<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Clément, Hi Nicolas,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2019 at 4:47 AM Clément Béra <<a href="mailto:bera.clement@gmail.com">bera.clement@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="auto"><div>Thanks Nicolas for your reply.</div><div dir="auto"><br></div><div dir="auto">That means that basically we make a copy of the whole array to read a single field. </div><div dir="auto"><br></div><div dir="auto">I was initially confused because copying the whole array looks expensive, but I guess all C compilers are able to remove the unused copy (everything is unused besides the field read).</div></div></blockquote><div><br></div><div>For example:<br>=========8<======== dpint.c =========8<========<br>typedef union { long l; double d; } Punner;<br>unsigned long uv(double d) { return d; }<br>signed long iv(double d) { return d; }<br>unsigned long ivp(double d) { Punner punner; punner.d = d; return punner.l; }<br>double dv(long l) { return l; }<br>double du(unsigned long l) { return l; }<br>double dvp(long l) { Punner punner; punner.l = l; return punner.d; }<br>=========8<======== dpint.c =========8<========<br>aarch64-none-elf-cc -O4 -S dpint.c (a cross compiler version of gcc 7.2.0 for ARMv8 on MacOS)<br>=========8<======== dpint.s =========8<========<br>uv:<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>fcvtzu x0, d0<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ret<br>iv:<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>fcvtzs x0, d0<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ret<br>ivp:<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>fmov x0, d0<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ret<br>dv:<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>scvtf d0, x0<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ret<br>du:<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ucvtf d0, x0<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ret<br>dvp:<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>fmov d0, x0<br><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ret<br>=========8<======== dpint.s =========8<========</div><div> </div><div>This is a quick and easy way of finding out the assembler mnemonics for float <-> integer conversion/moves. Far easier (and sometimes faster) than searching through a 7,900 page manual (!?!?!?!?)</div><div><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="auto"><div dir="auto"><br></div><div dir="auto">Best,<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Dec 18, 2019, 10:43 Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">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"><div>Hi Clement,</div><div>I need more context to answer your question.</div><div>We need to declare an automatic (local) variable for holding the content.</div><div>Here I understand that bits has to be re-interpreted as an array of int: we need to know the length of this array.</div><div>If we can't determine the length at compile time, this is going to be tricky...</div><div><br></div><div>I have no VMMaker image handy, so I won't try to type the exact declaration stntax from memory,</div><div>but I can give you an equivalent for swapper in C if the purpose is to swap:</div><div><br></div><div><font face="monospace">int i[sizeof(double) / sizeof(int)];</font></div><div><font face="monospace">double d;</font></div><div><font face="monospace">memcpy(i,&d,sizeof(d));</font></div><div><font face="monospace">return i[1-index];</font></div><div><font face="monospace"><br></font>
</div><div>Usage of union for type puning is legal in C, at least up to C99.</div><div>It is not legal in C++: the compiler may assume that assigning swapper.d won't have any effect on swapper.i, et vice et versa.</div><div>We can use one field or the other but they must be considered unrelated.<br></div><div>hence it can eliminate some code or consider it invariant in loops and keep swapper.d and swapper.i in two different registers and never reload them from memory...<br></div><div>My only concern is if we want to use compiler with unclear standards (MSVC?)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 17 déc. 2019 à 20:05, Clément Béra <<a href="mailto:bera.clement@gmail.com" rel="noreferrer" target="_blank">bera.clement@gmail.com</a>> a écrit :<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 Nicolas, hi all,<div><br></div><div>Can you be more specific Nicolas on how to use memcpy to circumvent strict aliasing? What should the convention for the line:</div><div><font face="monospace">^ (self cCoerceSimple: (self addressOf: bits) to: #'int *') at: fieldIndex</font><br></div><div>? This:</div><div><font face="monospace">| res |</font></div><div><font face="monospace">self memcpy: (self addressOf: res) _: bits + (fieldIndex *4) _: 4.<br></font></div><div><font face="monospace">^ res</font></div><div>?</div><div><br></div><div>I've already seen union used in the VM to circumvent aliasing (Cf in sqMemoryAccess.h):<br><font face="monospace">/* this is to allow strict aliasing assumption in the optimizer */<br>typedef union { double d; int i[sizeof(double) / sizeof(int)]; } _swapper;</font><br></div><div><font face="monospace"><br></font></div><div><font face="arial, sans-serif">Not sure if we should do something about that right now.</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2019 at 8:58 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" rel="noreferrer" target="_blank">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"><div>Hi all, Eliot, Pablo,</div><div>we should review all the pointer aliasing that we are still depending upon, because it can strike anytime soon...</div><div>The recommended way is memcpy, so let's use that.</div><div>The alternative is type puning via union, but it's not legal on C++. If wanting to support exotic compiler (MSVC) which is mainly focused on C++, not modern C, it's safer to use memcpy.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 11 déc. 2019 à 20:00, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" rel="noreferrer" target="_blank">eliot.miranda@gmail.com</a>> a écrit :<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"> <br>
<br>
<br>
> On Dec 11, 2019, at 9:09 AM, "<a href="mailto:tesonep@gmail.com" rel="noreferrer" target="_blank">tesonep@gmail.com</a>" <<a href="mailto:tesonep@gmail.com" rel="noreferrer" target="_blank">tesonep@gmail.com</a>> wrote:<br>
> <br>
> Hi Eliot, you can use PT as initials (I don't if there is a clash or<br>
> ptesone) and the timestamp is just today.<br>
<br>
Thanks. And I’ll include your email on the GCC SSA. Thanks for tracking this down. This has been biting us for some time. There was a similar issue with accessing the two 32-bit halves of the 64-bit object header in Spur that meant I had to use a rewrite. I’ll try and dig it out. Perhaps we could collaborate on performing the same analysis and verifying that there is an issue with this header access code in gcc.<br>
<br>
> <br>
> Thanks<br>
> <br>
>> On Wed, Dec 11, 2019 at 6:02 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" rel="noreferrer" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
>> <br>
>> <br>
>> <br>
>> <br>
>>>> On Dec 11, 2019, at 8:45 AM, "<a href="mailto:tesonep@gmail.com" rel="noreferrer" target="_blank">tesonep@gmail.com</a>" <<a href="mailto:tesonep@gmail.com" rel="noreferrer" target="_blank">tesonep@gmail.com</a>> wrote:<br>
>>> <br>
>>> <br>
>>> Hi Ken,<br>
>>> this is a problem in an optimization of GCC 8.3 (I am not sure what<br>
>>> other versions are impacted).<br>
>>> Basically it is generating bad a function, removing code that assumes<br>
>>> that is dead code.<br>
>>> Even though this is a bug in GCC, because there is not actual reason<br>
>>> to remove the code.<br>
>>> It is produced because the code is not written in a nice way.<br>
>>> <br>
>>> Basically, if someone wants to fix it in the VM code is modifying a<br>
>>> single method:<br>
>>> <br>
>>> Spur64BitMemoryManager >> fetchLong32: fieldIndex ofFloatObject: oop<br>
>>> "index by word size, and return a pointer as long as the word size"<br>
>>> <br>
>>> | bits |<br>
>>> (self isImmediateFloat: oop) ifFalse:<br>
>>> [^self fetchLong32: fieldIndex ofObject: oop].<br>
>>> bits := self smallFloatBitsOf: oop.<br>
>>> ^ fieldIndex = 0<br>
>>> ifTrue: [bits bitAnd: 16rFFFFFFFF]<br>
>>> ifFalse: [bits >> 32]<br>
>> <br>
>> Thank you, Pablo. I’ll integrate this quickly. Can you possibly give me initials and time stamp? It’s not necessary but helps that the code is marked as being your fix.<br>
>> <br>
>>> <br>
>>> The old method had a handwritten piece of C code to replace the last if:<br>
>>> <br>
>>> (self cCoerceSimple: (self addressOf: bits) to: #'int *') at: fieldIndex<br>
>>> <br>
>>> I assume it was done to handle a different kind of endianness, but the<br>
>>> single sender of this message is already doing the handling and having<br>
>>> different behavior depending on the endianness.<br>
>>> <br>
>>> With this fix the build can still be executed with -O2 optimization in GCC 8.3<br>
>>> <br>
>>> Cheers,<br>
>>> <br>
>>>> On Sat, Dec 7, 2019 at 4:20 PM <<a href="mailto:ken.dickey@whidbey.com" rel="noreferrer" target="_blank">ken.dickey@whidbey.com</a>> wrote:<br>
>>>> <br>
>>>> <br>
>>>>> Have you tried switching off compiler optimisations?<br>
>>>> <br>
>>>> Ah! I had forgotten that one. I thought that was changed in mvm.<br>
>>>> <br>
>>>> Image works fine noe (but more slowly!) on aarch64 Alpine Linux<br>
>>>> (musl+busybox).<br>
>>>> <br>
>>>> I am just out the door fir a couple of days but will try fdlib on<br>
>>>> return.<br>
>>>> <br>
>>>> Thanks again to all!<br>
>>>> -KenD<br>
>>> <br>
>>> <br>
>>> <br>
>>> --<br>
>>> Pablo Tesone.<br>
>>> <a href="mailto:tesonep@gmail.com" rel="noreferrer" target="_blank">tesonep@gmail.com</a><br>
> <br>
> <br>
> <br>
> -- <br>
> Pablo Tesone.<br>
> <a href="mailto:tesonep@gmail.com" rel="noreferrer" target="_blank">tesonep@gmail.com</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" rel="noreferrer" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" rel="noreferrer" target="_blank">https://clementbera.wordpress.com/</a></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div></div></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></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>