These date back to when the non-intrinsic format of variable locations
was still being tested and was behind a compile-time flag, so not all
builds / bots would correctly run them. The solution at the time, to get
at least some test coverage, was to have tests opt-in to non-intrinsic
debug-info if it was built into LLVM.
Nowadays, non-intrinsic format is the default and has been on for more
than a year, there's no need for this flag to exist.
(I've downgraded the flag from "try" to explicitly requesting
non-intrinsic format in some places, so that we can deal with tests that
are explicitly about non-intrinsic format in their own commit).
This is meant as a preparation for PR #130988 "[AMDGPU] Implement IR
expansion for frem instruction" which implements the expansion of
another instruction in this pass. The more general name seems more
appropriate given this change and quite reasonable even without it.
As suggested on
5ec884e5d8 (commitcomment-153707488)
this seems to fix the following tests when building with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON:
LLVM :: CodeGen/AMDGPU/materialize-frame-index-sgpr.gfx10.ll
LLVM :: CodeGen/AMDGPU/materialize-frame-index-sgpr.ll
LLVM :: CodeGen/AMDGPU/schedule-amdgpu-tracker-physreg-crash.ll
> This PR fixes test failures introduced in #127353 when expensive checks
> are enabled.
>
> For `llvm/test/CodeGen/AMDGPU/materialize-frame-index-sgpr.ll` and
> `llvm/test/CodeGen/AMDGPU/materialize-frame-index-sgpr.gfx10.ll`, `s59`
> is no longer in live-ins because it is caller saved. Switch to `s55` in
> this PR.
Contrary to the comment, this particular code is not responsible
for handling any composes that may be required, and unhandled cases
are already rejected later. Lift this restriction to permit composes
and reg_sequence subregisters later.
Before the dawn of civilization, instructions were printed in all
caps using the raw tablegen pseudo-names. This -NOT check was looking
for that, instead of the actual ISA output. Just switch to using generated
checks. Also replace a use of undef.
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.
EnableTailMerge is false by default and is handled by the pass builder.
Passes are independent of target pipeline options.
This completes the generic `MachineLateOptimization` passes for the NPM
pipeline.
The allocation order of 16 bit registers is vgpr0lo16, vgpr0hi16,
vgpr1lo16, vgpr1hi16, vgpr2lo16.... We prefer (essentially require) that
allocation order, because it uses the minimum number of registers. But
when you have 16 bit data passing between 16 and 32 bit instructions you
get lots of COPY.
This patch teach the compiler that a COPY of a 16-bit value from a 32
bit register to a lo-half 16 bit register is free, to a hi-half 16 bit
register is not.
This might get improved to coalescing with additional cases, and perhaps
as an alternative to the RA hints. For now upstreaming this solution
first.
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.
