[fpc-devel] inline... and philosophy
J. Gareth Moreton
gareth at moreton-family.com
Sun Nov 10 17:42:04 CET 2019
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 at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
More information about the fpc-devel
mailing list