[fpc-devel] Vectorisation, optimisation etc.

[Jeppe Johansen]

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 
> <gareth at moreton-family.com <mailto:gareth at 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....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190406/3fab9f2c/attachment.html>