This is an archive of the discontinued LLVM Phabricator instance.

DAG: propagate whether an arg is a pointer for CallingConv decisions.
ClosedPublic

Authored by t.p.northover on Mar 5 2019, 10:17 AM.

Details

Reviewers
arsenm
Summary

The arm64_32 ABI specifies that pointers (despite being 32-bits) should be zero-extended to 64-bits when passed in registers for efficiency reasons. This means that the SelectionDAG needs to be able to tell the backend that an argument was originally a pointer, which is implmented here.

Additionally, some memory intrinsics need to be declared as taking an i8* instead of an iPTR.

There should be no CodeGen change yet (so again no tests I'm afraid), but it will be triggered when AArch64 backend support for ILP32 is added.

Diff Detail

Repository
rL LLVM

Event Timeline

t.p.northover created this revision.Mar 5 2019, 10:17 AM
arsenm added a subscriber: arsenm.Mar 5 2019, 11:09 AM
arsenm added inline comments.
llvm/include/llvm/CodeGen/TargetCallingConv.h
48

This should probably include the address space. Currently the AMDGPU calling convention lowering hacks through this by looking at the original IR argument index

t.p.northover marked an inline comment as done.

Now with added context!

llvm/include/llvm/CodeGen/TargetCallingConv.h
48

Sounds plausible. I've added an extra field to parallel the ByValSize thing. It meant bumping up the size but I don't think we're drowning in these structs.

Accidentally had part of the ConsecutiveRegs patch in here.

arsenm accepted this revision.Apr 15 2019, 4:09 AM

LGTM

This revision is now accepted and ready to land.Apr 15 2019, 4:09 AM
arsenm added inline comments.Apr 15 2019, 4:10 AM
llvm/include/llvm/CodeGen/TargetCallingConv.h
52

You could make this -1 and then check that instead of a separate isPointer field, but I doubt that will actually save any space

t.p.northover closed this revision.Apr 15 2019, 5:03 AM
t.p.northover marked an inline comment as done.

Thanks, it's r358399.

llvm/include/llvm/CodeGen/TargetCallingConv.h
52

It would also be inconsistent with how ByVal is handled, so I think I'll leave it as is for now.

Thanks, it's r358399.

Sorry, this one is r358398.