This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Fix LiveVariables verifier error for values defined before SI_END_CF
ClosedPublic

Authored by arsenm on Mar 5 2023, 11:44 AM.

Details

Reviewers
critson
foad
Pierre-vh
rampitec
Group Reviewers
Restricted Project
Summary

GlobalISel happens to insert some constant materializes before SI_END_CF
in one test. These need to be excluded from AliveBlocks since they
are defined in the original block and used in the split block,
so they aren't fully alive through either block.

The case where the value defined in the first block which was originally used
in a later block is still broken.

Avoids a verifier error in a future patch.

Diff Detail

Event Timeline

arsenm created this revision.Mar 5 2023, 11:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 5 2023, 11:44 AM
arsenm requested review of this revision.Mar 5 2023, 11:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 5 2023, 11:44 AM
Herald added a subscriber: wdng. · View Herald Transcript

Patch LGTM, I just have a few questions to try and understand it better

llvm/lib/Target/AMDGPU/SILowerControlFlow.cpp
519

What does live through mean in this context?

llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.xfail.mir
3

Is this a test case that will be fixed in a future patch?

arsenm added inline comments.Mar 6 2023, 9:15 AM
llvm/lib/Target/AMDGPU/SILowerControlFlow.cpp
519

Defined in a predecessor and used in a successor

llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.xfail.mir
3

Ideally yes but this turned out to be more work than I expected and I wanted to unblock the other patch

Pierre-vh accepted this revision.Mar 7 2023, 2:41 AM
This revision is now accepted and ready to land.Mar 7 2023, 2:41 AM
ruiling added a subscriber: ruiling.Mar 7 2023, 5:01 AM
ruiling added inline comments.
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

Can we teach the previous pass to insert the instruction after prologue instruction? like through SkipPHIsAndLabels().

arsenm added inline comments.Mar 7 2023, 5:36 AM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

I think the prolog logic gets too complicated and we would need to scan through the entire block. Terminator placement is universally understood

ruiling added inline comments.Mar 7 2023, 6:14 AM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

I don't see why we need to scan through the entire block?

arsenm added inline comments.Mar 8 2023, 5:15 PM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

We currently treat the prolog as instructions that modify exec. The problem here is spills get inserted which don’t modify exec. In case a prolog appears anywhere, we would need to scan the whole block. The prolog concept is really frail as it is. We’d be better off removing it given that we sometimes need to insert more instructions in the prolog

ruiling added inline comments.Mar 8 2023, 8:28 PM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

If an instruction modifies EXEC does not immediately follow PHI or other prolog instruction, I think it is not prolog anymore. So I think we should never look for prolog by scanning the whole block. I agree the prolog concept is fragile. But I don't have a good idea to replace it now. I like the other change to always split the block and let the s_or_exec be the terminator. With that change, do we still have a case to insert vector instructions before the s_or_exec afterward?

For this case, I would like we teach the constant materializer respect the basic block prolog unless we decided deprecating the prolog idea. Otherwise, such pattern can be easily broken by machine optimization passes (like sinking a vector operation before SI_END_CF).

arsenm added inline comments.Mar 9 2023, 5:21 AM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

SI_END_CF is a hack to force placement of the instruction after phi lowering. It's fine if instruction end up inserted before it. In a better world where we have block arguments instead of phis, we wouldn't need to have this

ruiling added inline comments.Mar 9 2023, 6:47 AM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

IMHO, a vector instruction inserted before SI_END_CF is not ok. In a typical if/endif case, vector instructions in endif block should be executed with restored EXEC mask, which was done by SI_END_CF. I am not quite sure whether that would happen because vector instructions usually have dependency on EXEC, moving vector instruction across block should not be easy. Maybe I miss something, but I think it would be safer to keep SI_END_CF being prolog instruction.

arsenm added inline comments.Mar 9 2023, 6:51 AM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

SI_END_CF was never a prolog instruction since it doesn’t have the exec def on it. It only exists because of the requirement for phis to be the first instructions in the block. It’s always eliminated before regalloc where the prolog matters

ruiling added inline comments.Mar 9 2023, 7:52 PM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

Look at the example SI_END_CF killed %4, implicit-def $exec, implicit-def dead $scc, implicit $exec. There is a implicit-def $exec in SI_END_CF, and The MI.modifiesRegister(AMDGPU::EXEC, &RI) at (https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AMDGPU/SIInstrInfo.cpp#L6187) will return true for SI_END_CF.
Block prolog also matters at machine optimization stage, like @critson did in D119399.

arsenm closed this revision.Apr 8 2023, 4:05 AM
llvm/test/CodeGen/AMDGPU/lower-control-flow-live-variables-update.mir
248

OK, it is. I missed the implicit exec def. However that doesn't change anything. Without fundamentally changing the IR to avoid using phi instructions, this is always going to be an ugly hack with a true insert position with vector instructions before it.