Re: On killing SAVE_EXPR

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    No, a COMPOUND_EXPR can be re-evaluated many times without
    worrying about the side effects of evaluation on the tree
    representation itself.

It's not that simple, but I'll reply to that in the context of a later
message that I'll get to soon.

    Incidentally, a statement expression currently expands to an RTL_EXPR,
    which is worse than a SAVE_EXPR, in that it can only be evaluated once
    with no hope of fiddling state later.  This is another one I intend to
    axe.

Right, that is worse.

    > And now you lose optimization.  In the case where these are size or
    > offsets, usually knowing what the "initializing value", in your model,
    > is will allow significant optimizations.

    That's cse's job.

More like combine, but it's tricky.  We do a lot of multiplications, additions,
and divisions in size calculations.  Often they cancel each other out.
Yes, adding the SIZE_UNIT stuff lowered the impact of this, but not to anywhere
near zero.  Being able to do expression simplification is critical when the
size computations are at all complicated.

    The instance I'm most familiar is in tail-call elimination.  Here we
    generate two code sequences -- one as a normal call and one as a
    tail-call or tail-recursion.  At some point later we'll select one
    sequence or the other depending on whether the tail-call sequence is
    actually legitimate.

Well that one isn't a problem since you'll only select one to generate
code for.

    A third instance involves inlining at the tree level.  In this case
    we've spliced one function into others, potentially many times.
    Naturally all copies are present in the output.

Don't we *copy* trees in that case?