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

[Nicolas Cellier]

I'm also thinking of this specific -flto enemy:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/1d97d7952e5707c383e9b32945c5c2341aa0f0e2/platforms/Cross/plugins/IA32ABI/x64win64stub.c

Le sam. 5 janv. 2019 à 06:13, Eliot Miranda <eliot.miranda at gmail.com> a
écrit :

>
> 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/20190105/996991cf/attachment.html>