This is the mail archive of the
mailing list for the GCC project.
Re: PR/18308: ice-on-valid because of non-GIMPLE
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: Roger Sayle <roger at eyesopen dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 29 Dec 2004 10:31:21 +0100
- Subject: Re: PR/18308: ice-on-valid because of non-GIMPLE
- References: <Pine.LNX.firstname.lastname@example.org>
Might I strongly recommend that if we're reversing that previous
decision, and wish to allow do_jump to handle COND_EXPR again,
that we additionally revert the <COND_EXPR> part of the patch cited
above, i.e. the relevant hunks of "cvs diff -r1.27 -r1.26 dojump.c".
It would be a shame to so easily lose some of GCC's optimizations.
While I cannot but agree with you on the last sentence, I still hope
that somewhen the pattern matching in the expander can be removed, while
not losing the optimization opportunities that TER exposes. It would be
interesting to know how many SPEC points TER makes us gain. Andrew
Pinski's tree combiner might change numbers significantly, too.
Also, the support data structures that are used expression replacement
may help in the implementation of Aho expression reordering (one of your
plans, IIRC), because unlike in the expander you still have access to
the expressions as quadruples, rather than as complex trees.
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. It looks like phiopt is essentially a fold()
on COND_EXPRs that if-conversion produces, and that could expose more
I'll prepare an updated patch and link it to the 4.1 metabug.