This is an archive of the discontinued LLVM Phabricator instance.

[MachineSink] Don't reject sinking because of a dead def in isProfitableToSinkTo()
ClosedPublic

Authored by jonpa on May 12 2023, 6:57 AM.

Details

Summary

I am not quite sure, but it seems that the intent in this profitability check may be to avoid sinking phys-reg uses as they would prolong live ranges.

It seems reasonable to me to sink an instruction regardless if it has a dead def of a physreg or not. Physreg defs are checked in other places and sinking is only done with dead defs of regs that are not live into the target MBB.

It may be that this has more than a negligble impact on code generation, so perhaps this was avoided purposefully. It seems to change quite a lot of files on SPEC/SystemZ, at least. On the other hand, it seems that dead defs are in fact allowed generally. Please fill me in if I am missing something here.

This came up when I was experimenting with a pseudo that has the same operands as the target instruction, except it pretends to clobber CC. At least in this case I don't see why the sinking of that instruction should be any different than without that fake dead CC def.

Diff Detail

Event Timeline

jonpa created this revision.May 12 2023, 6:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2023, 6:57 AM
jonpa requested review of this revision.May 12 2023, 6:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2023, 6:57 AM
arsenm added inline comments.May 12 2023, 7:02 AM
llvm/test/CodeGen/AMDGPU/loop_exit_with_xor.ll
2

Switching a test to generated checks should be done in precommits

jonpa marked an inline comment as done.May 13 2023, 12:24 AM
jonpa added inline comments.
llvm/test/CodeGen/AMDGPU/loop_exit_with_xor.ll
2

ok - I will do so if there is a positive response to this patch, and if it's ok with you (AMD maintainer).

Sounds like a good idea to me, but I’m not versed enough in MachineIR to put the accept stamp on it.

llvm/lib/CodeGen/MachineSink.cpp
809–813

Should probably add brackets around the multiline-if.

arsenm accepted this revision.May 15 2023, 12:47 PM
This revision is now accepted and ready to land.May 15 2023, 12:47 PM
jonpa marked an inline comment as done.May 16 2023, 12:55 AM
This revision was landed with ongoing or failed builds.May 16 2023, 1:02 AM
This revision was automatically updated to reflect the committed changes.
alexfh added a subscriber: alexfh.May 22 2023, 10:21 AM

As a part of our routine internal release testing we found out that the Ptrdist/yacr2 benchmark shows an around 10% regression after this commit on Haswell CPUs. It's not blocking us in any way, but you might be interested in confirming that this doesn't indicate an undesired side effect on the generated code.

As a part of our routine internal release testing we found out that the Ptrdist/yacr2 benchmark shows an around 10% regression after this commit on Haswell CPUs. It's not blocking us in any way, but you might be interested in confirming that this doesn't indicate an undesired side effect on the generated code.

It's hard to say exactly what the reason is for that regression, but my best guess would be increased spilling which I think could happen when you increase sinking. This patch only says that it shouldn't affect the sinking decision if there is a dead def of a phys reg which is not live into the target MBB. That shouldn't affect reg-pressure / spilling by itself. Maybe this increased spilling (if that is indeed the case) comes from other factors which would then call for an additional further refinement of this cost function. Or it could be something else that needs fixing.

I checked impact on SystemZ / SPEC, which looked fine (no big changes). Don't know about yacr2 on Haswell - somebody more familiar would need to look into that...