Re: GCC build failed for powerpc-eabisim with your patch on 2002-06-13T18:40:10Z.

[Roger Sayle <roger at eyesopen dot com>]

> > > For at least the 950612, the code appears to still be valid, but it trips
> > > an assembler warning.  I'm in the process of verifying whether or not the
> > > other regressions are of a similar nature.
> >
> > I'll try building a mips-elf simulator and bootstraping an IRIX 6.5
> > system to see if I can figure out whats going on.  This is a bit
> > odd though, my 2002-06-13 cleanups shouldn't have affected any
> > behaviour (unless the MIPS backend explicitly disables if-conversion,
> > or cleanup_cfg isn't idempotent, i.e. running it more than once has
> > an observable effect on MIPS).
>
> The "trick" is that the code now cleans up the CFG even if we're not
> optimizing.
>
> Optimizing the CFG inverts a conditional branch (which allows it to eliminate
> a jump).
>
> The conditional branch has a value that is trivially computed at compile time,
> but because we're not optimizing we don't eliminate it.
>
> Worse yet, when you emit the branch as it was rewritten by the CFG optimization
> code, the assembler realizes the branch is a compile-time constant.  And lamely
> the assembler decides to warn you that you just emitted a branch that is
> either always taken or always not taken (I don't recall which).
>
> Fixing this may be as simple as making the call to cleanup_cfg be conditional
> on optimization being enabled.  Of course, someone should fix the lame-o
> assembler from issuing this kind of silly warning.
>
> Anyway, in the mean time I'm verifying that this problem is indeed what
> is causing the various MIPS failures from the regression tester.

Hi Jeff,

Another possible solution might be to modify the patterns in mips.md
to emit an unconditional branch if this is trivially obvious from the
conditional jump's operands.

Roger
--