diff options
| author | Amara Emerson <amara@apple.com> | 2023-06-04 00:23:47 -0700 |
|---|---|---|
| committer | Amara Emerson <amara@apple.com> | 2023-06-04 00:24:38 -0700 |
| commit | fbdcd54442ef9435d753ae974d33992f99d85ad8 (patch) | |
| tree | 5ad98c4739ac47e3b771c66b3d7b4bd9d7b6c7b3 /llvm/lib/CodeGen/StackMaps.cpp | |
| parent | f4eafba2064d52f992e6f32c957f3d51d8627975 (diff) | |
| download | llvm-fbdcd54442ef9435d753ae974d33992f99d85ad8.zip llvm-fbdcd54442ef9435d753ae974d33992f99d85ad8.tar.gz llvm-fbdcd54442ef9435d753ae974d33992f99d85ad8.tar.bz2 | |
[GlobalISel] Fix DIVREM combine from inserting a divrem before its operands' defs.
In some rare corner cases where in between the div/rem pair there's a def of
the second instruction's source (but a different vreg due to the combine's
eqivalence checks), it will place the DIVREM at the first instruction's point,
causing a use-before-def. There wasn't an obvious fix that stood out to me
without doing more involved analysis than a combine should really be doing.
Fixes issue #60516
I'm open to new suggestions on how to approach this, as I'm not too happy
at bailing out here. It's not the first time we run into issues with value liveness
that the DAG world isn't affected by.
Differential Revision: https://reviews.llvm.org/D144336
Diffstat (limited to 'llvm/lib/CodeGen/StackMaps.cpp')
0 files changed, 0 insertions, 0 deletions