instructionWaitsForSGPRWrites function covers ALL SALU instructions, including those like s_waitcnt that don't read from sgpr. This results in removing delay_alu instructions in cases like VALU->SGPR->VALU, which results in performance regression. Change modifies the function so that it checks if instruction also reads a sgpr.
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>
Unused sdst writing to null to avoid a false VALU->SALU dependency stall. This requires using the VOP3 encoding.
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.
We have a VALU->SGPR->SALU (VALU writing to SGPR and SALU reading from it). When VALU is issued, it increments internal counter VA_SDST used to track use of this SGPR. SALU will not issue until VA_SDST is zero, that is when VALU is finished writing. Therefore, delays added by s_delay_alu are not needed in this situation.
Many tests use store to undef as a placeholder use, so just replace all of these with poison.
This reverts commit 71582c6667a6334c688734cae628e906b3c1ac1d. Multiple buildbot failures have been reported: https://github.com/llvm/llvm-project/pull/127212
We have a VALU->SGPR->SALU (VALU writing to SGPR and SALU reading from it). When VALU is issued, it increments internal counter VA_SDST used to track use of this SGPR. SALU will not issue until VA_SDST is zero, that is when VALU is finished writing. Therefore, delays added by s_delay_alu are not needed in this situation.