<div dir="ltr"><div dir="ltr"><div dir="ltr">H Nicolas,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2020 at 2:55 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <div dir="ltr">Hi all,<br>I have practically solved <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/443" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/443</a> for passing/returning struct by value on X64SysV FFI.<br><br>I still have a few cases of packed struct or union to handle, but I know how to handle them and finish the job.<br><br>Practically, but not yet... There is an issue that I can't easily solve: slang inlining.<br><br>The generated code works on fast VM, but not debug nor assert...<br>It does not work because #ffiCalloutTo:SpecOnStack:in: is not inlined.<br>Since it uses sender's alloca as stack pointer (where FFI argVector was marshalled), it obviously will mess the stack if not inlined!<br><br>The code is not inlined because a sub-function sends a recursive message .<br>Unfortunately I have to check struct alignment for correctly determining the type of 8-byte registers, and algorithm for checking struct alignment is recursive because we must first check alignment of sub-struct....<br><br>Having a recursive function should not be a problem, just don't inline it, but invoke it.<br>Unfortunately, our strategy is to inline only sends that can be completely inlined (and recursively for every sub-send).<br></div></blockquote><div><br></div><div>What's the recursive function?  That should be marked as not inalienable (<inline: #false>.  And <span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">#ffiCalloutTo:SpecOnStack:in: should be marked as <inline: true> or <inline: #always>.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">So I'm currently blocked...<br></div></blockquote><div><br></div><div>We could pair later on today or early (my time) tomorrow.  Right now I'm busy with my day job and so can't spend significant time right now.  Feel free to email me the change set to look at too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'd like to specify to not inquire further sends that explicitely refuse to be inlined, maybe in the unless block in checkForCompletenessIn:<br><br>parseTree<br>        nodesDo:<br>            [:node|<br>             ...snip...]<br>        unless:<br>            [:node|<br>            node isSend<br><div>            and: [node selector == #cCode:inSmalltalk:</div><div>               <b> or: [node explicitelyRefuseToBeInlined</b><br></div><div>                or: [aCodeGen isAssertSelector: node selector]]]].</div><div><br></div><div>Thoughts?<br></div><br></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_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></div>