This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Move code sinking before structurizer
ClosedPublic

Authored by piotr on Apr 22 2021, 3:23 PM.

Details

Summary

Moving code sinking pass before structurizer creates more sinking
opportunities.

The extra flow edges introduced by the structurizer can have adverse
effects on sinking, because the sinking pass prefers moving instructions
to blocks with unique predecessors and the structurizer destroys that
property in some cases.

A notable example is moving high-latency image instructions across kills.

Diff Detail

Event Timeline

piotr created this revision.Apr 22 2021, 3:23 PM
piotr requested review of this revision.Apr 22 2021, 3:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 22 2021, 3:23 PM
piotr updated this revision to Diff 339799.Apr 22 2021, 3:26 PM

Added test.

I don't remember why we even run this extra sink run. The regular middle end optimizer runs it. I think this helped one edge case at one point. Do any tests regress if you just remove it entirely?

foad added a subscriber: foad.Apr 22 2021, 10:51 PM
piotr added a comment.EditedApr 23 2021, 1:40 AM

I know it is a legacy pass, but I am convinced of its usefulness in our flow - both in real-world content and lit testing (e.g., no_skip_no_successors in skip-if-dead.ll).

I know it is a legacy pass, but I am convinced of its usefulness in our flow - both in real-world content and lit testing (e.g., no_skip_no_successors in skip-if-dead.ll).

I'm not worried about legacy, but whether it's redundant since it should have already run at this point

llvm/test/CodeGen/AMDGPU/multilevel-break.ll
198

Did this drop the memory operand or something? This looks like a regression

llvm/test/CodeGen/AMDGPU/sink-image-sample.ll
4

Maybe add a comment explaining what this is for?

arsenm added inline comments.Apr 23 2021, 5:58 AM
llvm/test/CodeGen/AMDGPU/multilevel-break.ll
198

Oh, these loads are already volatile and should have had glc set. Maybe this test was last regenerated before glc was emitted for volatile loads?

piotr added a comment.Apr 23 2021, 5:59 AM

I know it is a legacy pass, but I am convinced of its usefulness in our flow - both in real-world content and lit testing (e.g., no_skip_no_successors in skip-if-dead.ll).

I'm not worried about legacy, but whether it's redundant since it should have already run at this point

Some sinking is done as part of other passes, but I do not think this pass is set up to be run at any other point in our pass list.

piotr added inline comments.Apr 23 2021, 7:15 AM
llvm/test/CodeGen/AMDGPU/multilevel-break.ll
198

Good spot - I get the glc generated even without my patch. I will pre-commit those glc changes separately so they do not pop up here.

piotr updated this revision to Diff 340052.Apr 23 2021, 8:34 AM

Rebased, added comment in test.

piotr added a comment.Apr 23 2021, 8:35 AM

I know it is a legacy pass, but I am convinced of its usefulness in our flow - both in real-world content and lit testing (e.g., no_skip_no_successors in skip-if-dead.ll).

I'm not worried about legacy, but whether it's redundant since it should have already run at this point

Some sinking is done as part of other passes, but I do not think this pass is set up to be run at any other point in our pass list.

@foad helped me understand what you mean (thanks). Yes, this pass should be part of the opt pipeline, but currently we rely on it being run in the codegen pipeline. I do not know the history of that, but Mesa also needs it here.

arsenm accepted this revision.May 3 2021, 2:27 PM

I know it is a legacy pass, but I am convinced of its usefulness in our flow - both in real-world content and lit testing (e.g., no_skip_no_successors in skip-if-dead.ll).

I'm not worried about legacy, but whether it's redundant since it should have already run at this point

Some sinking is done as part of other passes, but I do not think this pass is set up to be run at any other point in our pass list.

@foad helped me understand what you mean (thanks). Yes, this pass should be part of the opt pipeline, but currently we rely on it being run in the codegen pipeline. I do not know the history of that, but Mesa also needs it here.

The backend isn't responsible for adding all the general optimization passes, only cases where we might want them to cleanup other lowering or late optimizations. I don't remember why this ended up here but moving it is fine

This revision is now accepted and ready to land.May 3 2021, 2:27 PM
This revision was landed with ongoing or failed builds.May 11 2021, 5:34 AM
This revision was automatically updated to reflect the committed changes.