[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