Re: [patch tree-optimization 2/2]: Branch-cost optimizations

[Kai Tietz <ktietz70 at googlemail dot com>]

2011/11/7 Richard Guenther <richard.guenther@gmail.com>:
> On Sun, Nov 6, 2011 at 11:17 PM, Kai Tietz <ktietz@redhat.com> wrote:
>> Hello,
>>
>> the second patch extends the tree-ssa-ifcombine pass so, that it chains up simple if-and/or-if patterns via associative bitwise-and/or operations. ?This allows for example optimization for cases like:
>>
>> if (c == 0) return 2;
>> if (c == 1) return 2;
>> if (c == 2) return 2;
>> ...
>>
>> as now reassociation-pass can optimize on them.
>
> err ... tree-ssa-ifcombine does exactly if "merging", why are you now
> adding a "merging" part!? ?The above description does not shed any
> light on this either. ?In fact the above example is something
> that should be optimized by phiopt.
>
> Richard.

Well, the example I provided might be not the best, as indeed phiopt
should handle this.  But if such if-and/or-if chains have for example
the kind
if (a == 0)
   return doo ();
if (a == 1)
  return doo ();

etc.  phiopt won't do much here.  The point why the joining of simple
if-and/or-if conditions via truth-bitwise operation is profitable in
general, is that range-analysis and other stanard reassoc-patterns
getting catched up by reassoc, without the need to duplicate all the
code all over each pass (what we actually doing right now).
The classical ifcombine pass itself has only one point it might be
more profitable over the reassoc pass. and this is if the conditions
might trap, as here indeed we can't transform to associative
bitwise-binary tree.

I put the ifjoining within this pass, as the joining and the merging
passes are sharing some code about pattern-matching for simple
if-and/or-if.  But well, it is easy to factor out here a separate
pass. An additional if-if joining pass might be even profitable after
loop-optimization, and after current first reassociation pass.

This current patch shows already on tests a significant reduction of #
branches.  Together with the BC code in cfgexpand it leads to a fair
reduction in instructions, and even lowers the amount of executed
instructions on extra dynamic condition significant

Regards,
Kai