RE: [PATCH] Don't check for optab for 16bit bswap

[Oleg Endo <oleg dot endo at t-online dot de>]

On Mon, 2015-01-05 at 14:54 +0000, Thomas Preud'homme wrote:
> > From: Oleg Endo [mailto:oleg.endo@t-online.de]
> > Sent: Tuesday, December 30, 2014 4:25 PM
> > 
> > I've just tried disabling the 'rotlhi3' pattern and __builtin_bswap16
> > expands into shift + and + or (as expected).
> > Thus, I don't think the patch will make something worse (than it
> > already
> > 
> > .L42:
> > 
> > is) on some backends.  If the bswap detection bails out at the tree
> > level, the expanded ops will be shift + and + or -- as written in the
> > original code.  So probably, that will be the same as the fallback
> > expansion for __builtin_bswap16, and we're back to sqrt (1).
> > 
> > > OK, that is what I was asking - are there cases where using rot is worse
> > (like forcing a libcall or so).
> > 
> > See also comment in expmed.c (expand_shift_1):
> >  It is theoretically possible that the target machine might
> >  not be able to perform either shift and hence we would
> >  be making two libcalls rather than just the one for the
> >  shift (similarly if IOR could not be done).  We will allow
> >  this extremely unlikely lossage to avoid complicating the
> >  code below.  */
> > 
> > then goto .L42  ;)
> 
> Yes and if the fallback expansion for a rot is actually worse than the
> original set of stmt it means the fallback expansion should be improved.

I might be missing something, but how can the original shift/and/or
statements (which eventually are translated to shift/and/or insns) be
any better than the shift/and/or insns that are expanded by the rot
fallback?  In both cases the insns have to go through the backend
expanders, and if those are absent/unsupported libcalls will be
expanded.

> Now I realize that said like this it sounds more like stage1 material.
> 
> Would it be fine for next stage1?

Or maybe just leave everything as it is and I add a bswaphi expander in
the SH backend ;)

Cheers,
Oleg