That seems fair, yep. Currently, vectorcall, and the more intricate
parts of the System V ABI, is only really beneficial when interfacing
with third-party libraries or when programming in assembly language.
Sorry if I've given you a headache with my stubbornness and passion.
I'll try to behave myself. Thanks for accepting the jump optimisations,
by the way. I hope they perform well.
Some of the "condition_in" functions need expanding though, and I don't
yet have an answer if it's okay to do operator overloading in the
compiler source (so I can do things like "if (jmp1.cond in jmp2.cond)
then", for example, instead of the more ambiguous "if
condition_in(jmp1.cond, jmp2.cond) then".
Gareth aka. Kit
On 10/11/2019 15:33, Florian Klämpfl wrote:
Am 10.11.19 um 16:02 schrieb J. Gareth Moreton:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a behemoth with corporate
support) and Microsoft Visual C++ that often hides the size of
binaries behind a redistributable library. I don't ever seek to make
binaries smaller at the expense of speed, but if I see a potential
saving that could be done automatically, I dive for it!
On 10/11/2019 14:47, Marco van de Voort wrote:
(and btw, if you are serious about these scenarios, drop all
optimization work immediately, and start working on packages :-)
I did try to start simple with the 'uComplex' unit, but concerns were
raised because I changed the formal parameters to 'const' and aligned
the complex type on x86-64 platforms so it can take advantage of XMM
registers better (which, given proper optimisation, would result in
both smaller code size and higher speed). While I made sure that the
interfaces would not change for Pascal code, assembler code that
calls the functions (if it exists) might need to be changed slightly
(something Florian raised). I'm not quite sure what the rules are
when it comes fo updating packages, other than the obvious one of not
breaking old code.
Currently, there is no real gain by changing the calling conventions.
When we have a vectorizer, we can talk about it.
I like working on optimisation because I have a morbid fascination
with the lowest level of the CPU and I feel well-suited for it,
although there are still some things I'm learning about it.
Gareth aka. Kit
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel