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

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

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

--- Comment #61 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexander Klepikov from comment #60)
> > Maybe it's easier to add some shift specific passes.
> 
> Well, I couldn't think of anything better and ported the loop optimization
> pass. More precisely, all loop optimization passes, because they are tied to
> each other. They run after split1 pass. And it worked!
> 
> I want to beleive that another loop optimization pass won't break anything
> because loops are already optimized.

Theoretically it should't ... 

> 
> If that's redundant, I thought of expanding libcall if it's inside a loop
> before loop optimization passes.

I'm a bit concerned about the increased compile time.  Have you observed
anything (negative) in this regard?

Loop, hoist, constant propagation etc (+ all the good stuff) optimizations are
done before insn combine / split1.  We could add a simple SH specific pass that
goes over the RTL and does stuff to shifts before those other optimizations. 
However, it might miss insn combine opportunities later on.  I'm thinking about
your tst #imm,r0 case from before.