Hi, I have target specific intrinsics (X86 in my case) with special constant parameters. Rounding mode constant, or scale value in gather/scatter. The scale, for example, may be 0, 1, 2, 4, or 8 only. How do I verify the values on IR level ? I'm looking at Verifier::visitIntrinsicFunctionCall() but I see only common intrinsics here, not target specific. Thank you. - Elena --------------------------------------------------------------------- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150628/65994d8c/attachment.html>
Hi Elena, I think the checks are done by the front-end, then if the values provided to an intrinsic do not work for the IR, the backend aborts with cannot select. I may be wrong of course, this is my recollection of how the ARM backend work for neon intrinsics. The bottom line is you may want to ask this question to cfe dev. Cheers, Q.> On Jun 28, 2015, at 12:07 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > > Hi, > > I have target specific intrinsics (X86 in my case) with special constant parameters. > Rounding mode constant, or scale value in gather/scatter. The scale, for example, may be 0, 1, 2, 4, or 8 only. > How do I verify the values on IR level ? > > I’m looking at Verifier::visitIntrinsicFunctionCall() > but I see only common intrinsics here, not target specific. > > Thank you. > > Elena > > > > --------------------------------------------------------------------- > 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/9729510a/attachment.html>
FWIW, this is kind of lame, but this is how that work! Q.> On Jul 1, 2015, at 11:57 AM, Quentin Colombet <qcolombet at apple.com> wrote: > > Hi Elena, > > I think the checks are done by the front-end, then if the values provided to an intrinsic do not work for the IR, the backend aborts with cannot select. > I may be wrong of course, this is my recollection of how the ARM backend work for neon intrinsics. > > The bottom line is you may want to ask this question to cfe dev. > > Cheers, > Q. > >> On Jun 28, 2015, at 12:07 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com <mailto:elena.demikhovsky at intel.com>> wrote: >> >> Hi, >> >> I have target specific intrinsics (X86 in my case) with special constant parameters. >> Rounding mode constant, or scale value in gather/scatter. The scale, for example, may be 0, 1, 2, 4, or 8 only. >> How do I verify the values on IR level ? >> >> I’m looking at Verifier::visitIntrinsicFunctionCall() >> but I see only common intrinsics here, not target specific. >> >> Thank you. >> >> Elena >> >> >> >> --------------------------------------------------------------------- >> 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 <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/20150701/52e2a4bb/attachment.html>
On 07/01/2015 11:57 AM, Quentin Colombet wrote:> Hi Elena, > > I think the checks are done by the front-end, then if the values > provided to an intrinsic do not work for the IR, the backend aborts > with cannot select. > I may be wrong of course, this is my recollection of how the ARM > backend work for neon intrinsics. > > The bottom line is you may want to ask this question to cfe dev. > > Cheers, > Q.This is correct. clang allows defining a builtin, which will eventually map to an intrinsic call and allows you to enforce that the parameter folds to a constant integer. However, AFAIK there isn't an easy way to restrict the values there. -Matt
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. Not sure how they would stay relevant with back-end changes, though... Maybe table-gen'ed? Surely interesting to try next GSOC. --renato
> 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