AMDGPUCodeGenPrepareImpl::visitBinaryOperator() calls Builder.CreateBinOp() and casts the resulting Value as a BinaryOperator without checking, leading to an assert failure in a case found by fuzzing. In this case, the operands are constant and CreateBinOp does constant folding so returns a Constant instead of a BinaryOperator.
LIT tests which were incorrectly merged are corrected.
This reverts commit 0563569978fee1e780a560494c89869074933f58. Breaks tests, see comments on https://github.com/llvm/llvm-project/pull/134153
PHI operands and results must belong to the same register class. If a PHI node produces an SGPR, but one of its operands is a VGPR, we insert a VGPR-to-SGPR copy in the operand’s source block. The PHI operand is then updated to use the destination register of the inserted copy. These inserted copies are processed immediately when they are created. Therefore, we should avoid reprocessing them when handling their parent block later. --------- Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Insert the start instruction directly into the map before the uses. This prevents improperly re-visting sgpr->vgpr phi inputs multiple times which would trigger a use after free. I don't particularly trust the iteration scheme here. This is also unnecessarily revisting transitive users of a phi or reg_sequence for every input operand, but I will address that separately. Fixes #130646. I also believe it fixes #130119, although that test fails less consistently for me.
Given the rest of the pass just gives up when it needs to compose subregisters, folding a subregister extract directly into a reg_sequence is counterproductive. Later fold attempts in the function will give up on the subregister operand, preventing looking up through the reg_sequence. It may still be profitable to do these folds if we start handling the composes. There are some test regressions, but this mostly looks better.
This reverts commit 254d206ee2a337cb38ba347c896f7c6a14c7f218. +Added a fix in ExpandDivRem24 to disqualify if DivNumBits exceed 24. Original commit & msg: ce6e955ac374f2b86cbbb73b2f32174dffd85f25. Handle signed and unsigned path differently in getDivNumBits. Using computeKnownBits, this rejects shrinking unsigned div/rem if operands exceed signed max since we know NumSignBits will be always 0.
This reverts commit 509893b58ff444a6f080946bd368e9bde7668f13. This broke the libc build again https://lab.llvm.org/buildbot/#/builders/73/builds/9787.
… (SignedMax,UnsignedMax] (#116733)" This reverts commit 905e831f8c8341e53e7e3adc57fd20b8e08eb999. Handle signed and unsigned path differently in getDivNumBits. Using computeKnownBits, this rejects shrinking unsigned div/rem if operands exceed signed max since we know NumSignBits will be always 0. Rebased and re-attempt after first one was reverted due to unrelated failure in LibC (should be fixed by now I'm told).
This reverts commit b8e1d4dbea8905e48d51a70bf75cb8fababa4a60. Causes failures on the `libc` test suite https://lab.llvm.org/buildbot/#/builders/73/builds/8871