Is it possible to still consider these changes? They do give big time savings when compiling large projects under x86_64 and a couple of the rewritten functions perform better in finding optimisations with jumps. I'm holding off doing additional peephole additions until I know whether this will be discarded or not, since any new changes will involve updating the patch files (which might have to be updated with the recent changes to the trunk).
Gareth aka. Kit On Sun 23/12/18 21:09 , "J. Gareth Moreton" gar...@moreton-family.com sent: > 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! > > Gareth aka. Kit > P.S. To the moderators... I believe there's a message in the moderation > queue because it contains a 60kb attachment (a patch file). > > On Sat 22/12/18 20:28 , "J. Gareth Moreton" gar...@moreton-family.com > sent: > 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! > > 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. > > Gareth aka. Kit > > On Sat 22/12/18 20:04 , "J. Gareth Moreton" gar...@moreton-family.com > sent: > Have to apologise again for my web client making life difficult for the > mail archive system. > > 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. > > 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. > > 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. > > 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. > > 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. > > Gareth aka. Kit > __________________________________________ _____ > fpc-devel maillist - > http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > [1]">http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > > __________________________________________ _____ > fpc-devel maillist - > http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > [2]">http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > > __________________________________________ _____ > fpc-devel maillist - fpc- de...@lists.freepascal.org > http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel [3] > > > > Links: > ------ > [1] http://secureweb.fast.net.uk/ http:= > [2] http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > [3] > http://secureweb.fast.net.uk/parse.php? redirect=http://lists.freepascal.org > /cgi-bin/mailman/listinfo/fpc-devel > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
