This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: pr26026: udiv and umod optimization
- From: Jeffrey A Law <law at redhat dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 13 Mar 2006 16:56:32 -0700
- Subject: Re: pr26026: udiv and umod optimization
- References: <20060203122932.GB15321@bubble.grove.modra.org> <17379.30955.436649.904253@zapata.pink> <43E3835F.2090205@lu.unisi.ch> <20060205023311.GJ15321@bubble.grove.modra.org> <1139250389.3012.9.camel@localhost.localdomain> <20060209111511.GA18809@bubble.grove.modra.org> <1139499321.2874.110.camel@localhost.localdomain> <20060211055331.GD18809@bubble.grove.modra.org>
- Reply-to: law at redhat dot com
On Sat, 2006-02-11 at 16:23 +1030, Alan Modra wrote:
> On Thu, Feb 09, 2006 at 08:35:20AM -0700, Jeffrey A Law wrote:
> > The second alternative would be to walk the def-use chain back one
> > step for the divisor and see if the divisor is set from a 1 << X
> > style operation. This would be trivial to implement inside the
> > existing simplification code.
>
> Like so? My first foray into tree-ssa, so I won't be surprised if
> there is a better way to do this.. Bootstrapped and regression tested
> powerpc64-linux.
>
> PR tree-optimization/26026
> * tree-vrp.c (simplify_div_or_mod_using_ranges): Replace rhs_code
> param with is_div. Support optimisation of div and mod by
> power of two shifted left a variable amout. Tidy.
> (simplify_stmt_using_ranges): Similarly. Also support FLOOR_DIV_EXPR
> and FLOOR_MOD_EXPR.
Yes, this was basically what I was looking for. Unfortunately, I
haven't found any real code which would be optimized by this that
isn't already caught by the existing code in fold-const.c or
tree-vrp.c. That was still true after I trivially enhanced the
code to walk backwards through copy chains and nop type casts in
the hope of finding temp = x << y; statements.
Most of the time following the chains back eventually led us to
a parameter, a memory load or some arithmetic operation which
couldn't be trivially determined to give a power of two result.
Occasionally they led to an ASSERT_EXPR, but I doubt following
those backwards would find anything useful. Several others
led us back to a call.
Major sigh. I suggest we table the vrp enhancement and just rely
on your code in fold-const.c and the existing DIV/MOD optimization
support in tree-vrp.c
Thanks for taking the time to cobble this together though. Sorry
it was a rathole.
jeff