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: Richard Biener <rguenther at suse dot de>
- To: Thomas Preud'homme <thomas dot preudhomme at arm dot com>,'Oleg Endo' <oleg dot endo at t-online dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 05 Jan 2015 22:09:17 +0100
- 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>
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.
Thanks,
Richard.
>Best regards,
>
>Thomas