This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Get address space mapping by target triple environment
ClosedPublic

Authored by yaxunl on Mar 23 2017, 7:19 AM.

Details

Summary

As we introduced target triple environment amdgiz and amdgizcl, the address space values are no longer enums. We have to decide the value by target triple.

The basic idea is to use struct AMDGPUAS to represent address space values. For address space values which are not depend on target triple, use static const members, so that they don't occupy extra memory space and is equivalent to a compile time constant.

Since the struct is lightweight and cheap, it can be created on the fly at the point of usage. Or it can be added as member to a pass and created at the beginning of the run* function.

Diff Detail

Repository
rL LLVM

Event Timeline

yaxunl created this revision.Mar 23 2017, 7:19 AM
yaxunl edited the summary of this revision. (Show Details)Mar 23 2017, 7:22 AM
rampitec edited edge metadata.Mar 23 2017, 9:24 AM

Sam, I have found reference to AMDGPUAS in 23 files, including one td file. Please also look at indirect uses like in AMDGPUAliasAnalysis.cpp:

 static const AliasResult ASAliasRules[5][5] = {
/*             Private    Global    Constant  Group     Flat */
/* Private  */ {MayAlias, NoAlias , NoAlias , NoAlias , MayAlias},
/* Global   */ {NoAlias , MayAlias, NoAlias , NoAlias , MayAlias},
/* Constant */ {NoAlias , NoAlias , MayAlias, NoAlias , MayAlias},
/* Group    */ {NoAlias , NoAlias , NoAlias , MayAlias, MayAlias},
/* Flat     */ {MayAlias, MayAlias, MayAlias, MayAlias, MayAlias}
 };
arsenm edited edge metadata.Mar 23 2017, 1:33 PM

I'm not sure this intermediate step should go upstream

yaxunl updated this revision to Diff 92869.Mar 23 2017, 2:50 PM
yaxunl retitled this revision from [WIP] [AMDGPU] Get address space mapping by target triple to [AMDGPU] Get address space mapping by target triple.

completed the change.

I'm not sure this intermediate step should go upstream

The change is simple and can be easily reverted. It might be cheaper to revert it later than maintain two branches.

