Fix for #61766. Avoid asserting on dbg_value instr
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/CodeGen/MachineCycleAnalysis.cpp | ||
---|---|---|
101–103 ↗ | (On Diff #509050) | I am trying to understand how this is relevant to cycle invariance. It seems the intention is that debug instructions cannot be sunk by MachineSink. Then why not do this check there, in the function MachineSinking::FindCycleSinkCandidates()? The check can be done near the same line where isCycleInvariant() is called, ane it will be less confusing. |
llvm/lib/CodeGen/MachineCycleAnalysis.cpp | ||
---|---|---|
101–103 ↗ | (On Diff #509050) | Thanks for the review and comment, sameerds! This first solution was chosen after reading the comment on line 110 in isCycleInvariant (instr can't e.g. be hoisted, so mark this as not invariant). This also made isCycleInvariant callable on more instructions. But you're right, it is not clear. I will fix this. |
A more generalised solution I believe would be to skip debug instructions while examining the basic block -- that would mean
- Using an iterator-based for loop rather than a range based loop, and
- skipDebugInstructionsForward to increment past any debug instructions at the start of each iteration
Which would mean the rest of the logic in FindCycleSinkCandidates could remain unaltered. (The presence of debug instructions is awkward, but we're slowly trying to get rid of them).
For the test, I would recommend using a MIR test that runs only the machine-sink pass, to minimise the chance of other optimisation passes affecting the coverage of this test.
now skipping debug instructions while looping on basic block
replaced ll test by a MIR test
LGTM -- when landing could you add a short comment to the test indicating which function used to crash, that'll ease the life of anyone reading the test in the future and let them know exactly what's being tested.
llvm/lib/CodeGen/MachineSink.cpp | ||
---|---|---|
389–390 | You might be able to skip this as I believe we guarantee there are no debug intrinsics after the terminator of a block. On the other hand, it's not going to harm anything either. |
Thanks again for the review @jmorse. I modified the test.
I think the break statement cannot be removed, as it would crash if the last instruction is a debug instruction. Please correct me if I am missing something here.
Also I cannot merge the patch myself. So if everything is OK, could someone do this for me please?
> I think the break statement cannot be removed, as it would crash if the last instruction is a debug instruction. Please correct me if I am missing something here.
That's correct. MBB may not have any terminator.
clang-format not found in user’s local PATH; not linting file.