Re: ifcvt/crossjump patch: Fix PR 42496, 21803

[Jeff Law <law at redhat dot com>]

 On 07/27/10 16:45, Bernd Schmidt wrote:
> On 07/28/2010 12:18 AM, Eric Botcazou wrote:
> > > That's a non-argument, and false IMO.  Not every optimization can be
> > > represented cleanly as a set of CFG manipulations, and this one can't.
> > I wrote "this kind of transformations", not "all transformations".
> >
> > What about the algorithm sketched by Paolo?
> Paolo's "algorithm" was
> - split the destination BB before the jump (into BB11 and BB12)
> - split the source BBs after the last moved instruction (into BB21 and
> BB22, BB31 and BB32, etc.)
> - redirect the jumps to BBn1 (n>=2) to go to BBn2.
> - graft BB21 between BB11 and BB12, remove all BBn1 for n>2
>
> which has exactly the effect of one call to reorder_insns and a few more
> to delete_insn, except it creates lots of garbage BBs only to delete
> them immediately again.
>
> What exactly is gained by that?  Certainly not readability.  You're
> moving insns, so reorder_insns is the correct API.  The suggestion is
> obviously absurd in my eyes.

Can we all agree that the problem can be viewed as either cfg 
manipulations or insn movement and that what we're really arguing about 
is which is the most appropriate way to view the problem?

If so, then we really need to determine which implementation is the 
easiest to understand, implement & maintain.


> > I'm saying that optimizations run in cfgcleanup.c must play by the rules.
> If your "rules" lead to an absurd result, the rules are bogus.  Who
> decided those "rules" anyway?
I'm not aware of an such rule.   I can see the value in placing such 
rules on cfgcleanup.c's worker bees which is part of the reason why I 
originally suggested this optimization (if implemented as insn movement) 
be placed somewhere other than cfgcleanup.


Jeff