[MLton] fixing -codegen c -profile time for the release

[Matthew Fluet]

> It isn't luck :) I mean I am lucky, but the design
> is almost certain to prevent optimisation.

You're still walking on thin ice.

> The code is always a member of a C++ class
> virtual non-static member function, and it is not
> called in the same compilation unit

Same with MLton: Each .c file that MLton emits for the C-codegen contains 
exactly one (non-recursive) non-static C function.

> Also the code is entirely free of any C loops and blocks.
> Felix generates flat code with gotos exclusively.

Same with MLton: it is very easy for gcc to recompute (simple) loop 
structures from unstructured code.

> And finally .. Felix already does much more aggressive
> inlinling than gcc does (it inlines EVERYTHING!! Well,
> almost .. :)

Same with MLton: the C functions we produce can be many hundreds of lines 
long, much too large to be inlined into any other piece of code.

> None of this is true for functions .. but I only use
> assembler labels in procedures -- to support fast
> resumption of microthreads by computed gotos.
>
> I understand why the example you gave could fail.

Florian's example was very small to demonstrate the problem.  But the 
realization of the problem in MLton's emitted code shows that gcc is being 
a lot more aggressive in it's optimizations.  Note that gcc is well within 
its rights to transform:

  void foo() {
    body
  }

to

  void foo() {
    static int _z = 1;
    _z = (_z + 1) % 2;
    if (_z) {
      body
    } else {
      copy_body
    }
  }

where 'copy_body' is identical to 'body' except that C labels are renamed. 
(Granted, this ruins your code size and instruction cache behavior, but it 
is semantically equivalent to the original function.)  Now your assembler 
label is repeated, yielding an assembler error.

So, I don't see any way to prevent gcc from duplicating code, though you 
can easily prevent gcc from dropping code.