This is an archive of the discontinued LLVM Phabricator instance.

CodeGen: Disable isCopyInstrImpl if there are implicit operands
AcceptedPublic

Authored by arsenm on Jul 26 2023, 9:40 AM.

Details

Summary

This is a conservative workaround for broken liveness tracking of
SUBREG_TO_REG to speculatively fix all targets. The current reported
failures are on X86 only, but this issue should appear for all targets
that use SUBREG_TO_REG. The next minimally correct refinement would be
to disallow only implicit defs.

The coalescer now introduces implicit-defs of the super register to
track the dependency on other subregisters. If we see such an implicit
operand, we cannot simply treat the subregister def as the result
operand in case downstream users depend on the implicitly defined
parts. Really target implementations should be considering the
implicit defs and trying to interpret them appropriately (maybe with
some generic helpers). The full implicit def could possibly be
reported as the move result, rather than the subregister def but that
requires additional work.

Hopefully fixes #64060 as well.

This needs to be applied to the release branch.

Diff Detail

Event Timeline

arsenm created this revision.Jul 26 2023, 9:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 26 2023, 9:40 AM
arsenm requested review of this revision.Jul 26 2023, 9:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 26 2023, 9:40 AM
Herald added subscribers: wangpc, wdng. · View Herald Transcript

Just tried, this one does not solve the issue. Or it probably introduce a different miscompile. UBSan report is gone, but the test fails text expectations. With stable ( before D150388 ) compiler the test consistently green.

D156164 also makes the test consistently green.

Just tried, this one does not solve the issue. Or it probably introduce a different miscompile. UBSan report is gone, but the test fails text expectations. With stable ( before D150388 ) compiler the test consistently green.

D156164 also makes the test consistently green.

To clarify did you only apply this patch? You need the whole stack. This one in isolation won’t fix it

Just tried, this one does not solve the issue. Or it probably introduce a different miscompile. UBSan report is gone, but the test fails text expectations. With stable ( before D150388 ) compiler the test consistently green.

D156164 also makes the test consistently green.

To clarify did you only apply this patch? You need the whole stack. This one in isolation won’t fix it

yes, only the last one
arc patch does not apply entire stack, probably patches need to be rebased/uploaded

my 2c: if it's entire stack then revert D156381 is more appropriate solution

Just tried, this one does not solve the issue. Or it probably introduce a different miscompile. UBSan report is gone, but the test fails text expectations. With stable ( before D150388 ) compiler the test consistently green.

D156164 also makes the test consistently green.

To clarify did you only apply this patch? You need the whole stack. This one in isolation won’t fix it

yes, only the last one
arc patch does not apply entire stack, probably patches need to be rebased/uploaded

my 2c: if it's entire stack then revert D156381 is more appropriate solution

D156164 also works as the quick fix, I'm less horrified by it now that I fully understand what's happening. The full stack is a more refined variant

Just tried, this one does not solve the issue. Or it probably introduce a different miscompile. UBSan report is gone, but the test fails text expectations. With stable ( before D150388 ) compiler the test consistently green.

D156164 also makes the test consistently green.

To clarify did you only apply this patch? You need the whole stack. This one in isolation won’t fix it

yes, only the last one
arc patch does not apply entire stack, probably patches need to be rebased/uploaded

my 2c: if it's entire stack then revert D156381 is more appropriate solution

D156164 also works as the quick fix, I'm less horrified by it now that I fully understand what's happening. The full stack is a more refined variant

I don't know details of this code, but from my experience:

  1. revert
  2. wait a little
  3. land fixes
  4. wait a little
  5. revert the revert (better land patches one by one)

will be easier bisect/investigate if fixes introduce other issues later

alexfh added a subscriber: alexfh.Jul 26 2023, 5:42 PM

Vitaly is right. Let's revert the original commit with the dependent patches and work on a solution after that. I'm happy to test any suggested fixes, but we should first return the tree to a good state.

qcolombet added inline comments.Jul 28 2023, 5:47 AM
llvm/include/llvm/CodeGen/TargetInstrInfo.h
1044

Maybe that should be part of the verifier?

1053

Like I said in https://reviews.llvm.org/D156345, there was already a distinction between pure copies (isCopy) and copies with additional stuff that may require careful handling (isCopyLike).

Following this distinction, I feel that either:

  • this is the right fix, or
  • we need to make all the places that deals with isCopyInstr robust w.r.t. isCopyLike semantic, which may not be worth it to pull
arsenm added inline comments.Jul 28 2023, 9:41 AM
llvm/include/llvm/CodeGen/TargetInstrInfo.h
1044

Hypothetically you can still end up with the same implicit-def case as the mov, if you were to coalesce a copy into SUBREG_TO_REG. I believe all the instances which use SUBREG_TO_REG are fed by non-copy sources, so not sure if this happens in practice. The verifier probably should verify there are no implicit-defs at least

1053

worth it to pull

pull what?

qcolombet added inline comments.Jul 28 2023, 1:32 PM
llvm/include/llvm/CodeGen/TargetInstrInfo.h
1044

Hypothetically you can still end up with the same implicit-def case as the mov

True.

The scary thing to me is if regular copies have implicit defs, it would be good to distinguish if it is to make the liveness accurate or if it is something that went south (e.g., a target specific operation that got merged with a regular generic copy, in that case, codegen may be broken.)

1053

pull what?

Pull off :P.

I mean it may not be worth spending a lot of effort to support non pure copy everywhere.
I.e., Heroically try to implement the full support everywhere for a negligible gain.

arsenm added inline comments.Aug 2 2023, 3:20 PM
llvm/include/llvm/CodeGen/TargetInstrInfo.h
1053

I kind of think we should just get rid of SUBREG_TO_REG entirely. If you wanted to depend on those bits, you should have had to define them in the first place. However doing that is going to be a lot of work. I still haven't found anywhere making use of the "assert 0" property, if you really needed that it would look like AssertZext (which I would hope would be all taken care of before selection is complete)

qcolombet accepted this revision.Aug 8 2023, 2:46 AM
qcolombet added inline comments.
llvm/include/llvm/CodeGen/TargetInstrInfo.h
1053

+1
Also AFAICT, the lowering in ExpandPostRAPseudo is also broken with respect to preserving the bits when the source and target registers are not the same (super) register.

This revision is now accepted and ready to land.Aug 8 2023, 2:46 AM

Were the changes to arm-pcsections.ll in https://reviews.llvm.org/rGbc7d88faf1a595ab59952a2054418cdd0d9eeee8#change-knDnIXP6oBYw intended? We're seeing basically every single one of those fail when running the test locally. I'm also seeing bots failing, e.g. https://lab.llvm.org/buildbot/#/builders/119/builds/15375

arsenm reopened this revision.Oct 5 2023, 9:56 AM
This revision is now accepted and ready to land.Oct 5 2023, 9:56 AM