[Vm-dev] -ftlo option (link-time optimizer)

[Eliot Miranda]

Hi Ben,

On Fri, Jan 4, 2019 at 8:32 PM Ben Coman <btc at openinworld.com> wrote:

>
> I was reading https://sogilis.com/blog/wrong-usage-of-extern-keyword-in-c/
> and first I heard of -ftlo flag for link-time optimizer and it providing
> additional type checking.  I was curious if we used it?
>

No, and I would counsel that we don't.  Link-time optimization is
implementation-defined and so could have various effects on the binary.
There are some convenient implicit assumptions in the VM that there's a
slim chance could be violated.  For example, the primitiveFunctionPointer
is tested and it is assumed that any value above 519 is a function pointer,
and any value less than or equal is a quick primitive index (a primitive
that answers an inst var or one of a handful of constants).  This
eliminates the need to maintain primitiveIndex and primitiveFunctionPointer
in the method cache and shrinks it from eight slots per entry to four.
This hence significantly speeds up primitive dispatch in the
StackInterpreter.  But it is the kind of hack that *could* be violated by
too aggressive an optimizer.  The VM is in the business of executing
Smalltalk quickly, and that may not be fully aligned with executing its C
code quickly. IME it is best to be a little conservative with the C level
optimizations and be aggressive with the VM's own
algorithmically/representationally implemented optimizations.

Of course, once the JIT is involved, the system is spending less and less
time in compiled C and more and more time in generated machine code.  At
that point C love; optimizations have less and less effect on overall speed.

None of the above applies to the C code for the GC or for individual
plugins.  But since the GC tries hard to take a small percentage of overall
execution time anyway, use of aggressive optimization therein shouldn't pay
back huge dividends.  If one can show that for a particular *external*
plugin (a separate shared object/dll) I would have no objection to it being
more aggressively optimized.

And I am happy to be proved wrong.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190104/46016ae4/attachment-0001.html>