> The following patch implements this optimization. It checks for a range > that does not have the sign-bit set, and an index value that is already > sign extended, and then does a sign extend instead of an zero extend. > > This has been tested with a riscv{32,64}-{elf,linux} builds and testsuite > runs. There were no regressions. It was also tested with an x86_64-linux > build and testsuite run. > > Ok? > > Jim > > gcc/ > * expr.c (do_tablejump): When converting index to Pmode, if we have a > sign extended promoted subreg, and the range does not have the sign bit > set, then do a sign extend.
Richard dragged me into this so I feel somewhat entitled to step up... The patch looks OK to me, modulo: > + /* We know the value of INDEX is between 0 and RANGE. If we have a > + sign-extended subreg, and RANGE does not have the sign bit set, then > + we have a value that is valid for both sign and zero extension. In > + this case, we get better code if we sign extend. */ > + if (GET_CODE (index) == SUBREG > + && SUBREG_PROMOTED_VAR_P (index) > + && SUBREG_PROMOTED_SIGNED_P (index) > + && ((width = GET_MODE_PRECISION (as_a <scalar_int_mode> (mode))) > + <= HOST_BITS_PER_WIDE_INT) > + && ! (INTVAL (range) & (HOST_WIDE_INT_1U << (width - 1)))) I'd use UINTVAL instead of INTVAL here. -- Eric Botcazou