<HTML>
Updated https://bugs.freepascal.org/view.php?id=34628 - new "overhaul-mov-refactor.patch" that now changes "movl addl movq" to "addl" (and equivalently with "incl"). Currently the patches only apply to x86_64, but i386 is ready for upload if approved... much less splitting involved!<br>
<br>
<div>Gareth aka. Kit</div><div><br>
</div><div>P.S. To the moderators... I believe there's a message in the moderation queue because it contains a 60kb attachment (a patch file).<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Sat 22/12/18 20:28 , "J. Gareth Moreton" gareth@moreton-family.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
Saying that, it might not be a bug but a design choice. If the compiler is able to extend the variable to 64 bits on the stack, it will do, including the use of "incq" over "incl" - whenever I try to exploit the upper 32 bits, the compiler is too smart for that!<br>
<br>
The only problem is that it can hinder the peephole optimiser, and if I put in an exception that optimises, say, "movl addl movq" to "addl" or "incl" or whatnot, then that could be exploited. I'll have a think in regards to what to do with that one.<br>
<div><br>
</div><div>Gareth aka. Kit<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Sat 22/12/18 20:04 , "J. Gareth Moreton" gareth@moreton-family.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
Have to apologise again for my web client making life difficult for the mail archive system.<br>
<br>
Currently I'm a little reluctant to put in the "incq" fix because the code isn't equivalent. More than anything, it's a very minor bug with the node system in that it writes the full 64-bit register instead of the 32-bit register for LongInts and LongWords, it seems. I might be able to exploit the bug in a very narrow range of circumstances, and if I'm able to make a reproducible test case, I'll report it.<br>
<br>
Nevertheless, if I'm not able to exploit it, it's something that might be worth fixing if only because it will make optimisation easier and correct.<br>
<br>
<div>Also note that "INC" is generally only generated if you're optimising for size, because modern CPUs work better with "ADD" due to how it modifies the RFLAGS register.<br>
<br>
For the overhaul in general, I have it ported over to i386 on my working branch, since I've got x86_64 working without any breaking bugs.<br>
<br>
Even if just for a temporary debugging measure, I'm considering options to allow the writing of node trees to an XML file or some such, since I think this will allow easier debugging of that part of the compiler.<br>
<br>
</div><div>Gareth aka. Kit<br>
</div>
_______________________________________________<br>
fpc-devel maillist - <a href="javascript:top.opencompose('fpc-devel@lists.freepascal.org','','','')">fpc-devel@lists.freepascal.org</a><br>
<a target="_blank" href="<a href=" http:="" lists.freepascal.org="" cgi-bin="" mailman="" listinfo="" fpc-devel"="">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span><br>
<br>
</blockquote>
_______________________________________________<br>
fpc-devel maillist - <a href="javascript:top.opencompose('fpc-devel@lists.freepascal.org','','','')">fpc-devel@lists.freepascal.org</a><br>
<a target="_blank" href="parse.php?redirect=<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a><br>
<br>
</blockquote></HTML>