That can't happen or won't benefit much, before the compiler supports
super-natual alignments. So there's a deeper level of support needed.
And personally I don't think that's the right long term direction. It
takes a long time to develop and maintain this stuff and you never know
what the market will look like in 10 years.
ARM has SVE, and RISC-V has the upcoming vector extension which will
move far away from the traditional SIMD stuff.
Compiler support for block vectorization has rarely paid off really well
given the amount of work that needs to go into it. So maybe it's better
to wait for the next iteration :)
On 4/6/19 11:13 PM, Ben Grasset wrote:
On Wed, Mar 27, 2019 at 11:32 AM J. Gareth Moreton
<gar...@moreton-family.com <mailto:gar...@moreton-family.com>> wrote:
So with the false start that was pure inline assembly, I like to
talk about how to move forward with FPC, or at least with x86_64.
It occurred to me today, aren't you the person who fixed the -Sv
compiler flag so that it actually works? I'd say expansion on that
functionality would be more widely useful than just about anything
else I can think of with regards to optimization (because it's so easy
to use, and yet so powerful.)
Maybe start with making it fully use AVX instructions for the
operations? IIRC, currently, even if you use the AVX or AVX2 compiler
flags, it will always generate stuff like this:
vmovups(%rdx),%xmm0
addps(%r8),%xmm0
vmovups%xmm0,(%rax)
rather than using vaddps.
From there you could make it support arrays larger than 4 elements,
e.t.c....
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
