This is an archive of the discontinued LLVM Phabricator instance.

[CUDA][SPIRV] Match builtin types and __GCC_ATOMIC_XXX_LOCK_FREE macros on host/device
ClosedPublic

Authored by shangwuyao on Feb 14 2023, 2:13 PM.

Details

Summary

This change matches the CUDA/SPIRV behavior with CUDA/NVPTX, and makes some builtin types
and __GCC_ATOMIC_XXX_LOCK_FREE macros the same between the host and device. This is only
done when host triple is provided and known, otherwise the behavior is unchanged.

Diff Detail

Event Timeline

shangwuyao created this revision.Feb 14 2023, 2:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2023, 2:13 PM
shangwuyao requested review of this revision.Feb 14 2023, 2:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2023, 2:13 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Making the builtin types consistent is necessary to keep struct layout consistent across host and device, but why do we need to make __GCC_ATOMIC_XXX_LOCK_FREE macros the same between the host and device? Is there any concrete issue if they are not the same?

Making the builtin types consistent is necessary to keep struct layout consistent across host and device, but why do we need to make __GCC_ATOMIC_XXX_LOCK_FREE macros the same between the host and device? Is there any concrete issue if they are not the same?

The reason is the same as NVPTX, see https://github.com/llvm/llvm-project/blob/22882c39df71397cc6f9774d18e87d06e016c55f/clang/lib/Basic/Targets/NVPTX.cpp#L137-L141. Without it, we won't be able to use libraries that statically check the __atomic_always_lock_free. I could add the comments in the code if that makes things more clear.

Making the builtin types consistent is necessary to keep struct layout consistent across host and device, but why do we need to make __GCC_ATOMIC_XXX_LOCK_FREE macros the same between the host and device? Is there any concrete issue if they are not the same?

The reason is the same as NVPTX, see https://github.com/llvm/llvm-project/blob/22882c39df71397cc6f9774d18e87d06e016c55f/clang/lib/Basic/Targets/NVPTX.cpp#L137-L141. Without it, we won't be able to use libraries that statically check the __atomic_always_lock_free. I could add the comments in the code if that makes things more clear.

I see. Better add some comments about that.

This also means backend needs to handle atomic operations not supported by hardware.

Amend with comments

Making the builtin types consistent is necessary to keep struct layout consistent across host and device, but why do we need to make __GCC_ATOMIC_XXX_LOCK_FREE macros the same between the host and device? Is there any concrete issue if they are not the same?

The reason is the same as NVPTX, see https://github.com/llvm/llvm-project/blob/22882c39df71397cc6f9774d18e87d06e016c55f/clang/lib/Basic/Targets/NVPTX.cpp#L137-L141. Without it, we won't be able to use libraries that statically check the __atomic_always_lock_free. I could add the comments in the code if that makes things more clear.

I see. Better add some comments about that.

This also means backend needs to handle atomic operations not supported by hardware.

Yeah. It is probably the application developer's responsibility to not request atomics that are not supported by the hardware?

Run clang-format.

Friendly ping :-)

yaxunl accepted this revision.Feb 21 2023, 8:06 AM

LGTM. Thanks

This revision is now accepted and ready to land.Feb 21 2023, 8:06 AM