Differential D31211
[AMDGPU] Switch data layout by triple environment Authored by yaxunl on Mar 21 2017, 2:26 PM.
Details Switch data layout by target triple environment amdgiz and amdgizcl indicating using of an address space mapping in which generic address space is 0. amdgiz is for non-OpenCL environment where generic address space is 0. amdgizcl is for OpenCL environment where generic address space is 0. This is mainly to allow upstreaming Clang changes for changing address space mapping https://reviews.llvm.org/D31210 since the Clang data layout needs to match the backend data layout.
Diff Detail Event TimelineComment Actions This can't be a subtarget feature. This needs to be a global option since this is a property of the module Comment Actions I believe it is much more than just adding feature. At the very least it should change addrspace enum and potentially its uses. Comment Actions This is just a start point for upstreaming the Clang changes. Further changes will follow. Comment Actions 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. Comment Actions For now this is mainly to provide a matching data layout for Clang, otherwise when Clang emit llvm for AMDGPU there will be warnings. We cannot upstream everything at the same time. That will be too big to review. The plan is to let Clang generates expected LLVM IR first, then bring in the backend change. By this patch, we can also facilitate upstreaming the changes for letting alloca returning private pointer. What we need to do is for the old address space mapping we let alloca return pointer in address space 0, and for the new address space mapping, we let alloca return pointer in address space 5. This way, we could upstream the alloca change without breaking anything. In the final stage hopefully we only need minor changes to switch to the new address space mapping. Comment Actions 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. Comment Actions You can add an arbitrary environment type string to the end of the triple you could check
| ||||||||||||
I don't think we should be adding new entries for a temporary step. I think the triple still preserves whatever you give it, so can you check getEnvironmentName()?