On Mon, 2014-12-29 at 17:53 +0000, Thomas Preud'homme wrote: > > From: Richard Biener [mailto:rguent...@suse.de] > > Sent: Monday, December 29, 2014 5:09 PM > > > > OK, but what about targets without a rotation optab? Is the fallback > > expansion reasonable in all cases? > > To be honest I haven't checked. I thought being a treecode means it > can always be expanded, using a sequence of shift and bitwise or if > necessary. Isn't there some language that GCC support with rotate > operators? > > Given your question I guess I was wrong assuming this. Is there a list > of gimple construct that are necessary supported? What about a list > of insn pattern that a backend must necessarily provide? >
__builtin_bswap16 expansion uses the 'rotlhi3' pattern to do a 16 bit bswap as a fallback when there's no 'bswaphi2' pattern in the backend (like on SH at the moment. I haven't added bswaphi2, as __builtin_bswap16 has been working without it). 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 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). Cheers, Oleg
