Since this feature is still a work in progress and bugs are inevitable,
my merge request over here now only does what it was originally designed
to do... make __m128 and the like aligned, although admittedly code that
ensures they are treated as vector types is tied into the same commit:
So I've done some testing... make_not_regable is NOT being called at
all. When the array is already on the stack, this is no problem, but if
it's in an MM register, then problems start occurring. If I force the
call to make_not_regable, then the bad code disappears. I'm still
learning how
On 08/04/2022 20:31, J. Gareth Moreton via fpc-devel wrote:
That might explain a few things. The problem is that under vectorcall
and the System V ABI (the default x86_64 calling convention for Linux),
vector types are supposed to be fully supported, like an aligned array
of 4 Singles should
On 08/04/2022 19:19, Jonas Maebe via fpc-devel wrote:
On 08/04/2022 19:57, J. Gareth Moreton via fpc-devel wrote:
It looks like support for writing to arrays that are wholly stored in
registers is a little limited and buggy
Modifying individual elements of arrays stored in registers has never
On 08/04/2022 19:57, J. Gareth Moreton via fpc-devel wrote:
It looks like support for writing to arrays that are wholly stored in
registers is a little limited and buggy
Modifying individual elements of arrays stored in registers has never
been enabled nor supported in the compiler. That is
Also I just raised an internal error on the trunk:
program m128test;
type
UnalignedArray = array[0..1] of Double;
function Test3(V1, V2: UnalignedArray): UnalignedArray; vectorcall;
begin
Test3[1] := V1[1] + V2[1];
end;
begin
end.
Compiler fails with "m128.pp(7,1) Fatal: Internal error
It looks like support for writing to arrays that are wholly stored in
registers is a little limited and buggy - while it writes to temporary
memory when modifying an individual element, the compiler sometimes
doesn't write back the final result into the original register. I'm
seeing if I can
That's fair. Looks like I'm going to have to explore and experiment a
lot more to see if I can 'unbreak' some things. What was meant to be a
simple alignment fix has kind of ballooned into much more.
Gareth aka. Kit
On 06/04/2022 22:00, Jonas Maebe via fpc-devel wrote:
On 06/04/2022 22:58,
On 06/04/2022 22:58, J. Gareth Moreton via fpc-devel wrote:
On 06/04/2022 21:16, Jonas Maebe via fpc-devel wrote:
On 06/04/2022 19:20, J. Gareth Moreton via fpc-devel wrote:
I recently made a merge request that initally just fixed the
incorrect memory alignment for __m128 and similar types,
I used it because it was easy to hot-swap the constructor in the
definition of __m128 and the like, and it was a quick and convenient way
to ensure the alignment was correct.
Gareth aka. Kit
On 06/04/2022 21:16, Jonas Maebe via fpc-devel wrote:
On 06/04/2022 19:20, J. Gareth Moreton via
On 06/04/2022 19:20, J. Gareth Moreton via fpc-devel wrote:
I recently made a merge request that initally just fixed the incorrect
memory alignment for __m128 and similar types, but doing so revealed a
whole plethora of other bugs. First, when I fixed it, __m128 etc were
no longer recognised
Pascal simply is a strongly typed language. Vector intrinsics are no
reason to weaken this. Thus you need to declare operator overloads that
hide the nitty, gritty details of assigning a TVector4 to a __m128, e.g.:
type
TVector4 = packed record
X, Y, Z, W: Single;
class operator :=
Am 06.04.2022 um 20:32 schrieb J. Gareth Moreton via fpc-devel:
Another problem... I've tried to declare an ADDPD intrinsic as follows:
function x86_addpd(r0, r1: __m128d): __m128d; [INTERNPROC:
fpc_in_x86_addpd];
I thought using __m128d instead of __m128 was fairly logical since
ADDPD
Another problem... I've tried to declare an ADDPD intrinsic as follows:
function x86_addpd(r0, r1: __m128d): __m128d; [INTERNPROC:
fpc_in_x86_addpd];
I thought using __m128d instead of __m128 was fairly logical since ADDPD
works with Doubles, not Singles, but this can cause problems. For
Hi everyone,
I recently made a merge request that initally just fixed the incorrect
memory alignment for __m128 and similar types, but doing so revealed a
whole plethora of other bugs. First, when I fixed it, __m128 etc were
no longer recognised as a valid SIMD or aggregate type due to the
15 matches
Mail list logo
