Re: Question about simplify_cond_and_lookup_avail_expr

[Jeffrey A Law <law at redhat dot com>]

On Mon, 2004-11-29 at 11:58 -0800, Devang Patel wrote:
> On Nov 24, 2004, at 6:09 PM, Andrew Pinski wrote:
> 
> > No this is in the wrong place, this should be done by a tree combiner.
> 
> Tree combiner is mentioned many times but I do not understand its role 
> clearly. What is it suppose to do?
It's basically the same as the RTL combiner.  It would take a series of
dependent expressions combine them into a single expression and try
to simplify it.

There are a few possible outcomes:

  1. The result can be simplified and it simplifies into a gimple
     expression.

  2. The result can be simplified, but it does not simplify into
     a gimple expression.  However, we may be able to gimplify
     the expression and still end up with something that is better
     than the original series of expressions (this is similar to 
     the 3->2 insn combinations in the RTL combiner)

  3. The result simplifies, but gimplification doesn't produce
     a series of statements that is cheaper than the original.

  4. The result does not simplify.

Cases 1 & 2 are wins.  Cases 3 & 4 do not win and we would not change
the IL in those cases.

One trivial example would be the reassociation done by the dominator
optimizer.

  t = a + C1
  res = t + C2

A tree combiner would turn that into

  res = a + C3  /* Where C3 is C1 + C2 computed at compile time */

Or consider a couple typecasts in series:

  t = (type1) a;
  res = (type2) t;
  

Depending on the types of a, type1 and type2, we may be able to simplify
that into

  res = (type2) a;

This happens often enough that I nearly wrote an optimizer to deal
with it explicitly.
 


Everything in the forward propagation pass (and the proposed extensions
to it is) just a specialized form of tree combination.

And the list of goes on and on and on.

jeff