This is an archive of the discontinued LLVM Phabricator instance.

[riscv] Remove mutation of prior vsetvli from insertion dataflow
ClosedPublic

Authored by reames on May 9 2022, 2:26 PM.

Details

Summary

This moves mutation entirely out of the main algorithm.

The immediate trigger is that we hit another case of the same issue I thought we'd fixed in 72925d9. It turns out we hadn't considered the cross block case.

As a brief summary, the issue being fixed is that if we mutate a previous vsetvli in phase 3, there's a possibility that some later use of that vsetvli changes "compatibility". In the cross_block_mutate test, this later vsetvli occurs in another block (and is thus visit order dependent too!). This causes us to fail strict asserts. (To be explicit, the current on by default workaround should compensate. It's only when we turn that off that we have problems.)

Now, I want to explicitly call out an alternate workaround. We could leave the mutation in phase 3, and simplify restrict it to the case where the previous vsetvli's GPR result is unused. That covers the case we've actually seen. (I'll note that codegen regressions with a simple form of this were significant. We might have to check specifically for the use outside block case to keep them reasonable, which complicates the workaround slightly.)

Personally, I'm at the point where I want the mutation pulled out just for robustness sake. I'm worried there's yet one more form of this bug we haven't thought about.

The other motivation for this change is that it does give us a couple of minor codegen wins. None appear to be hugely significant, but improvements never hurt right?

Diff Detail

Event Timeline

reames created this revision.May 9 2022, 2:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 9 2022, 2:26 PM
reames requested review of this revision.May 9 2022, 2:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 9 2022, 2:26 PM
reames planned changes to this revision.May 10 2022, 1:38 PM

I had an alternate way of solving the scalar move miscompile occur to me that I like a *lot* better than this. Posted for review here: https://reviews.llvm.org/D125337

Assuming that lands, I'll rebase this to solve the wrong abstract state bits, but I think we can do that much more simply if the wrong VL bug has already been fixed. I expect this patch to radically simplify.

reames updated this revision to Diff 428685.May 11 2022, 8:58 AM

Rebase after two predecessor patches.

Note that commit comment is now stale. Posting this mostly as a WIP. The opt quality result here is unconvincing, I want to play with a few other variants before deciding whether to bother with this at all.

reames planned changes to this revision.May 11 2022, 8:59 AM
reames updated this revision to Diff 430723.May 19 2022, 9:56 AM
reames edited the summary of this revision. (Show Details)
reames set the repository for this revision to rG LLVM Github Monorepo.

Rebase, and rework explanation.

reames updated this revision to Diff 430728.May 19 2022, 9:59 AM

Delete a stale comment

reames edited the summary of this revision. (Show Details)May 19 2022, 10:05 AM

I'm personally happy to see this moved out of phase 3. The fact it gets some codegen wins is definitely a bonus. I prefer it to the alternate workaround you mention.

llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
484

isVLPreservingConfig? I'm thinking it could to be more explicit about how it differs from the default one which we assume sets VL and VTYPE. That or isVTYPEOnlyConfig but I don't like that one quite as much. isVLPreservingVSETVLI

1484

Don't need {} on this loop

llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll
813–814

Is this FIXME still true with this patch?

reames updated this revision to Diff 431712.May 24 2022, 10:20 AM

Address review comments

craig.topper added inline comments.May 24 2022, 10:25 AM
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
489

Since it's PseudoVSETVLIX0 can we move AVLReg == RISCV::X0 to an assert?

reames updated this revision to Diff 431719.May 24 2022, 10:41 AM

Address review comment

Anything blocking this from going in?

This revision is now accepted and ready to land.May 25 2022, 9:13 AM
This revision was landed with ongoing or failed builds.May 25 2022, 10:51 AM
This revision was automatically updated to reflect the committed changes.