On Tue, May 6, 2008 at 8:11 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Mon, May 5, 2008 at 7:42 PM, Jim Wilson <[EMAIL PROTECTED]> wrote:
> > Pranav Bhandarkar wrote:
> >
> > > GCC 4.3 does fine here except when the operator is "logical and" (see
> > > attached. test.c uses logical and and test1.c uses plus)
> > >
> >
> > Logical and generates control-flow instructions, i.e. compares, branches,
> > and labels. This makes optimizing it a very different problem than
> > optimizing for plus.
> >
> > Try compiling with -fdump-tree-all and notice that the "gimple" dump file
> > already contains all of the control-flow expressed in the IL, which means
> > optimizing this is going to be very difficult.
> >
> > We could perhaps add a new high level gimple that contains the C language
> > && as an operator, run a CSE pass, and then later lower it to expose the
> > control flow, but that will be a lot of work, and probably won't give
> enough
> > benefit to justify it.
>
> There are a couple of things that can be done. One thing is building a
> canonical representation for && and || and their control-flow variants and
> doing optimizations on them. Another thing is to expose the actual
> conditions of the COND_EXPRs to the value-numberer, which means
> converting
>
> if (a > b)
>
> to
>
> cond_1 = a > b;
> if (cond_1)
>
> this way (partial) redundancies can be detected and optimized. Of course
> this may pessimize code in as many cases as it improves it.
Off the top of my head but would some sort of reassoc after removing
such (partial) redundancies help ?
i.e. after the redundancies are removed and the VN has done its magic .
merge
cond1 = a> b
if( cond1)
into if (a > b)
cheers
Ramana
>
> Richard.
>
>
>
> > It is simpler to rewrite the code. For instance if you change this
> > a[0] = ione && itwo && ithree && ifour && ifive;
> > to
> > a[0] = !!ione & !!itwo & !!ithree & !!ifour & !!ifive;
> > then you get the same effect (assuming none of the subexpressions have
> > side-effects), and gcc is able to perform the optimization. You also get
> > code without branches which is likely to be faster on modern workstation
> > cpus.
>
--
Ramana Radhakrishnan
