[Bug target/54089] [SH] Refactor shift patterns

["klepikov.alex+bugs at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #79 from Alexander Klepikov <klepikov.alex+bugs at gmail dot com> ---
(In reply to Oleg Endo from comment #78)
> (In reply to Alexander Klepikov from comment #77)
> > > It'd be good if the newly added passes are ran only with -O2 or higher.
> > 
> > This can be confusing to users when they discover that not all invariants
> > are moved out of loops. Then we should inform them about that at least.
> 
> I don't think the compiler reports any optimizations not done to the user at
> lower optimization levels?  It's normal not to do certain optimizations at a
> lower level, that's why we have -O0 -O1 -O2 ... or do you mean something
> else by that?
> 

I mean that if a user run GCC with -O1 and we don't do SH specific loop move
invariants pass at -O1, a user could look at binary (or at .S file) and find
that not all invariants are moved out of the loops, because library addresses
are hoisted after split1 pass. That would confuse a user even if RTL dump is
generated, and he can decide that it's a bug into loop2 pass. I suggest to
generate sh_loop dumps if RTL dump is requested and place there a message that
sh_loop hoisting is not done due to optimization level setting.

But, actually, it's not that important at the moment because I'm aiming to do
the second option - run sh_loop only when it's potentially needed.

> The compiler processes one function at a time, all passes at once.

That's what I missed! Thank you for clarification!

> > I see some strange new exec fails only at testsuite logs. Right now I'm
> > trying to find the cause.
> 
> What's the configure line of your GCC build?

../gcc-13.1.0/configure --target=sh-elf --with-endian=big,little
--disable-bootstrap --enable-languages=c,c++ --disable-nls --with-gnu-as
--with-gnu-ld --prefix=/usr/local/sh-toolchain/ --without-newlib
--without-headers

I checked several cases and they are because ld cannot link little endian
binary. When I run failed command taken from log file, it always fails for
linking little endian binary. But sometimes logs say that executing of little
endian binary is successful. I'm at a loss - how is that even possible?