[fpc-devel] State of SSE/AVX intrinsics
J. Gareth Moreton
gareth at moreton-family.com
Tue Apr 21 14:11:57 CEST 2020
The value stored at V is the pointer to V[0],
not the zeroth element's data, hence why your
comparison always returns true. In assembly
language, you'd have to effectively do:
MOV RDX, [RSP] { or wherever V's service data
is stored }
VMOVAPS YMM0, [RDX]
Passing RSP (V) into VMOVAPS directly will
load garbage data and possibly cause a buffer
overrun.
The reason why it is a pointer to a pointer
is because the variable has to have a
constant address, but the data may have to be
reallocated to a new location if the dynamic
array is lengthened.
Sorry for getting off topic a bit. I do a
agree that there should be a way to enforce
the alignment of the data pointer. It may
require versions of ReallocMem etc. where you
can enforce the alignment without having to
do any dangerous pointer arithmetic.
Gareth aka. Kit
On Tue 21/04/20 13:58 , "denisgolovan"
denisgolovan at yandex.ru sent:
> > I think Gareth meant the address of V
instead
> (Pointer(@V)).
> >
>
> > Regards,
>
> > Sven
>
>
>
> Hm. I have no idea why anyone would take
pointer to pointer :)
>
>
>
> BTW, Sven, what's your opinion on dynamic
arrays alignment problem?
>
>
>
> I don't have any viable solution besides
maintaining my own compiler fork
> so far.
> LLVM backend could also help with
autovectorization, but it would require
> proper alignment as well.
>
>
> -- Regards,
>
> Denis Golovan
>
>
>
>
>
More information about the fpc-devel
mailing list