[LLVMdev] Adding masked vector load and store intrinsics (original) (raw)

Smith, Kevin B kevin.b.smith at intel.com
Fri Oct 24 16:55:58 PDT 2014

Also, FWIW, this is the direction that was taken in the Intel Compiler to support masking in the IR as well.

Kevin B. Smith

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Smith, Kevin B Sent: Friday, October 24, 2014 3:31 PM To: dag at cray.com Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics

Yes, IMO that has to be the direction in order for SSA form to work properly for masked operations.

Kevin B. Smith

-----Original Message----- From: dag at cray.com [mailto:dag at cray.com] Sent: Friday, October 24, 2014 3:13 PM To: Smith, Kevin B Cc: dag at cray.com; Demikhovsky, Elena; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics

"Smith, Kevin B" <kevin.b.smith at intel.com> writes:

How would one express such semantics in LLVM IR with this intrinsic? By definition, %data anmd %passthrough are different IR virtual registers and there are no copy instructions in LLVM IR. You never need to express this semantic in LLVM IR, because in SSA form they are always different SSA defs for the result of the operation versus the inputs to the operation. Someplace late in the CG needs to handle this, in exactly an analogous fashion as it already has to handle this for mapping to regular X86 two address code.

Following up, doing it this way will require that additional intrinsics (for exmaple, all FP operations) each have an additional passthrough register operand:

%result = llvm.masked.fadd(%a, %b, %mask, %passthrough)

Otherwise we would need some implicit specification that either %a or %b is the passthrough which seems very wrong for a general intrinsic.

Is this how you see this going?

                           -David

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