[LLVMdev] Intrinsic parameters verification

Demikhovsky, Elena elena.demikhovsky at intel.com
Thu Jul 2 03:36:51 PDT 2015


> Maybe table-gen’ed?
Oh! This is a good idea I was looking for!

I can add a new parameter type, something like this:

class LLVMConstEnum<list<int> values> : LLVMType<i32> {
  list<int> Values = values;
}

And target specific::
def ScaleEnum : LLVMConstEnum<[0, 1, 2, 4, 8]>;

And use it:

  def int_x86_avx512_gather_dpd_512  : GCCBuiltin<"__builtin_ia32_gathersiv8df">,
          Intrinsic<[llvm_v8f64_ty], [llvm_v8f64_ty, llvm_ptr_ty,
                     llvm_v8i32_ty, llvm_i8_ty, ScaleEnum],    [IntrReadArgMem]>;

And then I can add:

  if (R->isSubClassOf("LLVMConstEnum")) {
    Sig.push_back(IIT_ENUM);                       
    std::vector<int64_t> Values = R->getValueAsListOfInts("Values");
    Sig.push_back(Values.size());   // Number of values
    for (int64_t Val : Values)
      Sig.push_back((char)Val);
  }

The only issue here that the enumerator max value is 255, otherwise I can't put in "unsigned char". (Or I should split into 4 entries)

-  Elena


-----Original Message-----
From: Pete Cooper [mailto:peter_cooper at apple.com] 
Sent: Thursday, July 02, 2015 02:52
To: Renato Golin
Cc: Demikhovsky, Elena; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Intrinsic parameters verification


> On Jul 1, 2015, at 2:02 PM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> On 28 June 2015 at 08:07, Demikhovsky, Elena 
> <elena.demikhovsky at intel.com> wrote:
>> I’m looking at Verifier::visitIntrinsicFunctionCall()
>> but I see only common intrinsics here, not target specific.
> 
> Hey, that's a nice project! A target-specific verifier that scans for 
> all builtins and makes sure they conform to what the back-end accepts.
+1.

This is also something the IR optimizers have had to take in to consideration.  For example, see SimplifyCFG SinkThenElseCodeToEnd which won’t sink intrinsic calls in if/else blocks to the end block if it would replace a constant parameter with a non-constant.  Having some way to at least verify after that this has happened would be great.  Having a way to annotate the intrinsic so that this code can check when its valid or not would be even better.
> 
> Not sure how they would stay relevant with back-end changes, though...
> Maybe table-gen’ed?
Tagging the intrinsics with(for example) which parameters must be constants is ideal I think, as then we could even verify that the backend patterns don’t try to match a constant intrinsic parameter with a register.  Then we know that the backend is consistent with the intrinsic definitions.

Cheers,
Pete
> 
> Surely interesting to try next GSOC.
> 
> --renato
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

---------------------------------------------------------------------
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.




More information about the llvm-dev mailing list