This is the mail archive of the gcc-patches@gcc.gnu.org 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]

ifcvt.c fix (was: Re: 4 GCC regressions, 1 new, with your patch on2001-07-28T03:15:01Z.)


On Tue, 31 Jul 2001, DJ Delorie wrote:
> > The new failures are:
> > powerpc-eabisim gcc.sum gcc.c-torture/execute/compndlit-1.c
>
> This fixes that regression (tested on powerpc-eabi, no regressions)
> but when I originally added those lines I recall that *not* changing
> cond_earliest caused some unneeded insns to be left around. Comments?
> Else, ok to apply?
>
> The problem in compndlit-1.c is that one of the insns that assigns a
> constant to a register (which is then used in a comparison) gets
> *moved* (not deleted) to somewhere after the compare, making the
> comparison meaningless.  I don't truly grok why.

I see this on mmix-knuth-mmixware too.  It's actually the
compare that moved before the constant. :-)

In my case (which seems to match yours), noce_get_alt_condition
is called from noce_try_minmax, the second transformation
attempt in noce_process_if_block.  A while after the
noce_get_alt_condition the noce_try_minmax attempt failes
because it doesn't match.  Later on, noce_try_cmove is attempted
and succeeds.  When applying that transformation, insns are
inserted *before* if_info->cond_earliest (the (set (reg)
(const_int)) insn).  Since the emitted insns were generated from
if_info->cond and so refer to the needed register with the
constant, boom.

> 	* ifcvt.c (noce_get_alt_condition): Don't make an auxiliary
> 	set from a constant part of the condition.

While your patch fixes this failure, I think another change
might be better; let noce_get_alt_condition set if_info->cond
too, keeping if_info consistent.  I haven't tested that
approach, though.

Still another additional change seems to make sense: factor out
the noce_get_alt_condition calls from noce_try_minmax and
noce_try_abs into their caller, noce_process_if_block.  Then
if-conversions (existing and future ones) wouldn't either have
to look around for the logical compare operands or fail the
optimization because they don't find a compare with a constant.

brgds, H-P


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