This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Fold stack reload into sext.w by using lw instead of ld.
ClosedPublic

Authored by craig.topper on Jul 16 2022, 6:31 PM.

Details

Summary

We can use lw to load 4 bytes from the stack and sign extend them
instead of loading all 8 bytes.

Diff Detail

Event Timeline

craig.topper created this revision.Jul 16 2022, 6:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 16 2022, 6:31 PM
craig.topper requested review of this revision.Jul 16 2022, 6:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 16 2022, 6:31 PM
asb added inline comments.Jul 17 2022, 8:43 AM
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
648

It would probably be a minor improvement in readability to define a isSEXTW helper and use it here and in RISCVSExtWRemoval.

650

I think you could ditch this and replace the .addMemOperand below with .setMemRefs(MI.memoperands())

craig.topper added inline comments.Jul 17 2022, 9:36 AM
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
650

MI is the sext.w, it doesn’t have a memoperand and the load hasn’t been created yet.

asb accepted this revision.Jul 17 2022, 1:16 PM

LGTM.

llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
650

Ah yes, of course it is. Sorry for the confusion.

This revision is now accepted and ready to land.Jul 17 2022, 1:16 PM
craig.topper added inline comments.Jul 17 2022, 1:24 PM
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
650

Should I check for little endian target here? For big endian I think we need to use 4 for the offset.

Add isSEXT_W helper.
Add check for big endian.

frasercrmck added inline comments.Jul 18 2022, 1:59 AM
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
652

Maybe it's just me but I read "sext.w+load" the other way round than it's intended here. Maybe I'm interpreting "+" as "followed-by"?

asb added a comment.Jul 18 2022, 2:43 AM

Good thought re big-endian. This looks good to me, modulo tweaking the comment as Fraser suggested.

llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
652

You're right, load+sext.w would seem clearer. Or maybe just use S-expressions to remove any ambiguity.

This revision was landed with ongoing or failed builds.Jul 18 2022, 9:09 AM
This revision was automatically updated to reflect the committed changes.
craig.topper added inline comments.Jul 18 2022, 9:13 AM
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
652

I think i wrong it that way because of "load from stack". I rewrote to "load from stack followed by sext.w" and remove the +

reames added inline comments.Jul 18 2022, 9:38 AM
llvm/test/CodeGen/RISCV/stack-folding.ll
24

Hm, looking at these spills sparks a question for discussion.

Do we have infrastructure to narrow the spill itself? If we know only four bytes are used, can we use a narrower store? And maybe even a smaller stack slot? I think the answer is here is no, but maybe it's worth some discussion?

There's two ways of narrowing this I see.

The first is the use of the narrow type - though that's been lowered so I really mean the presence of the sext.w. This could be phrased as some time of demanded bits analysis. Though, given how late we spill, maybe we don't have anything like that.

The second is exploiting the fact that only the i1 comparison value is actually needed. We could hoist the compare up to the site of the spill, and then store only the i1 - probably i8 in practice - result to the stack. This has all the general speculation safety and profitability concerns.

Anyways, just a thought that occurred.