[PATCH] D31211: [AMDGPU] Add target feature new-addr
Yaxun Liu via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 22 09:55:42 PDT 2017
yaxunl added a comment.
In https://reviews.llvm.org/D31211#707627, @arsenm wrote:
> In https://reviews.llvm.org/D31211#707611, @yaxunl wrote:
> > In https://reviews.llvm.org/D31211#706970, @yaxunl wrote:
> > > In https://reviews.llvm.org/D31211#706892, @arsenm wrote:
> > >
> > > > This can't be a subtarget feature. This needs to be a global option since this is a property of the module
> > >
> > >
> > > By convention, Clang use -m options for target specific options, e.g. -mmmx. Clang translates them to target feature string by dropping -m. When TargetInfo is constructed in Clang, only TargetOption is available. I don't see a better way to define a Clang option which is only used by AMDGPU target.
> > In Clang codegen, when clang creates a module, it will use data layout specified by Clang's TargetInfo, then it will create a target machine and query the data layout returned by the target machine. If these two data layout mismatch, it will emit a warning. When Clang queries the data layout of the target machine, it only depends on the properties of the target machine itself. If we want to tell the target machine to use a specific address space mapping, we need to convey that information through the arguments of the constructor of the target machine, e.g. target triple, target option or feature string. It seems to me that feature string is the reasonable way to convey this information.
> > Can you elaborate on your comments about global option? A global option of what? The AMDGPU backend, or the LLVM module? Thanks.
> You can add an arbitrary environment type string to the end of the triple you could check
Sounds great. I will try that. Thanks.
More information about the llvm-commits