Re: [DotGNU]gcc?

[Rhys Weatherley]

Fergus Henderson wrote:

> On 06-Aug-2001, Rhys Weatherley <address@hidden> wrote:
> > I've actually faced a similar issue in Portable.NET's
> > assembler.  I considered putting peephole and other
> > optimizations into the assembler, rather than into the
> > main C# compiler.  But then I realised that proprietary
> > vendors could use this to get highly-optimised code
> > out of a poor front-end.  i.e. they get good code without
> > working hard for it.
>
> Hmm...  so you decided to deliberately choose a technically sub-optimal
> design, because you were worried that proprietry software might benefit
> from your work?  <Arghhh>

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.

Peephole optimization is only effective where there are
2 or more ways of doing the same thing, some of them
shorter than others.  This is the case in the JVM, but not
in IL.  e.g. in the JVM, one can collapse the following:

iload_2
iconst_1
iadd
istore_2

to:

iinc 2,1

IL does not have a short-cut increment instruction, and
so it isn't possible to perform the same optimization in
the bytecode.  The optimization must be deferred to the
runtime engine, which presumably has a native peephole
optimizer within its JIT.

The only optimizations that are effective are those that
shorten variable access and branch instructions.  e.g. there
are 6 instructions to load a local, depending on the index.
Branch instructions have two forms: short and long.
I already shorten these, although Microsoft's assembler
doesn't.

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

Cheers,

Rhys.