[fpc-devel] Rules about record types and internal storage

J. Gareth Moreton gareth at moreton-family.com
Thu Apr 2 17:59:25 CEST 2020

For a reference, it's the /Gv compiler option: 

If anything it's proving to be an interesting study case on how to make 
something optimal when given code that doesn't give the compiler many 
clues.  Granted, given the sample function, I'm envisioning some 
node-level optimisation and auto-inlining.

Gareth aka. Kit

On 02/04/2020 16:48, J. Gareth Moreton wrote:
> Apologies - I wasn't clear.  There is an option in the MSVC compiler 
> to default to vectorcall, but you have to specify it.
> Gareth aka. Kit
> On 02/04/2020 16:16, Sven Barth via fpc-devel wrote:
>> Sven Barth <pascaldragon at googlemail.com 
>> <mailto:pascaldragon at googlemail.com>> schrieb am Do., 2. Apr. 2020, 
>> 17:10:
>>         P.S. Of course you can force it by forcing the vector to be
>>         an m128 type
>>         and specifying vectorcall for x86_64-win64, but not everyone
>>         will know
>>         to do that and it gets unwieldly rather quickly. Speaking of
>>         vectorcall, I'm wondering if we can introduce 'fastcall' as
>>         an alias for
>>         'ms_abi_default', mostly so if we follow Microsoft Visual
>>         C++'s example
>>         of automatically making all routines vectorcall (which is
>>         closer to the
>>         System V ABI used by linux and will make vectorisation
>>         easier), we can
>>         force the default one if we need a routine that, say, has to
>>         interface
>>         with a third-party library ('fastcall' under win32 is what
>>         the MS ABI is
>>         based off... first parameter in ECX, second in EDX and
>>         everything else
>>         on the stack).
>>     Please provide a source for your statement that MSVC uses
>>     vectorcall by default. Cause I highly doubt that as Microsoft is
>>     huge on backwards compatibility especially regarding the lower
>>     level stuff.
>> Just checked myself: cdecl is the default. So nothing needs to be 
>> changed here for us.
>> Regards,
>> Sven
>> _______________________________________________
>> fpc-devel maillist  -fpc-devel at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virus-free. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20200402/c67bf621/attachment-0001.html>

More information about the fpc-devel mailing list