<div dir="ltr"><div>Thanks Eliot & Nicolas.  Its always good to understand things in relation to specific circumstances.</div><div>cheers -ben</div><br><div class="gmail_quote"><div dir="ltr">On Sat, 5 Jan 2019 at 23:39, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="auto"><div dir="ltr">On Jan 5, 2019, at 2:17 AM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote type="cite"><div dir="ltr"><span></span></div></blockquote><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">I'm also thinking of this specific -flto enemy:</div><div dir="ltr"><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/1d97d7952e5707c383e9b32945c5c2341aa0f0e2/platforms/Cross/plugins/IA32ABI/x64win64stub.c" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/1d97d7952e5707c383e9b32945c5c2341aa0f0e2/platforms/Cross/plugins/IA32ABI/x64win64stub.c</a></div></div></div></blockquote><div><br></div>+1.  Right!  And that’s such a nice cheap hack to load the floating-point registers.  It would be completely broken because link-time optimization would simply delete the function call given that it has no explicit effect.<div><br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">Le sam. 5 janv. 2019 à 06:13, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr">Hi Ben,</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 4, 2019 at 8:32 PM Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr">I was reading <a href="https://sogilis.com/blog/wrong-usage-of-extern-keyword-in-c/" target="_blank">https://sogilis.com/blog/wrong-usage-of-extern-keyword-in-c/</a></div><div>and first I heard of -ftlo flag for link-time optimizer and it providing additional type checking.  I was curious if we used it?</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>And I am happy to be proved wrong.</div><div><br></div></div><div dir="ltr" class="gmail-m_-3267150912040186557gmail-m_-1205832446288742318gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
</blockquote></div>
</div></blockquote></div></div></blockquote></div></div>