On Mon, Jan 5, 2015 at 1:09 PM, Richard Biener <rguent...@suse.de> wrote: > 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.
Does it cause: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64718 -- H.J.
