Re: 4 GCC regressions, 2 new, with your patch on 2002-07-18T09:56:17Z.

[Jan Hubicka <jh at suse dot cz>]

> > We do lose since often peepholes are asking for flags to do something
> > smart (like using xor for loading zero). Whenever we place unnecesary
> > code in between flags setter and user we lose.
> 
> The peephole code is supposed to look at the data flow, so it
> shouldn't matter how many instructions are between the setter and user.

It is not the problem to find flags setter and flags user.  The problem
is following

compare instruction

a=a+1 produced by code motion

jump instruction using flags

Now the a=a+1 is represented as LEA instruction since code motion strips
down the flags clobber (this itself is wrong design, but I have separate
patch for this).  Peephole2 has a peephole that match such dummy LEAs,
checks whether flags register is dead and produces ADD if it is.
In this case it is not and we lose, in case we insert the instruction
before the compare we win.

Similar code is common over combine and some other optimization passes.

Even worse, many passes, like loop or ifcvt freely expects they can
insert new code in about any place in program.  They do use normal gen_*
machinery to produce new code and such new code can clobber flags for
i386.  The problem does not happen just before the jumps (only consumers
of flags) are the simple instrucitons we do not optimize in these cases
and the flags are always set just before the jump.
This is bad design, but I don't think we can easilly change it in this
release period. Aditionally I think it makes sense to maintain the case
of not extending flags registers lifetimes for performance reasons
explained above.
> 
> > I think we simply should not extend liveness of hard registers when it
> > is easy to go without (ie we do not lose the optimization).
> 
> I don't think your patch represents a good design.  If it's important
> to keep hard register lifetimes short, then that problem should be
> solved in a general way, not by having special code for just one case
> in just one of the many routines that insert insns.

How?
> 
> > > This code really doesn't feel right to me.  There could be many
> > > unexpected consequences.
> 
> For instance, you used single_set, but I think that's wrong in this
> case, because a CLOBBER might mean the instruction has a conflict with
> the insn you're moving over.

I don't think so.  THe instruction I am moving is storing into newly
allocated pseudo and has no side effect.
In the case it is valid to execute it after the instruction, it must be
valid to do so before.
> 
> I think you also don't check that the basic block actually has more
> than one insn.  What happens if first instruction in a program is a
> (conditional?) jump?

This is bug, I already noticed that. I can send updated patch in case we
will not find better sollution.

Honza
> 
> -- 
> - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>