This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Add llvm.read.register support for vlenb
ClosedPublic

Authored by reames on May 13 2022, 8:30 AM.

Details

Summary

This patch adds minimal support for lowering an read.register intrinsic with vlenb as the argument. Note that vlenb is an implementation constant, so it is never allocatable.

This was split off a patch to eventually replace PseudoReadVLENB with a COPY MI because doing so revealed a couple of optimization opportunities which really seemed to warrant individual patches and tests. To write those patches, I need a way to write the tests involving vlenb, and read.register seemed like the right testing hook.

A couple notes for reviewers on oddities (things we should maybe fix infrastructure in other patches):

  • InstrEmitter will crash when lowering a copy from a physical register if that physical register is not a member of some register class. I didn't study the code closely, but on the surface this seems odd. I worked around this by adding a dummy register class, and assuming others agree, will use it's removal as the test for a change to InstrEmitter.
  • I couldn't figure out a robust way to translate from CSR register defs to the sysreg number. Oddly, getName() on VLENB returns EH_LABEL? I suspect we have something missing elsewhere.

Diff Detail

Event Timeline

reames created this revision.May 13 2022, 8:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 13 2022, 8:30 AM
reames requested review of this revision.May 13 2022, 8:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 13 2022, 8:30 AM
craig.topper accepted this revision.May 13 2022, 8:57 AM

LGTM. Should we eventually implement something like AArch64DAGToDAGISel::tryReadRegister?

This revision is now accepted and ready to land.May 13 2022, 8:57 AM

Should we eventually implement something like AArch64DAGToDAGISel::tryReadRegister?

I think that basically comes down to a question of whether we think having the ccsr exposed earlier than COPY elimination is helpful. I don't currently have a strong opinion on that, but would lean towards using the generic COPY through optimization.

This revision was landed with ongoing or failed builds.May 13 2022, 9:12 AM
This revision was automatically updated to reflect the committed changes.

I couldn't figure out a robust way to translate from CSR register defs to the sysreg number. Oddly, getName() on VLENB returns EH_LABEL? I suspect we have something missing elsewhere.

That sounds like you asked TargetInstrInfo for the name rather than TargetRegisterInfo. EH_LABEL is instruction number 4. VLENB is register number 4.

Should we eventually implement something like AArch64DAGToDAGISel::tryReadRegister?

I think that basically comes down to a question of whether we think having the ccsr exposed earlier than COPY elimination is helpful. I don't currently have a strong opinion on that, but would lean towards using the generic COPY through optimization.

This is absolutely what I did. Thanks! Fixed properly in 853fa8ee. Though I am surprised the register type auto-converts to something TII accepts...

Should we eventually implement something like AArch64DAGToDAGISel::tryReadRegister?

I think that basically comes down to a question of whether we think having the ccsr exposed earlier than COPY elimination is helpful. I don't currently have a strong opinion on that, but would lean towards using the generic COPY through optimization.

This is absolutely what I did. Thanks! Fixed properly in 853fa8ee. Though I am surprised the register type auto-converts to something TII accepts...

The code base isn't clean on use of Register so there is an operator unsigned() I think.

For anyone curious on context, I wrote up a punchlist of potential optimizations following this here: https://github.com/preames/public-notes/blob/master/llvm-riscv-status.rst#optimizations-for-constant-physregs-vlenb-x0. I'm going to know through a few of the easier ones.

Would llvm.vscale() * 8 have been a good testing hook for vlenb? I imagine that would CSE in SelectionDAG.

Would llvm.vscale() * 8 have been a good testing hook for vlenb? I imagine that would CSE in SelectionDAG.

vscale is currently lowered to PseudoReadVLENB. I needed something which bypassed the pseudo to be able to write the COPY from constant physreg cases before replacing the pseudo with the plain copy.