https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #97 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexander Klepikov from comment #96)
>
> Not really. 'expand_ashiftrt' could emit
>
> mov #imm, r1
> shad r1, r0
>
> and 'mov' instruction would be loop invariant if there's a loop. It looks
> like 'ashrsi3_libcall_expanded' is a bad name. I think name
> 'ashrsi3_n_call_expanded' would be more appropriate.
Ah, yes, indeed. I'm cleaning up your patch and will rename it.
>
> > However, there is one case from your previous posts in PR 49263:
> >
> > int f_rshift(char v){
> > return v >> S;
> > }
> >
> > This will not work on SH2 and expand to a libcall.
>
> I think you mean SH2A, because the same is going on with SH4.
>
> > On SH4 the combine pass
> > converts it into:
> >
> > Successfully matched this instruction:
> > (set (reg:SI 166)
> > (ashiftrt:SI (reg/v:SI 164 [ v ])
> > (const_int 31 [0x1f])))
> >
> > But it doesn't even try to do so with the 'ashrsi3_n_call' pattern. Not
> > sure why ...
>
> Well, the same thing is going on when using vanilla GCC. It looks like it's
> happening due to char sign extension. Then instruction is catched by
> 'ashrsi2_31' pattern. In another words, it looks to me like an optimization.
It can be fixed by adding another pattern. I'll make another patch for that
later.
