On 21/10/2019 20:00, Florian Klämpfl wrote:
What's the problem with

{$push}
{$codealign RECORDMIN=16}
type complex = record
                      re : real;
                      im : real;
end;
{$pop}

?

Hi Florian,

I tried that, but that puts each individual field on a 16-byte boundary (and the documentation for RECORDMIN implies that this is correct behaviour), which is why only an array element works. This occurs even if "packed record" is used.  The assembly language confirms this:

    movsd    U_$P$COMPLEX_$$_Z(%rip),%xmm0
    addsd    U_$P$COMPLEX_$$_X(%rip),%xmm0
    movsd    %xmm0,40(%rsp)
    movsd    U_$P$COMPLEX_$$_Z+16(%rip),%xmm0
    addsd    U_$P$COMPLEX_$$_X+16(%rip),%xmm0
    movsd    %xmm0,56(%rsp)
    movq    40(%rsp),%rax
    movq    %rax,U_$P$COMPLEX_$$_Z(%rip)
    movq    48(%rsp),%rax
    movq    %rax,U_$P$COMPLEX_$$_Z+8(%rip)
    movq    56(%rsp),%rax
    movq    %rax,U_$P$COMPLEX_$$_Z+16(%rip)

The section with 48(%rsp) seems to relate to those 8 filler bytes and I do question its validity, if not its necessity, since the rest of the subroutine implies that the data at 48(%rsp) is undefined.

In the compiler that sets up XMM parameters (compiler/x86_64/cpupara.pas, line 945), the following code dictates whether a packed vector register is used or two separate registers:

                    if Assigned(parentdef) and ((parentdef.aggregatealignment mod 16) = 0) and ((byte_offset mod parentdef.aggregatealignment) <> 0) then
                      { Aligned vector of type double }
                      classes[0].typ:=X86_64_SSEUP_CLASS
                    else
                      classes[0].typ:=X86_64_SSEDF_CLASS;

(parentdef is the "complex" type in this case, while the regular def is one of the real-type fields).

"byte_offset" for 're' is 0 and for 'im' is 8.  The problem is that parentdef.aggregatealignment, by default, is equal to 8, which indicates that, as far as the compiler is concerned, it is only guaranteed to be aligned to an 8-byte boundary, not 16 (the "mod" expression checks this).  When using the RECORDMIN=16 construct above, the aggregatealignment does increase to 16, but "byte_offset" for 'im' also becomes 16.  At the moment, there's no way to configure a record type to have an aggregate alignment of 16 and a field alignment of 8.

Regarding the stack being aligned to 16-byte boundaries, while this can be guaranteed for local variables and formal parameters, the actual parameters passed into the function may not be aligned (e.g. when deferencing a pointer on the heap after calling, say, "New(complex);"), hence why the compiler can only go by the 8-byte aggregate alignment.

Gareth aka. Kit


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to