This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH] Further improve VRP BIT_AND_EXPR and BIT_IOR_EXPR handling (PR tree-optimization/28632)

From: Jeff Law <law at redhat dot com>
To: Jakub Jelinek <jakub at redhat dot com>
Cc: gcc-patches at gcc dot gnu dot org, aldot at gcc dot gnu dot org, Denys Vlasenko <dvlasenk at redhat dot com>
Date: Mon, 12 Jul 2010 11:30:46 -0600
Subject: Re: [PATCH] Further improve VRP BIT_AND_EXPR and BIT_IOR_EXPR handling (PR tree-optimization/28632)
References: <20100709191153.GQ20208@tyan-ft48-01.lab.bos.redhat.com>

On 07/09/10 13:11, Jakub Jelinek wrote:

Hi!

When writing the last VRP BIT_AND_EXPR patch, I wasn't aware of this PR.
Looking at it there indeed are further possibilities for optimizations,
both for BIT_AND_EXPR and also BIT_IOR_EXPR.  For the latter, e.g. we used
to derive from [0x400, 0x40f] | [0x800, 0x80f] a [0x800, 0xc0f]
range, while this patch computes [0xc00, 0xc0f] range.
The new helper function might be useful even when optimizing away useless
BIT_AND_EXPR or BIT_IOR_EXPRs.

Bootstrapped/regtested on x86_64-linux and i686-linux. Ok for trunk?

If you wanted to get ambitious, you could go through all the zero/nonzero bit stuff in combine.c and translate it to VRP style. It'd be interesting to know how many of those transformations trigger on the higher level IR.

Jeff

References:
- [PATCH] Further improve VRP BIT_AND_EXPR and BIT_IOR_EXPR handling (PR tree-optimization/28632)
  - From: Jakub Jelinek

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]