On 09/01/2022 04:53, J. Gareth Moreton via fpc-devel wrote:
On 09/01/2022 01:47, Martin Frb via fpc-devel wrote:
I take it, it also is one (or two?) bytes longer? If that is in a
loop, which otherwise is exactly within a 32 byte aligned block, then
that could cause a slow down too. (If the loop is 16 bytes long, but
aligned to a 32byte-bound+16, then it may slow down if the loop code
size goes from 16 to 17 bytes, because that is when it goes over the
boundary of the 32byte block.
This is a bit hard to predict. But within very small loops (even 2 or
maybe 3 blocks of 32 bytes), size may be as important. (Actually a
good question, what weighs more....)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
jng .Lj188 would be 2 bytes long here since it's a short jump, while
setg %bl and movzbl %bl,%ebx are 3 bytes long apiece, so the code size
goes grow by 4 bytes overall (it would grow by 6 bytes if a REX prefix
has to be used to encode, say, %r8b etc.)
Some sizes are very hard to predict, like some optimisations are not
performed under -Os because it would increase code size, but in some
cases it causes a cascade that ends up both shrinking the code size
and making the block several cycles faster.
Btw, have you seen this?
https://www.agner.org/optimize/optimizing_assembly.pdf
Page 70, it says that under some conditions a branch may be faster than
a conditional move.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
