[fpc-devel] x86_64 Optimizer Overhaul

[J. Gareth Moreton]

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" gareth at 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" gareth at 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" gareth at 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-
devel at 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
>