Hi everyone,

I'm just trying to get properly versed with the rules of record types over here: https://www.freepascal.org/docs-html/ref/refsu15.html

For standard record types (no "packed" modifier or compiler directives or anything), I'm wondering how many liberties that the compiler is allowed to take in storing its data.  Take the following example (from raybench.pas over here: http://runtimeterror.com/tools/raybench ):

type
   Vec = record
     X, Y, Z: Single;
   end;
function VLength(const V: Vec): Single;
begin
   Result:=Sqrt(V.X*V.X + V.Y*V.Y + V.Z*V.Z);
end;

If you wanted to get the highest speed possible for this routine on an Intel processor, one solution would be to pack X, Y and Z together, have an invisible 4th dummy field, and align the entire record to a 16 byte boundary, because then you could pass the entire record by value through an XMM register and the VLength operation can be performed with just a pair of VDPPS (dot product) and VSQRTSS (square root) instructions.

Obviously if you use 'packed record' or a compiler directive to change things up, this may not be possible, but at what points is the compiler allowed to make its own choice on what might be best?

Gareth aka. Kit

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).

J. Gareth Moreton schrieb am Do., 2. Apr. 2020,
15:25:

With no explicit packing specified the compiler in general follows the platform's C compiler for compatibility reasons.

P.S. Of course you can force it by forcing the vector to be an m128 type

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.

Regards,
Sven

Sven Barth schrieb am Do., 2. Apr. 2020,
17:10:

Just checked myself: cdecl is the default. So nothing needs to be changed here for us.

Regards,
Sven

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

For a reference, it's the /Gv compiler option:
https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=vs-2019

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

J. Gareth Moreton wrote

For a reference, it's the /Gv compiler option: https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=vs-2019

https://www.freepascal.org/docs-html/prog/progsu7.html

and

fpc -h
...
-Cc<x> Set default calling convention to <x>

Jonas

Hi Sven,

Am I right in thinking that, for C alignment, each field is aligned according to its data size? For example, if you had:

TType = record
   Field1: Byte
   Field2: LongInt;
end;

Are there are three unused bytes between Field1 and Field2 and the structure as a whole is 8 bytes long and aligned to a 4-byte boundary?  I'm trying to find the page that explains all that, and also exceptional cases where the data size is not necessary the same as the minimum alignment.

Gareth aka. Kit

On most platforms, yes. Probably not on 16 bit platforms.

I'm trying to find the page that explains all that, and also exceptional cases where the data size is not necessary the same as the minimum alignment.

"C alignment" is actually a bad name. It's in fact the ABI alignment (which is indeed what C uses), and hence this is different depending on architecture and OS. As a result, there is no page that explains it all, since you have to look it up in the ABI documentation of every individual platform.

Some examples of non-matching alignments on Darwin/i386:
* double is aligned to 4 bytes
* extended is aligned to 16 bytes

Jonas

Hi Jonas,

I brought that up because Florian once asked about just doing everything as vectorcall on Win64 because the calling convention, by and large, is a compatible extension to its default one.  I think issues of compatibility and third-party interfacing makes it not the best idea unless there's a way to override it (which you can do by specifying the 'ms_abi_default' directive, even though that's not the nicest name to remember!)

I'm partly driven by the results from
http://runtimeterror.com/tools/raybench/, thinking "yeah, we can do better than that!".  Speaking of that, I attached the assembler dumps for raybench.pas for comparisons, and it looks like 3.2.0 performs slightly worse in a couple of places, but a number of things have been addressed by 3.3.1 optimisations already (there's an assembler dump for that in the ZIP file too, which also has a load of debug comments).

Gareth aka. Kit

J. Gareth Moreton schrieb am Do., 2. Apr. 2020,
22:33:

I don't think it's a good idea to change the default calling convention. We'll get many bug reports about third party libraries then even if it can be changed. The potential performance gain is not worth it. And those that want to really optimize their code can do so by adjusting the calling convention either per function or using $calling.

Regards,
Sven

Agreed.  Sometimes it is a question of how much should be left to the compiler and how much should be left to the programmer when it comes to optimisation.

Gareth aka. Kit