An x86 backend improvement that I'm working results in combine attempting
to recognize:

(set (reg:DI 87 [ xD.2846 ])
     (ior:DI (subreg:DI (ashift:TI (zero_extend:TI (reg:DI 92))
                                   (const_int 64 [0x40])) 0)
             (reg:DI 91)))

where the lowpart SUBREG has difficulty seeing through the (hi<<64)
that the lowpart must be zero.  Rather than workaround this in the
backend, the better fix is to teach simplify-rtx that
lowpart((hi<<64)|lo) -> lo and highpart((hi<<64)|lo) -> hi, so that
all backends benefit.  Reducing the number of places where the
middle-end generates a SUBREG of something other than REG is a
good thing.

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, except for pr78904-1b.c, for which a backend
solution has just been proposed.  Ok for mainline?


2023-06-18  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
        * simplify-rtx.cc (simplify_subreg):  Optimize lowpart SUBREGs
        of ASHIFT to const0_rtx with sufficiently large shift count.
        Optimize highpart SUBREGs of ASHIFT as the shift operand when
        the shift count is the correct offset.  Optimize SUBREGs of
        multi-word logic operations if the SUBREGs of both operands
        can be simplified.


Thanks in advance,
Roger
--