This is an archive of the discontinued LLVM Phabricator instance.

CodeGen: Add a hook for getFenceOperandTy
ClosedPublic

Authored by yaxunl on Apr 18 2017, 1:48 PM.

Details

Summary

Currently the operand type for ATOMIC_FENCE assumes value type of a pointer in address space 0.
This is fine for most targets. However for amdgcn target, the size of pointer in address space 0
depends on triple environment. For amdgiz environment, it is 64 bit but for other environment it is
32 bit. On the other hand, amdgcn target expects 32 bit fence operands independent of the target
triple environment. Therefore a hook is need in target lowering for getting the fence operand type.

This patch has no effect on targets other than amdgcn.

Diff Detail

Repository
rL LLVM

Event Timeline

yaxunl created this revision.Apr 18 2017, 1:48 PM
arsenm edited edge metadata.Apr 19 2017, 10:38 AM

Alternatively could these just be made i32 target constants for all targets?

lib/Target/AMDGPU/AMDGPUISelLowering.h
235 ↗(On Diff #95620)

Extra space before (

Alternatively could these just be made i32 target constants for all targets?

It requires changes lowering of ATOMIC_FENCE in several backends. I am not sure if those backends like this change.

kzhuravl added inline comments.Apr 20 2017, 10:32 PM
include/llvm/Target/TargetLowering.h
242 ↗(On Diff #95620)

new line.

lib/Target/AMDGPU/SIInstructions.td
97 ↗(On Diff #95620)

InstSI -> SPseudoInstSI.

102–104 ↗(On Diff #95620)

Remove these, as those are inherited from SPseudoInstSI.

yaxunl updated this revision to Diff 96150.Apr 21 2017, 8:52 AM
yaxunl marked 4 inline comments as done.

Revised by Matt's and Konstantin's comments.

t-tye accepted this revision.Apr 21 2017, 12:40 PM

Alternatively could these just be made i32 target constants for all targets?

It requires changes lowering of ATOMIC_FENCE in several backends. I am not sure if those backends like this change.

I think making these constants makes more sense than inventing getFenceOperandTy(). It seems other targets are using the size of a pointer to address space 0 which does not seem right as these operands are for the memory scope and memory ordering which are not pointer types. Assuming that the size of a pointer to address space 0 is the size of size_t also seems incorrect. Since these values are in fact integer constants then doing as @arsenm suggests above seems the better approach.

However, that would require changing other backends, so this approach seems to be a work around to avoid that. So perhaps a TODO could be added that explains what the right fix is, and see if other backends would agree to the change in a later patch?

LGTM if add TODO.

This revision is now accepted and ready to land.Apr 21 2017, 12:40 PM
yaxunl updated this revision to Diff 96220.Apr 21 2017, 1:35 PM

Add TODO by Tony's comments.

Any further comments? Thanks.

This revision was automatically updated to reflect the committed changes.