This is an archive of the discontinued LLVM Phabricator instance.

[CallingConv] Generate isCCArgumentReg() predicate via tablegen
AbandonedPublic

Authored by void on Feb 17 2022, 3:19 PM.

Details

Summary

The purpose of isCCArgumentReg() is to help identify whether a given
register can be used for passing arguments when calling a function. The
initial usage is for the `-fzero-call-used-regs' commandline option,
which can optionally zero out argument registers. We don't care about
the registers used for the return values.

We piggyback off of *CallingConv.td information, which is used to
generate code to allocate a register. Instead of actually allocating a
register, it checks to see if a given register *could* be allocated,
based on the calling convention, and reports "true" if it is one of the
registers in the CC (the opposite of the allocation code, which reports
"false" when the register is allocated).

Diff Detail

Event Timeline

void created this revision.Feb 17 2022, 3:19 PM
void requested review of this revision.Feb 17 2022, 3:19 PM
arsenm added inline comments.Feb 17 2022, 3:25 PM
llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
3060 ↗(On Diff #409803)

Not sure why you need ArgFlags or are setting inreg here, you need to preserve this from the original IR

void added inline comments.Feb 17 2022, 3:34 PM
llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
3060 ↗(On Diff #409803)

I should explain better in the commit message what's going on.

The ArgFlags is here because some *CallingConv.td files have custom code in them to check these flags.

What all of this code is doing is simply saying whether or not a register is part of a calling convention. Because of that, I don't need to retain many of the flags and other stuff that's needed when allocating the register.

void updated this revision to Diff 409807.Feb 17 2022, 3:39 PM

Improved the commit message.

void updated this revision to Diff 409811.Feb 17 2022, 3:57 PM

Add override method to BogusRegisterInfo.

Revision summary seems to be totally lacking any explanation of what this actually is for. Also how is this meant to interact with architectures like MIPS where return value registers aren't argument registers (v0 and v1); is it meant to include those or not? The name suggests it does, but the old function name suggested it didn't (and was just a stub outside of X86?).

llvm/lib/Target/RISCV/RISCVRegisterInfo.h
73

Spelling

arsenm added inline comments.Feb 17 2022, 6:13 PM
llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
3060 ↗(On Diff #409803)

But if the code is checking them, and this is lying to it, what good is it? inreg can change the register/register class used for a parameter

This seems to add a large amount of code that may duplicate information already available elsewhere. It's hard to say, in particular because I don't quite understand the exact semantics of the new isCallingConvReg. For what registers exactly should this return true? Those that may hold (part of) an argument or return value? Those that hold some platform-specific value like a GOT pointer? Those that may be clobbered by the call?

void updated this revision to Diff 410395.Feb 21 2022, 3:02 PM
  • s/isCallingConvReg/isCCArgumentReg/g
  • Improve commit message to explain better the purpose of this predicate.
void updated this revision to Diff 410396.Feb 21 2022, 3:04 PM
void marked an inline comment as done.

spelling

void added a comment.Feb 21 2022, 3:05 PM

Revision summary seems to be totally lacking any explanation of what this actually is for. Also how is this meant to interact with architectures like MIPS where return value registers aren't argument registers (v0 and v1); is it meant to include those or not? The name suggests it does, but the old function name suggested it didn't (and was just a stub outside of X86?).

I improved the commit message.

You're correct that we don't care about return values here. I changed the predicate's name to better reflect that.

void updated this revision to Diff 410398.Feb 21 2022, 3:06 PM

Accidental commit fixed.

void retitled this revision from [CallingConv] Generate isArgumentRegister() predicate via tablegen to [CallingConv] Generate isCCArgumentReg() predicate via tablegen.Feb 21 2022, 3:07 PM
void edited the summary of this revision. (Show Details)
uweigand added inline comments.Feb 22 2022, 1:42 AM
llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp
472 ↗(On Diff #410398)

This whole series of functions still is quite confusing and seems really pointless to me.

If you want to answer the question: "identify whether a given register can be used for passing arguments when calling a function" on SystemZ, this is very simple: Just look at the existing lists

ELFArgGPRs,  ELFArgFPRs  (for the ELF calling convention)
XPLINK64ArgGPR,  XPLINK64ArgFPRs, XPLINK64ArgVRs (for the XPLINK calling convention)

This will correctly answer the above question without any need for TableGen generated routines or any of this additional code (which looks at those lists anyway, so it isn't even that those would be avoided ...).

void updated this revision to Diff 410585.Feb 22 2022, 10:31 AM

Simplify the SystemZ isCCArgumentReg predicate.

llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp
472 ↗(On Diff #410398)

The point of using TableGen is to make it as generic as possible so that all backends have a ready-made call that will answer the question for them without having to resort to custom code. If one backend (in this case SystemZ) has a simpler way to do this, then we should use that instead. I'll change the code for SystemZ.

uweigand added inline comments.Feb 23 2022, 2:19 AM
llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp
480 ↗(On Diff #410585)

Thanks for reworking this, this looks much simpler. However, this version now solely returns general purpose registers used for argument passing. The SystemZ calling convention may in addition also use floating-point registers (and, for XPLINK64, vector registers) to pass arguments of certain types; these are ignored by this implementation.

Is the semantics of isCCArgRegister such that only GPRs *should* be returned? In that case, I think this should be clearly documented (and also, some of the other implementations may have to be adapted?). However, if all registers need to be returned here, then you'll also have to check those other lists mentioned above.

void added inline comments.Feb 23 2022, 1:45 PM
llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp
480 ↗(On Diff #410585)

I ARE DUMM! I didn't look at your comment above well-enough. Instead, I looked at some of the other code in the SystemZ directory. My mistake. I'll fix this.

void updated this revision to Diff 410929.Feb 23 2022, 1:46 PM

Include the FP registers for SystemZ.

uweigand added inline comments.Feb 24 2022, 2:24 AM
llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp
480 ↗(On Diff #410585)

SystemZ changes LGTM now, thanks!

The Hexagon part looks ok.

Herald added a project: Restricted Project. · View Herald TranscriptMar 14 2022, 3:10 PM
simoll edited reviewers, added: kaz7; removed: simoll.Mar 21 2022, 5:35 AM
kaz7 added a comment.Apr 17 2022, 12:44 AM

VE part looks OK too.

void abandoned this revision.Apr 6 2023, 2:31 PM