This is the mail archive of the
mailing list for the GCC project.
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!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.
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?