Re: [PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-22 Thread Richard Guenther
On Tue, May 22, 2012 at 2:50 PM, Ulrich Weigand wrote: > Richard Guenther wrote: > >> Btw, reassoc (and your patch?) would have the issue that for >> a + (b + c) - a it would yield b + c as result which is not an atom >> (but still ok, since it is a pre-existing value that is computed in the IL >>

Re: [PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-22 Thread Ulrich Weigand
Richard Guenther wrote: > Btw, reassoc (and your patch?) would have the issue that for > a + (b + c) - a it would yield b + c as result which is not an atom > (but still ok, since it is a pre-existing value that is computed in the IL > already). The simple forwprop matching catches this as it doe

Re: [PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-22 Thread Michael Matz
Hi, On Tue, 22 May 2012, Richard Guenther wrote: > > I had thought of that as well.  But it is not quite that simple -- the > > problem is that tree-ssa-reassoc.c as part of its core algorithm > > reassociates > > expressions all the time while even still building up the tree, see e.g. > > linea

Re: [PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-22 Thread Richard Guenther
On Tue, May 22, 2012 at 2:04 PM, Richard Guenther wrote: > On Tue, May 22, 2012 at 1:58 PM, Ulrich Weigand wrote: >> Richard Guenther wrote: >>> On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand >>> wrote: >>> > The following patch rewrites associate_plusminus to remove all the >>> > explicitly

Re: [PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-22 Thread Richard Guenther
On Tue, May 22, 2012 at 1:58 PM, Ulrich Weigand wrote: > Richard Guenther wrote: >> On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand wrote: >> > The following patch rewrites associate_plusminus to remove all the >> > explicitly coded special cases, and instead performs a scan of the >> > plus/min

Re: [PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-22 Thread Ulrich Weigand
Richard Guenther wrote: > On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand wrote: > > The following patch rewrites associate_plusminus to remove all the > > explicitly coded special cases, and instead performs a scan of the > > plus/minus tree similar to what is done in tree-ssa-reassoc (and also

Re: [PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-22 Thread Richard Guenther
On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand wrote: > Richard Guenther wrote: >> On Thu, Mar 8, 2012 at 3:29 PM, Ulrich Weigand wrote: >> > - Should I try to improve forwprop to handle casts and additional re- >> > association cases until it handles the above expression? >> >> Yes, ideally by

Re: [PATCH] Improved re-association of signed arithmetic

2012-05-21 Thread Richard Guenther
On Fri, May 18, 2012 at 11:13 PM, Robert Dewar wrote: > On 5/18/2012 4:27 PM, Ulrich Weigand wrote: > >> I finally got some time to look into this in detail.  The various special- >> case transforms in associate_plusminus all transform a plus/minus >> expression >> tree into either a single operan

Re: [PATCH] Improved re-association of signed arithmetic

2012-05-18 Thread Robert Dewar
On 5/18/2012 4:27 PM, Ulrich Weigand wrote: I finally got some time to look into this in detail. The various special- case transforms in associate_plusminus all transform a plus/minus expression tree into either a single operand, a negated operand, or a single plus or minus of two operands. Th

[PATCH] Improved re-association of signed arithmetic (was: Inefficient end-of-loop value computation)

2012-05-18 Thread Ulrich Weigand
Richard Guenther wrote: > On Thu, Mar 8, 2012 at 3:29 PM, Ulrich Weigand wrote: > > - Should I try to improve forwprop to handle casts and additional re- > > association cases until it handles the above expression? > > Yes, ideally by trying to sub-divide this task into separate profitable > tran