t-tye added inline comments.Mar 24 2017, 11:46 AM
lib/Target/AMDGPU/AMDGPU.h
181–209 ↗(On Diff #92869)

Since all these are still constants, and the plan is to revert back to having an enumeration for AddressSpaces, would it be better to leave these as an anonymous enum enumerators and avoid the need for changing this text, or defining the large number of static variables needed?

t-tye added inline comments.Mar 24 2017, 6:52 PM
lib/Target/AMDGPU/AMDGPU.h
181–209 ↗(On Diff #92869)

Since you have already done the change probably best to leave as is for consistency. Note the few places that did not get updated to access these via . member selection.

lib/Target/AMDGPU/AMDGPUAliasAnalysis.cpp
51–52 ↗(On Diff #92869)

I think this comment needs updating?

63–64 ↗(On Diff #92869)

Is using a DenseMap the best choice here? If an address space that is not one of the ones assigned in the ASAliasRulesTy constructor is used to index then won't it create a new entry and default construct the mapping meaning 0 will be returned?

Also DenseMap seems non-trivial, would if be better to initialize the ASAliasRules array so it can be indexed directly with the address space number (asserting that the 5 address spaces we care about are <5).

73–79 ↗(On Diff #92869)

This checking seems to belong in getAliasResult since that is where these restrictions are needed due to the implementation inside getAliasResult.

lib/Target/AMDGPU/AMDGPUISelDAGToDAG.cpp
594 ↗(On Diff #92869)

For consistency should this be AMDGPUASI.CONSTANT_BUFFER_0 ?

lib/Target/AMDGPU/SIISelLowering.cpp
2212 ↗(On Diff #92869)

Should this be AMDGPUASI.GLOBAL_ADDRESS for consistency?

2401 ↗(On Diff #92869)

Should this be AMDGPUASI.LOCAL_ADDRESS for consistency?

lib/Target/AMDGPU/SMInstructions.td
231 ↗(On Diff #92869)

Should this be AMDGPUASI.GLOBAL_ADDRESS for consistency?

t-tye edited reviewers, added: t-tye; removed: tony-tye.Mar 24 2017, 6:53 PM
yaxunl added inline comments.Mar 24 2017, 7:05 PM
lib/Target/AMDGPU/AMDGPU.h
181–209 ↗(On Diff #92869)

I will fix those inconsistencies.

lib/Target/AMDGPU/AMDGPUAliasAnalysis.cpp
63–64 ↗(On Diff #92869)

You are right. I will use two static arrays and choose the right one in constructor.

We need to include Region memory for the index to be continuous from 0 to 5.

73–79 ↗(On Diff #92869)

will move it there.

yaxunl updated this revision to Diff 93085.Mar 26 2017, 3:19 PM
yaxunl marked 12 inline comments as done.
yaxunl retitled this revision from [AMDGPU] Get address space mapping by target triple to [AMDGPU] Get address space mapping by target triple environment.
yaxunl edited the summary of this revision. (Show Details)

Updated remaining usage of AMDGPUAS::.

t-tye accepted this revision.Mar 26 2017, 6:50 PM

Minor suggestions.

Presumably the concern to avoid linking LLVM IR with different settings of the address space mapping is enforced because each has a different data layout.

Otherwise:

LGTM

lib/Target/AMDGPU/AMDGPUAliasAnalysis.cpp
60 ↗(On Diff #93085)

Privat->Private

62–63 ↗(On Diff #93085)

Would it be better to simply assert the assumption built into the tables that the address space indexes are exactly as expected, and that MAX_COMMON_ADDRESS is less than or equal to the table size?

assert(AS.MAX_COMMON_ADDRESS <= 5);
if (AS.FLAT_ADDRESS == 0) {
  assert(AS.FLAT_ADDRESS == 0 &&
           AS.GLOBAL_ADDRESS == 1 &&
           AS.REGION_ADDRESS == 2 &&
           AS.LOCAL_ADDRESS == 3 &&
           AS.CONSTANT_ADDRESS == 4 &&
           AS.PRIVATE_ADDRESS == 5);
  ASAliasRules = &ASAliasRulesGenIsZero;
} else {
  assert(AS.PRIVATE_ADDRESS == 0 &&
           AS.GLOBAL_ADDRESS == 1 &&
           AS.CONSTANT_ADDRESS == 2 &&
           AS.LOCAL_ADDRESS == 3 &&
           AS.FLAT_ADDRESS == 4 &&
           AS.REGION_ADDRESS == 5);
  ASAliasRules = &ASAliasRulesPrivIsZero;
}
68–73 ↗(On Diff #93085)

Move to do once in the constructor.

lib/Target/AMDGPU/AMDGPUAliasAnalysis.h
53 ↗(On Diff #93085)

Should this be ASAliasRulesTy(const ASAliasRulesTy &R)? Does if even need to be defined since it is exactly the same as the default copy constructor?

54 ↗(On Diff #93085)

Should this be a const member since it does not change ASAliasRulesTy?

This revision is now accepted and ready to land.Mar 26 2017, 6:50 PM
yaxunl marked 5 inline comments as done.Mar 26 2017, 8:40 PM
yaxunl added inline comments.
lib/Target/AMDGPU/AMDGPUAliasAnalysis.cpp
62–63 ↗(On Diff #93085)

yes. will do.

lib/Target/AMDGPU/AMDGPUAliasAnalysis.h
53 ↗(On Diff #93085)

You are right. We don't need this. Will remove it.

54 ↗(On Diff #93085)

Will make it const.

This revision was automatically updated to reflect the committed changes.
yaxunl marked 3 inline comments as done.