[fpc-devel] Optimization theory

J. Gareth Moreton gareth at moreton-family.com
Sun Jun 17 12:16:13 CEST 2018

 Indeed, so if it can be done only once, that's a major saving.  Even if
div and mod are separate assembler instructions on the target platform,
it's possible to make a saving if multiplication and subtraction aren't too
expensive, as then the modulus can be calculated via r = n - qd.

 The issue with DivMod is that the saving isn't that great because of the
penalty of calling a subroutine, which amounts to around 50 cycles on
x86-64, about equal to DIV.  This could be alleviated if the function is
able to be inlined or, when dealing with constants, can be identified as a
'pure' function (I wrote a little request article about this:
[1] )

 Gareth aka. Kit 

 On Sun 17/06/18 10:08 , "Christo Crause" christo.crause at gmail.com sent:
 The penalty for separate div border-left:1px #ccc solid;padding-left:1ex">

 There are also situations in optimization where one might detect a repeat
calculation that the programmer cannot eliminate themselves, but which the
best optimization is to store the result and re-use it later... the most
obvious situation where this arises is with div and mod with the same
numerator and denominator.  Currently, the compiler doesn't know any
better and has to calculate the division twice, a relatively expensive
operation, even though DIV returns both the quotient and the remainder in
RAX and RDX respectively.  I believe storing the mod result in a virtual
register for later use will be far easier to manage when the registers have
not yet been allocated, especially if it's determined that a new register
has to be preserved in the function prologue, or there are no free
registers at all and it has to be put on the stack, or if it's at all
possible to use RDX itself as that temporary storage (the most ideal
outcome in both speed and size), something that would be near impossible if
RDX has been allocated for something in between. 
 Gareth aka. Kit
 fpc-devel maillist  -  fpc-devel at lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]

[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180617/fdbe2b00/attachment.html>

More information about the fpc-devel mailing list