This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GCC] Simplification of 1U << (31 - x)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: Sudi Das <Sudi dot Das at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>
- Date: Thu, 13 Apr 2017 13:21:51 +0200
- Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 94EB618E3C7
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 94EB618E3C7
- References: <AM5PR0802MB2610B3E04DF2484B04208CEC83020@AM5PR0802MB2610.eurprd08.prod.outlook.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Apr 13, 2017 at 11:16:08AM +0000, Wilco Dijkstra wrote:
> >On Wed, Apr 12, 2017 at 09:29:55AM +0000, Sudi Das wrote:
> > > Hi all
> > >
> > > This is a fix for PR 80131
> > > Currently the code A << (B - C) is not simplified.
> >> However at least a more specific case of 1U << (C -x) where C = precision(type) - 1 can be simplified to (1 << C) >> x.
> >
> > Is that always a win though?
>
> Yes assuming left and right shift have the same performance.
>
> > Some constants have higher costs than others on various targets, some
> > significantly higher. This change might be beneficial only
> > if if C is as expensive as 1, then you get rid of a one (typically cheap)
> > operation.
>
> Most targets can create the constant cheaply. Targets that can't would need 2
No. Some constants sometimes even 7 instructions (e.g. sparc64; not talking
in particular about 1ULL << 63 constant), or have one instruction
that is more expensive than normal small constant load. Compare say x86_64
movl/movq vs. movabsq, I think the latter has 3 times longer latency on many
CPUs. So no, I think it isn't an unconditional win.
Jakub