[PATCH] D97598: [NFC][AMDGPU] Document the AMDGPU target feature defaults

Tony Tye via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 1 17:24:44 PST 2021


t-tye added inline comments.


================
Comment at: llvm/docs/AMDGPUUsage.rst:509-528
+                                                  If not specified for code object V2 to V3, generate
+                                                  code that can be loaded and executed in a process
+                                                  with XNACK replay enabled.
+
+                                                  If not specified for code object V4, generate
+                                                  code that can be loaded and executed in a process
+                                                  with either setting of XNACK replay.
----------------
foad wrote:
> t-tye wrote:
> > foad wrote:
> > > Isn't your third paragraph here just explaining that the first two are identical? I.e. "generate code that works with xnack replay enabled" and "generate code that works whether xnack replay is enabled or not" are the same thing.
> > Code object v2/v3 does not support the concept of ANY and so the default has to be ether ON or OFF. The second paragraph specifies that ON is used.
> > 
> > Code object V4 has the concept of ANY and the third paragraph states that the default is ANY.
> > 
> > The fourth paragraph describes the consequences of these defaults.
> But ANY and ON are synonyms, aren't they? They both seem to tell the compiler to do exactly the same thing, so the default behaviour hasn't changed in any observable way.
No they are not. Code object v2-v3 only supports ON and OFF. Code object supports ON, OFF, and ANY. ANY tells the loader that it is safe to load the code on a device configured with either ON or OFF. ON tells the loader it can only load onto a device with the feature ON.

It may be that the compiler generates the same code for ON and ANY but that is distinct from how the loader acts on them.

This is explained more in the TargetID section of the clang offload bundler.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97598/new/

https://reviews.llvm.org/D97598



More information about the llvm-commits mailing list