Question about simplify_cond_and_lookup_avail_expr

[Devang Patel]

On Nov 29, 2004, at 12:13 PM, Jeffrey A Law wrote:

> 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.

Thank you guys.
-
Devang