This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Emit predefined macro `__AMDGCN_CUMODE__`
ClosedPublic

Authored by yaxunl on Mar 5 2023, 5:35 PM.

Details

Summary

Predefine __AMDGCN_CUMODE__ as 1 or 0 when compilation assumes CU or WGP modes.

If WGP mode is not supported, ignore -mno-cumode and emit a warning.

This is needed for implementing device functions like __smid (https://github.com/ROCm-Developer-Tools/hipamd/blob/312dff7b794337aa040be0691acc78e9f968a8d2/include/hip/amd_detail/amd_device_functions.h#L957)

Diff Detail

Unit TestsFailed

Event Timeline

yaxunl created this revision.Mar 5 2023, 5:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 5 2023, 5:35 PM
yaxunl requested review of this revision.Mar 5 2023, 5:35 PM
arsenm added a comment.Mar 5 2023, 5:48 PM

I think exposing whether or not the flag was used is weird/broken, as is including _OPTION in the name. Should just define to whether it's enabled or not

yaxunl added a comment.Mar 5 2023, 6:40 PM

I think exposing whether or not the flag was used is weird/broken, as is including _OPTION in the name. Should just define to whether it's enabled or not

I agree. @b-sumner What do you think?

b-sumner added a comment.EditedMar 5 2023, 7:33 PM

I think exposing whether or not the flag was used is weird/broken, as is including _OPTION in the name. Should just define to whether it's enabled or not

I agree. @b-sumner What do you think?

Applications may need to check if CUMode is set at compile time, and they may also need to check if an old compiler is being used. So an macro that says whether it's enabled or not is fine, and if no macro is defined, then the application can conclude the compiler is old

tra added a comment.Mar 6 2023, 12:04 PM

Can __has_feature be used to accomplish what you need?

arsenm requested changes to this revision.Mar 6 2023, 12:09 PM

We can’t let specific flag usage leak into the semantics. Cu mode is on or off. If someone really cares about supporting older compilers they could always define their own macro

This revision now requires changes to proceed.Mar 6 2023, 12:09 PM
yaxunl updated this revision to Diff 518391.Apr 30 2023, 9:16 PM
yaxunl retitled this revision from [AMDGPU] Emit predefined macro `__AMDGCN_CUMODE_OPTION` to [AMDGPU] Emit predefined macro `__AMDGCN_CUMODE`.
yaxunl edited the summary of this revision. (Show Details)

Revised by Matt's comments.

Can __has_feature be used to accomplish what you need?

There are a few issues using __has_feature or similar builtin macros to check target feature, which has been discussed in https://reviews.llvm.org/D125555 . One of the concerns is the stability of target feature name.

Using a predefined macro does not have such concern.

arsenm added inline comments.May 1 2023, 1:17 PM
clang/lib/Basic/Targets/AMDGPU.cpp
318

Why do we sometimes use __ on both sides, and sometimes only leading __?

yaxunl added inline comments.May 1 2023, 5:19 PM
clang/lib/Basic/Targets/AMDGPU.cpp
318

We did not establish a naming convention for pre-defined macros.

The rationale of only prefixing with __ is that:

  1. it is shorter
  1. many other targets following that for target feature related macros, e.g. https://github.com/llvm/llvm-project/blob/main/clang/test/Preprocessor/arm-target-features.c , https://github.com/llvm/llvm-project/blob/main/clang/test/Preprocessor/riscv-target-features.c

The rationale of adding __ on both sides is:

  1. most gcc predefined macros follow this convention https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
  1. some targets follow this convention for target feature related macros, e.g https://github.com/llvm/llvm-project/blob/main/clang/test/Preprocessor/x86_target_features.c

I think it is not too late to establish a naming convention for predefined macros for amdgpu target. I would prefer to adding __ on both sides since

  1. most of the existing amdgpu predefined macros follow that. We just need to add __AMDGCN_WAVEFRONT_SIZE__ and phasing out __AMDGCN_WAVEFRONT_SIZE. This will be the least interruptive.
  1. we will conform to GCC naming convention for pre-defined macros.

Or maybe we should have an RFC for this topic.

yaxunl updated this revision to Diff 521396.May 11 2023, 11:50 AM
yaxunl retitled this revision from [AMDGPU] Emit predefined macro `__AMDGCN_CUMODE` to [AMDGPU] Emit predefined macro `__AMDGCN_CUMODE__`.
yaxunl edited the summary of this revision. (Show Details)

rename the macro to be consistent with most existing predefined macros for amdgcn target

arsenm added inline comments.May 12 2023, 7:44 AM
clang/include/clang/Basic/DiagnosticDriverKinds.td
121–123

I'm surprised there already isn't a warning for this?

clang/lib/Driver/ToolChains/CommonArgs.cpp
146

I don't understand the use of "no-cumode". Where is this defined?

yaxunl added inline comments.May 12 2023, 8:05 AM
clang/include/clang/Basic/DiagnosticDriverKinds.td
121–123

I am surprised too. Before this patch, there is no check and no handling of unsupported target features in Clang. clang just blindly adds target features specified in the command line and relies on the backend to handle them properly.

This patch enables Clang to warn and ignore unsupported target features.

clang/lib/Driver/ToolChains/CommonArgs.cpp
146

This function is called by clang driver. The argument TargetFeature is the target feature command line option to be checked, with -m removed, e.g. -mcumode or -mno-cumode passed to this function as "cumode" or "no-cumode".

arsenm added inline comments.May 12 2023, 9:26 AM
clang/lib/Driver/ToolChains/CommonArgs.cpp
146

Can this use something like

if (!DriverArgs.hasFlag(options::OPT_fgpu_sanitize,
                        options::OPT_fno_gpu_sanitize, true))
  return true;

to make it clear this is checking the flag? At a minimum this needs to be renamed to indicate it's a flag and not the actual subtarget feature name

yaxunl updated this revision to Diff 521714.May 12 2023, 10:41 AM
yaxunl marked an inline comment as done.

revised by Matt's comments

arsenm accepted this revision.May 12 2023, 10:45 AM
This revision is now accepted and ready to land.May 12 2023, 10:45 AM
This revision was landed with ongoing or failed builds.May 12 2023, 4:01 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2023, 4:01 PM