[LLVMdev] Adding masked vector load and store intrinsics

Adam Nemet anemet at apple.com
Mon Oct 27 09:40:35 PDT 2014


> On Oct 25, 2014, at 4:30 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote:
> 
>> The same problem exists with any potentially trapping instruction (e.g. all floating point computations).  The need for intrinsics goes way beyond loads and stores.
> 
> We definitely looking at them, but decided to start from load and store. All FP + gather/scatter are in our long term plan. It will be about 20 intrinsics. 
> But step-by-step.

Hi Elena,

Can you please elaborate on the list.  I don’t see how 20 intrinsics would cover “All FP”.  But do you really have to do all FP or only instructions that can trap with LLVM (e.g. division by zero)?

I do agree that we want to go step by step but we also need to see the the end goal to make sure the design will scale.

Thanks,
Adam

> -  Elena
> 
> 
> -----Original Message-----
> From: dag at cray.com [mailto:dag at cray.com] 
> Sent: Friday, October 24, 2014 19:49
> To: Hal Finkel
> Cc: Demikhovsky, Elena; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics
> 
> Hal Finkel <hfinkel at anl.gov> writes:
> 
>> For the loads, I'm must less sure. Why can't we represent the loads as 
>> select(mask, load(addr), passthru)?
> 
> Because that does not specify the correct semantics.  This formulation expects the load to happen before the mask is applied.  The load could trap.  The operation needs to be presented as an atomic unit.
> 
> The same problem exists with any potentially trapping instruction (e.g. all floating point computations).  The need for intrinsics goes way beyond loads and stores.
> 
>                             -David
> ---------------------------------------------------------------------
> 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.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list