This is the mail archive of the
mailing list for the GCC project.
Re: ifcvt/crossjump patch: Fix PR 42496, 21803
On 07/27/10 16:45, Bernd Schmidt wrote:
On 07/28/2010 12:18 AM, Eric Botcazou wrote:
I wrote "this kind of transformations", not "all transformations".
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.
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 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.
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?