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.
I dare say, if there's one possible place for AI and machine learning,
it would be compiler optimisation!
Gareth aka. Kit
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
