On Fri, Jul 10, 2026 at 7:44 PM Roger Sayle <[email protected]> wrote: > > > Long story... Back in January I proposed the following patch: > https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705292.html > which contained two pieces, one in combine, the other in simplify-rtx. > Both of which were initially approved by Jeff Law here > https://gcc.gnu.org/pipermail/gcc-patches/2026-May/715595.html > but then Richard Sandiford pointed out the combine piece might > cause problems on RISC machines, and suggested improvements. > https://gcc.gnu.org/pipermail/gcc-patches/2026-May/715668.html > > In addition to making Richard's recommended changes, I've also > decided to split the patch into two, to enable bisection and > isolate these transformations [in case Richard S's fears come > to pass and the combine transformation needs to be reverted]. > > This is the "safe" (or less controversial) half. Hopefully, > folks are (still) happy for this bit to be committed? > p.s. the second and third hunks are just micro-optimizations; > we don't need to call simplify_gen_unary (TRUNCATE, ...) > if the operand already has the correct mode. The significant > change is that the modes don't need to match, and the operand > need not be a register [combine can put anything in a SUBREG]. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32}, > with no new failures. Ok for mainline?
OK. Thanks, Richard. > > 2026-07-10 Roger Sayle <[email protected]> > > gcc/ChangeLog > PR rtl-optimization/123236 > * simplify-rtx.cc (simplify_context::simplify_truncation): Handle > cases where a ZERO_EXTRACT or SIGN_EXTRACT has a different mode > to (but at least as wide as) its first operand. > > gcc/testsuite/ChangeLog > PR rtl-optimization/123236 > * gcc.target/i386/pr123236-1.c: New test case. > > > Thank again, > Roger > -- >
