[LLVMdev] Adding masked vector load and store intrinsics

[Stephen Canon]

One can at least imagine using a masked load to access device memory which might have access granularity smaller than the vector size (this seems like a *terrible* idea to me, but at least I can conceive of cases where the semantics would matter beyond just page-crossing loads).

That said, page-crossing loads are a good-enough reason to support this on their own.
– Steve

> On Oct 24, 2014, at 12:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: dag at cray.com
>> To: "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "Elena Demikhovsky" <elena.demikhovsky at intel.com>, llvmdev at cs.uiuc.edu
>> Sent: Friday, October 24, 2014 11:56:14 AM
>> Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics
>> 
>> Hal Finkel <hfinkel at anl.gov> writes:
>> 
>>>> If this were really a question of safety, I'd agree. And if we
>>>> were
>>>> talking about gather loads, I'd agree. For a regular vector loads,
>>>> I
>>>> don't see this as a safety issue. We should outline what the
>>>> downside of emitting a regular load would actually be should some
>>>> optimization be done to the select. Can you please elaborate on
>>>> this?
>>> 
>>> Nevermind ;) -- I changed my mind, the safety issue is with
>>> non-aligned loads that might cross page boundaries. Is that right?
>> 
>> That's just one safety issue.  There are others.
> 
> Can you be more specific? You mentioned overindexing in your other e-mail, exactly what do you mean by that?
> 
> Thanks again,
> Hal
> 
>> 
>>> If so, I think this proposal is good (although obviously the docs
>>> need
>>> to make clear what the faulting behavior of these intrinsics is).
>> 
>> The behavior should be not to ever fault on an element whose mask bit
>> is
>> false, and behave as a regular load (wrt trapping) for any element
>> whose
>> mask bit is true.
>> 
>>                              -David
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141024/fe762665/attachment.html>