On January 5, 2015 3:54:40 PM CET, Thomas Preud'homme <thomas.preudho...@arm.com> 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. > >Now I realize that said like this it sounds more like stage1 material. > >Would it be fine for next stage1?
No, I think the patch is fine as-is now. Thanks, Richard. >Best regards, > >Thomas
