[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 #72 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexander Klepikov from comment #71)
> 
> > * Do we really need to add that new source file sh_loop.cc with the wrapper
> > classes?  Can't we just instantiate the passes that are needed in-place when
> > they are registered?
> 
> Unfortunately, no.
> [...]

That's too bad.  Thanks for digging.  I haven't checked myself recently, I
thought this infrastructure has been improved a little bit, but seems not so. 
Perhaps SH is the only backend that wants to do this kind of thing.  Let's
leave it at that for now.  Later, after everything else has been cleared out we
can ask other GCC developers' opinion on this.

> Yes, of course! I'll add some 'tst #imm,0' presence tests.

That'd be good.

> Should I add hoist test? I do not yet understand how hoisting check should be
> performed, but I hope to find examples.

Also not sure how to do that at the moment.  Maybe scanning RTL dumps of the
new extra passes?  Or perhaps just a simple example as a start:

void test_func (int* a_ptr, int* b_ptr, unsigned int count)
{
  for (unsigned int i = 0; i < count; ++i)
    a_ptr[i] >> 5;


  for (unsigned int i = 0; i < count; ++i)
    b_ptr[i] >> 5;
}

... and then just scan the asm output and check against the expected number of
insns.  In this case, mov.l insn to load the function call address.


> Maybe some other tests? If I'm missing something, please tell me.

Right now not that I can think of.


> And as I understand, I should name test file something like
> pr54089-next-free-number.c, right?

Yes, that should be fine.