This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Extend stacksave/restore elimination
ClosedPublic

Authored by nextsilicon-itay-bookstein on Nov 3 2021, 7:50 AM.

Details

Summary

Previously, InstCombine detected a pair of llvm.stacksave/stackrestore
instructions that are adjacent modulo debug instructions in order to
eliminate the llvm.stackrestore. This precludes situations where
intervening instructions (e.g. loads) preclude the llvm.stacksave and
llvm.stackrestore from becoming adjacent. This commit extends the logic
and allows for eliminating the llvm.stackrestore when the range of
instructions between them does not include any alloca or side-effect
causing instructions.

Signed-off-by: Itay Bookstein <itay.bookstein@nextsilicon.com>

Diff Detail

Event Timeline

nextsilicon-itay-bookstein requested review of this revision.Nov 3 2021, 7:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 3 2021, 7:50 AM

Not really familiar with stack manipulation infra.

llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1808–1809

&& SS.getParent() == II.getParent()

1811

What if they are in different blocks?

1822–1823

Maybe add a comment that all non-intrinsic calls are considered to be side-effects?

nikic added a subscriber: nikic.Nov 3 2021, 8:20 AM
nikic added inline comments.
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1822–1823

Generally, an explanation how exactly "side effects" come into this would be nice. "Side effect" in LLVM is defined as memory write, unwind or divergence, none of which are really related to allocas (an alloca is not a side effect).

Added comment about call-with-side-effects, added same-BB-check

nextsilicon-itay-bookstein marked 2 inline comments as done.Nov 3 2021, 10:14 AM
nextsilicon-itay-bookstein added inline comments.
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1808–1809

Great catch, thanks.

1822–1823

I added a comment about considering all non-intrinsic calls to be side-effects.
Regarding the allocas, I classify them separately above, so I'm not 100% sure if you meant that I should add something at this line or above?

Can this patch be split into two, the NFC refactoring, and the actual change?

nextsilicon-itay-bookstein marked an inline comment as done.

split from NFC refactor

Looks good.

llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1814–1815

What about stackrestore from the same stacksave?

llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1814–1815

Then it will have been eliminated when it was the subject of the enclosing switch statement, before this one was. I will add an appropriate comment.

lebedev.ri accepted this revision.Nov 9 2021, 1:47 AM

Seems fine.

llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1814–1815

I'm mainly highlighting that it might not have already happened because of the processing order.
It would be really hard to come up with an appropriate test manually,
but i suspect it is possible.

This revision is now accepted and ready to land.Nov 9 2021, 1:47 AM

Improved the test to include multiple stackrestores.

llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1814–1815

I see. So it's a matter of not not deferring the work to the next InstCombine iteration (or missing the opportunity if it's we're at the iteration cap). Would you prefer that I replace the comment with the check?

Refined logic so that stackrestores of the same stacksave do
not inhibit removal in the same instcombine iteration.

lebedev.ri added inline comments.Nov 9 2021, 2:21 AM
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
1814–1815

So it's a matter of not not deferring the work to the next InstCombine iteration (or missing the opportunity if it's we're at the iteration cap).

Right.

Would you prefer that I replace the comment with the check?

I think that would be better, yes.

nextsilicon-itay-bookstein marked 3 inline comments as done.Nov 9 2021, 2:29 AM
lebedev.ri accepted this revision.Nov 9 2021, 2:33 AM