[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