About
These are two tasks carried forward from 2H2023 and some additional work identified in 2024
FIrst is a small improvement from Jivan which detects generation of some redundant sign/zero extension in the RISC-V backend. Essentially in the low level optimizers Jivan intercepts requests for zero/sign extending a value. For a small set of cases we can look at the source object and determine if it is already sign extended. This is not expected to produce significant benchmark improvements and mostly serves to catch corner cases so that we do not have to debug them again. To date the cases caught so far have been highly concentrated in handling of builtins which perform arithmetic operations with overflow checking. No cases have been seen in benchmarks or other performance sensitive code.
Second, the extension-dce work that was started in 2H2024. This is a new optimization pass which is designed to track liveness of the result of sign/zero extension instructions. If the bits set by a sign/zero extension are never read and never escape (implicitly read), then the extension is useless and can potentially be removed. This is expected to improve x264's scalar implementation by roughly 1%. It is also expected to be a very small improvement to the coremark benchmark. Other codes show very small improvements. This code was originally targeted at gcc-14 (Spring 2024), but it was decided to wait rather than push integration of the code well after feature freeze.
Third, eliminate the redundant sign extensions after various double→int conversions. This can likely use the same procedure as we have with the 32bit ops like addw. Jivan has taken care of this.
Fourth, eliminate the redundant sign extension after an inlined strcmp. More generally expose the sign extended nature of function return values.
Fifth, using a technique Jivan introduced in 2023, we can seamlessly expose the sign extending nature of function return values in the backend which should eliminate another class of unnecessary sign extensions.
Sixth, investigate Ajit's work (IBM) to exploit cases where masking can be viewed as zero-extension within REE.
Seventh, in the extension elimination pass, handle things like (any_extend:DI (ashift: SI ...)). The extension will be replaced by a SUBREG, which we can then push into the operands creating word-sized operations. That eliminates the unnecessary extension in code like this:
void foo(unsigned char *data, unsigned int lo_bit) {
unsigned int mask = ((1UL << 1) - 1) << lo_bit;
*data = (*data & ~mask) | ((1 << lo_bit) & mask);
}
One the unnecessary extension is eliminated a simple backend pattern can be used to simplify all that to a simple lb+bset+sb.
Stakeholders/Partners
RISE:
Ventana: 1 FTE Jivan Hakobyan and Jeff Law
Rivos: Vineet (part time)
External:
The original idea for and implementation of the ext-dce pass was from Joern Rennecke at EMBECOSM.
Dependencies
Status
Updates
- Breaking out additional items as 2H2024 work
- Note additional case we should add to ext-dce.
- Note Jivan has taken care of extensions following fp→int conversions. It will be submitted once gcc-15 is open for development.
- Note the two additional identified opportunities to remove redundant sign extensions. Change development state to in-progress.
- Added yet another idea for ABI defined extension elimination in REE.
- Carried over unfinished items from 2H2023 plan
- Jivan's patch for catching corner cases of promoted objects integrated into tester