Re: [DotGNU]gcc?

[Fergus Henderson]

On 05-Nov-2001, Rhys Weatherley <address@hidden> wrote:
> In my defence, I have since discovered that peephole
> optimization isn't very effective on IL.  And so adding
> such an optimizer to the assembler wouldn't help much.

This is true.

However, there are more sophisticated optimizations that could help.

Really what I'd like is an IL-to-IL optimizer.  It doesn't have to go
in the assembler, but putting it rather than in a separate program would
save some I/O and parsing.

The point here is just to share infrastructure between different compilers
that target IL, rather than having each compiler writer implement their own
IL->IL optimization passes.

> Is there a particular IL optimization that Mercury would
> benefit from?

There's a few that might help:

        - Common sub-expression elimination.
        We sometimes generate repeated occurrences of the same
        `castclass' expression.

        - Local variable elimination.
        We sometimes generate code which loads a value,
        stores it into a local variable, loads the value
        from the variable again, and doesn't look at the value
        of the local variable again afterwards.
        In such cases, it's often possible to eliminate
        the store, the second load, and the variable itself.

        - Dead store elimination.
        We sometimes generate code which loads a value,
        stores it into a local variable, and doesn't look at the
        value of the local variable again afterwards.
        In this case, the load, the store, and the variable
        can all be eliminated.

        - Elimination of branches around branches.
        We sometimes generate code such as this:
                br label2
                label1:
                label2:
        The `br label2' instruction can be optimized away.

        - Jump threading (elimination of branches to branches).

There are some others, such as optimizing redundant `castclass'
instructions, which might have been useful once but which we already
do in our front-end now anyway.

Now, that said, I don't think any of this is a high priority right now.
Obviously getting all it working first is much more important than
worrying about optimizations.
And I don't want to give the impression that I'm demanding
lots of features while not contributing any code myself --
please take my proposals as design suggestions, not demands! ;-)

P.S. Thanks for your work on Portable.NET, and especially for
your quick response to bug reports -- I've reported three or four
bugs now, and I think they've all been fixed within 24 hours.  Thanks!

-- 
Fergus Henderson <address@hidden>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth