This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Extend sext.w removal pass to remove unused sign-extensions
AbandonedPublic

Authored by mohammed-nurulhoque on Feb 11 2022, 2:30 AM.

Details

Summary

Current pass recursively searches definitions backwards to determine if a sext.w is redundant because the value is already in sign-extended form. An instruction propagates a sign-extended definition if giving it a sign-extended input yields a sign-extended output.

This patch adds recursively searching uses forwards to determine if bits 63:32 of sext.w result are not used, so it can be removed. An isntruction propagates sign-extended use if the lower word of its output is only dependent on the lower word of its input.
It also adds a few W instructions to the backwards search.

I have a pending patch dependent on this one that "fixes" other instructions (e.g. ADD -> ADDW) to make a sext.w redundant.

Diff Detail

Event Timeline

mohammed-nurulhoque requested review of this revision.Feb 11 2022, 2:30 AM
mohammed-nurulhoque edited the summary of this revision. (Show Details)Feb 11 2022, 3:31 AM

Rebase on latest main

craig.topper added inline comments.Feb 11 2022, 8:53 AM
llvm/test/CodeGen/RISCV/sextw-removal.ll
506

The loop calculate the same value every time. The loop optimizers in the middle can remove it.

Nothing about this test looks a problem that is unique to RISCV. The shifts are redundant on any target and are visible to the middle end. Why shouldn't we clean it up in the middle end?

520

This function is unused

Thanks for your comments. As I mentioned, this patch is actually first half of a larger patch which I now uploaded as a signle patch here https://reviews.llvm.org/D119928 (didn't request reviews there yet). The main thing is transforming instructions to their W variant to eliminate sext.w occurences. With that change, checking for unused sext.w was just cheap to add because we already have the isAllUsesReadW function.

I originally broke it into 2 parts because I thought it would be too big for a single review, but I'm finding it hard to isolate a test case for the first part (this review) that wouldn't be optimized out by the middle-end. The full patch linked above has more convincing tests cases. Please do check the full patch and let me know if you think I should proceed with the full patch as a single review and cancel this one.

craig.topper added inline comments.Feb 16 2022, 10:45 PM
llvm/lib/Target/RISCV/RISCVSExtWRemoval.cpp
116

The register form is handled without knowing anything about the shift amount operand. So why does the immediate value matter?

120

Similar question.

298

Can't changing bit 31 break the sign extension?

llvm/lib/Target/RISCV/RISCVSExtWRemoval.cpp
116

In the register form, we check recursively if the uses of SLL only read the lower word.
We can do the same for SLLI, but if the immediate is >= 32, there's a stronger conclusion: we don't have to check the uses because the upper bit are already lost.
If the condition is false, we do the same as the register form.

120

Same here, AND with an immadiate that has leading zeros, we know we don't have to check the uses further. The upper bits are already lost.
Otherwise, we do the same as the register form.

298

true. Updating

mohammed-nurulhoque marked an inline comment as done.

a polite ping for this review.

Herald added a project: Restricted Project. · View Herald TranscriptMar 4 2022, 2:10 AM
craig.topper added inline comments.Mar 4 2022, 9:33 AM
llvm/lib/Target/RISCV/RISCVSExtWRemoval.cpp
63

const auto -> const auto *. LLVM coding guidelines want to see the *

149

Only one of the operands of ADD_UW uses all bits. Can we know which operand is being used?

162

SLLI_UW could be treated the same as W instructions. It only uses the lower 32 bits of the first operand.

180

Can you put the changes to this function in a separate patch with tests?

396

Combine this into a single if using &&

llvm/test/CodeGen/RISCV/sextw-removal.ll
506

I still don't think this is a robust test. The middle end can make it not a loop so it would never make it to the backend in this form. And it doesn't demonstrate a RISCV specific problem This code is a problem for any target so why is a RISC-V specific solution that correct solution?

Thank you for your feedback. I decided to abandon this revision and split its content to one that has just the changes in isSignExtendingOpW and one that has the forward searching https://reviews.llvm.org/D119928. I will request reviewing for these 2 soon.