On Tue, May 6, 2008 at 9:28 AM, Ramana Radhakrishnan <[EMAIL PROTECTED]> wrote: > > 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)
We don't do this at the moment, but yes, some canonicalization usually helps at least to keep code simple. Richard.
