This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR/18308: ice-on-valid because of non-GIMPLE

On Wed, 2004-12-29 at 18:59 -0800, Devang Patel wrote:
> On Dec 29, 2004, at 1:31 AM, Paolo Bonzini wrote:
> > Another point: this PR (a combination of vectorization, which enables 
> > if-conversion, and loop unrolling) shows that COND_EXPR may now 
> > percolate to the expander even in the absence of vectorizable code.  I 
> > need to read the code, but I wonder exactly what is different between 
> > phiopt and if-conversion.
> AFAIU, phiopt does simple pattern matching to remove phi nodes whenever 
> possible (irrespective of loop structure) where as if-conversion tries 
> to make one block for entire loop body. if-conversion knows how to 
> update loop structure appropriately. My understanding is that phiopt 
> does not handle cases when basic block has more than one phi node 
> and/or when basic block has more than one statements (I have not read 
> phiopt code recently so I could be wrong). if-conversion is enabled 
> only when automatic vectorization is requested.
You're basically correct.  phiopt is a very very simple pattern
matching if-conversion pass.  It's extremely limited in what it
can/will do.

> >  It looks like phiopt is essentially a fold() on COND_EXPRs that 
> > if-conversion produces, and that could expose more optimization 
> > opportunities.
IIRC someone actually reimplemented phiopt using fold :-)  It's on
the list of things to examine once we start looking at 4.1 stuff.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]