...

1. Jivan has a small patch which detects generation of some redundant sign/zero extensions in the RISC-V backend.    This is not expected to produce any significant benchmark improvements, but mostly serves as a final catch for corner cases so that we don't have to debug them again.  To date cases detected have all been due to expansion of builtins which perform overflow checking of basic integer operations.
   1. To date this has only triggered as a result of the expansion of arithmetic with overflow checking
   2. Probably still worth integrating
2. Eliminate the redundant sign extension after an inlined strcmp.
3. Eliminate the redundant sign extension after an inlined memcmp
4. sCC code generation will often need mixed modes and would benefit from Jivan's trick
5. Use Jivan's trick to expose the sign extended nature of SI/HI/QI mode return values.
6. A signed comparison of a sign extended SI subreg against a constant with 0x8000000 clear can be turned into unsigned comparison in DImode
   1. This is a generalization of the min/max case that's currently handled in bitmanip.md.
   2. Investigate if we're already handling this (we may be), and if not explore the best way to fix
7. Investigate Ajit's work (IBM) to exploit cases where masking can be viewed as zero-extension within REE
8. In REE handle cases like (any_extend:DI (ashift:SI )) where the extension can be replaced by a SUBREG and then push the SUBREG into the operands generating word sized operations.  This helps 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:

...

Updates

07 Nov 2024 

• Incomplete/New items moved to 2025.

12 Oct 2024 

• Jivan's patch to avoid zero/sign extending a value already known to be appropriately extended has been integrated.

...