[PATCH] Add new indexed load/store intrinsics.

Demikhovsky, Elena elena.demikhovsky at intel.com
Sun Apr 26 05:05:13 PDT 2015


We are interested in these intrinsics anyway:

<4 x double> @llvm.masked.indexed.load.v4f64 (double* <ptr>, <4 x i32> <index>, i32 <alignment>, <4 x i1>%mask, <4 x double>%paththru)

Presence of index means that the sequential load is not a solution.
If you are not going to implement this interface now, I’ll do this later.


-           Elena

From: Renato Golin [mailto:renato.golin at linaro.org]
Sent: Thursday, April 23, 2015 10:29
To: reviews+D9194+public+a2f9c543cd08afc3 at reviews.llvm.org
Cc: Ahmed Bougacha; Hao.Liu at arm.com; llvm-commits at cs.uiuc.edu; qcolombet at apple.com; Demikhovsky, Elena
Subject: Re: [PATCH] Add new indexed load/store intrinsics.


On 23 Apr 2015 3:38 am, "Hao Liu" <Hao.Liu at arm.com<mailto:Hao.Liu at arm.com>> wrote:
>
> Hi Renato and Ahmed,
>
> I agree with your comments.
>
> But I want to change the plan. Because I think maybe there is no need to use intrinsics.
> For the interleaved load about <4 x double>
>
>   <4 x double> @llvm.indexed.load.v4f64 (double* <ptr>, <4 x i32> <index>, i32 <alignment>)
>
> I think we can use two common IRs:
>
>   <value> = load <4 x double>, <4 x double>* <ptr>
>   shufflevector <4 x double> <value>, <4 x double> undef, <4 x i32> <0, 2, 1, 3>
>
> Even though it is more complex for a backend to match two IRs, it is achievable. I think the disadvantage of  intrinsics is not easy to be optimized.
>
> I want to implement the loop vectorization on interleaved memory access  with vectorload/vectorstore+shufflevector.
>
> What do you think?

I agree. If it's possible to represent it in plain IR, I see no reason to not do it.

I'll be particularly interested in how other passes scramble the accesses, making the pattern irrecoverable. But I guess will find that out as you progress with the examples and tests.

Cheers,
Renato
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150426/ba46ae6b/attachment.html>


More information about the llvm-commits mailing list