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

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 optimization opportunities.

I'll prepare an updated patch and link it to the 4.1 metabug.


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