This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Don't check for optab for 16bit bswap
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>, Oleg Endo <oleg dot endo at t-online dot de>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 21 Jan 2015 11:16:16 -0800
- Subject: Re: [PATCH] Don't check for optab for 16bit bswap
- Authentication-results: sourceware.org; auth=none
- References: <000401d02370$6167b440$24371cc0$ at arm dot com> <FCA0702A-77A7-4DFC-A504-F45C515B4538 at suse dot de> <000601d02390$51fc5ae0$f5f510a0$ at arm dot com> <1419878653 dot 8915 dot 112 dot camel at yam-132-YW-E178-FTW> <65636772-3D4C-43B7-9511-E833B90B4AD8 at suse dot de> <1419956711 dot 2473 dot 4 dot camel at yam-132-YW-E178-FTW> <000701d028f7$88fa69d0$9aef3d70$ at arm dot com> <A7F91E14-3B3E-4BD1-8061-F57DB23150B2 at suse dot de>
On Mon, Jan 5, 2015 at 1:09 PM, Richard Biener <rguenther@suse.de> wrote:
> On January 5, 2015 3:54:40 PM CET, Thomas Preud'homme <thomas.preudhomme@arm.com> wrote:
>>> From: Oleg Endo [mailto:oleg.endo@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.