This is the mail archive of the
mailing list for the GCC project.
Re: PR/18308: ice-on-valid because of non-GIMPLE
- From: Roger Sayle <roger at eyesopen dot com>
- To: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 29 Dec 2004 03:46:20 -0700 (MST)
- Subject: Re: PR/18308: ice-on-valid because of non-GIMPLE
On Wed, 29 Dec 2004, Paolo Bonzini wrote:
> > 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.
In addition to the examples you give, another common source of
non-gimple and/or non-folded trees in the RTL expanders is the RTL
expansion process itself. Its not unusual for expanders to create
temporary trees to be expanded immediately. This code is neither
large nor unmaintainable, and I'd far rather improve the quality of
the initial RTL we generate, than to rely on the RTL optimizers to
clean things up, and thereby be forced to keep entire RTL passes.
> I'll prepare an updated patch and link it to the 4.1 metabug.
I'm happy to consider ICEing in dojump.c a regression for GCC 4.0;
We've never ICE'd on a COND_EXPR in do_jump in any previous release.
Please bootstrap and regression test an updated patch, and if/when
it completes without any new failures, repost it to gcc-patches.
Thanks in advance,