On Mon, 2015-01-05 at 14:54 +0000, Thomas Preud'homme wrote: > > From: Oleg Endo [mailto:oleg.e...@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