[Bug target/109874] [SH] GCC 13's -Os code is 50% bigger than GCC 4's

["olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109874

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olegendo at gcc dot gnu.org

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> It looks like the target cannot do arbitrary constant shifts so it benefits
> from shifting incrementally.  Even if that is exposed early enough for CSE
> the optimal sequences for shifting by 10, 11, 12 and 13 could prevent CSE
> here.

That's right.  SH1, SH2 doesn't have a barrel shifter and needs stitched
constant shifts.  In some cases we resort to a rt lib call to avoid code bloat.

There are a couple of opportunities when sharing intermediate results of
incremental / stitched shifts.  A while ago I had the idea of writing an RTL
pass that would try to figure that out...

In this case the shifts are expanded to RTL with the constant shift amounts
already propagated and the incremental shifts removed, so it's a bit harder to
undo this at the RTL level, but not impossible.

On SH3, SH4 dynamic shifts are available, but it requires another register +
constant load.  Incremental / stitched shifts would be always better on SH for
this test case.