> 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. Now I realize that said like this it sounds more like stage1 material. Would it be fine for next stage1? Best regards, Thomas
