* Re: Fw: RFC: Representing vector lane load/store operations
[not found] <OF630F8944.96ACEF66-ONC225785C.00363150-C225785C.003637B4@il.ibm.com>
@ 2011-03-23 10:02 ` Ira Rosen
0 siblings, 0 replies; only message in thread
From: Ira Rosen @ 2011-03-23 10:02 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc, rdsandiford
>> ...Ira would know best, but I don't think it would be used for this
>> kind of loop. It would be more something like:
>>
>> for (i=0; i<N; ++i)
>> X[i] = Y[i].red + Y[i].blue + Y[i].green;
>>
>> (not a realistic example). You'd then have:
>>
>> compoundY = __builtin_load_lanes (Y);
>> red = ARRAY_REF <compoundY, 0>
>> green = ARRAY_REF <compoundY, 1>
>> blue = ARRAY_REF <compoundY, 2>
>> D1 = red + green
>> D2 = D1 + blue
>> MEM_REF <X> = D2;
>>
>> My understanding is that'd we never do any operations besides ARRAY_REFs
>> on the compound value, and that the individual vectors would be treated
>> pretty much like any other.
>
> Ok, I thought it might be used to have a larger vectorization factor for
> loads and stores, basically make further unrolling cheaper because you
> don't have to duplicate the loads and stores.
Right, we can do that using vld1/vst1 instructions (full load/store
with N=1) and operate on up to 4 doubleword vectors in parallel. But
at the moment we are concentrating on efficient support of strided
memory accesses.
Ira
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-03-23 10:02 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <OF630F8944.96ACEF66-ONC225785C.00363150-C225785C.003637B4@il.ibm.com>
2011-03-23 10:02 ` Fw: RFC: Representing vector lane load/store operations Ira Rosen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).