This is the mail archive of the
mailing list for the GCC project.
Re: PR/18308: ice-on-valid because of non-GIMPLE
- From: Jeffrey A Law <law at redhat dot com>
- To: Devang Patel <dpatel at apple dot com>
- Cc: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Roger Sayle <roger at eyesopen dot com>
- Date: Mon, 03 Jan 2005 21:14:10 -0700
- Subject: Re: PR/18308: ice-on-valid because of non-GIMPLE
- Organization: Red Hat, Inc
- References: <Pine.LNX.firstname.lastname@example.org> <41D27969.email@example.com> <DD8A7DBC-5A0E-11D9-B498-000393A91CAA@apple.com>
- Reply-to: law at redhat dot com
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
> > 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.