Deepak Rajendrakumaran via llvm-dev
2021-Mar-04 19:51 UTC
[llvm-dev] Query supported llvm intrinsic calls during runtime.
Seems like it’s more complicated than just checking intrinsics/target features. Some intrinsics seem to require specific opt passes to lower. For eg. https://llvm.org/docs/LangRef.html#matrix-intrinsics : it doesn’t say anything in the doc but llc with no opt pass - https://godbolt.org/z/dWYddx lowering with opt pass : https://godbolt.org/z/18n69T That raises the question – is there any doc available with similar exceptions which require additional passes to be run for codegen? -Deepak On Wed, Feb 24, 2021 at 12:34 PM Craig Topper <craig.topper at gmail.com> wrote:> The prefixes should work excerpt for all the subfeatures of avx512 where > everything is just llvm.avx512. > > ~Craig > > > On Wed, Feb 24, 2021 at 12:19 PM Deepak Rajendrakumaran <deepak3 at vt.edu> > wrote: > >> Yeah...that’ll be tricky. >> >> Assuming intrinsic prefix denote target support needed, maybe I can >> handle that considering during runtime target to be compiled to is known. >> >> I.e., Lets use llvm.x86.sse41.round.as as an example. If the prefix >> llvm.x86.sse4 can be used to decide the supported target features for this >> intrinsics are x86 arch and sse4 vector support, maybe that’ll be enough. >> Ideally, I was hoping for some way to specify target features (say target >> cpu) and have the intrinsics filtered. But if it’s not available, this can >> be an alternate path. >> >> Regards, >> Derpak >> >> On Wed, Feb 24, 2021 at 11:41 AM Craig Topper <craig.topper at gmail.com> >> wrote: >> >>> That doesn't check for target features being enabled for target specific >>> intrinsics. I believe Andy's suggestion will just check if the types are >>> valid. >>> >>> ~Craig >>> >>> >>> On Wed, Feb 24, 2021 at 11:34 AM Deepak Rajendrakumaran <deepak3 at vt.edu> >>> wrote: >>> >>>> Thank you! That looks like it should do the trick assuming it checks >>>> for both target specific and target independent intrinsics. >>>> >>>> Regards, >>>> Deepak >>>> >>>> On Wed, Feb 24, 2021 at 11:29 AM Kaylor, Andrew < >>>> andrew.kaylor at intel.com> wrote: >>>> >>>>> Does Intrinsic::getIntrinsicInfoTableEntries() + >>>>> Intrinsic::matchIntrinsicSignature() do what you’re looking for? >>>>> >>>>> >>>>> >>>>> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Deepak >>>>> Rajendrakumaran via llvm-dev >>>>> *Sent:* Wednesday, February 24, 2021 11:27 AM >>>>> *To:* Craig Topper <craig.topper at gmail.com> >>>>> *Cc:* llvm-dev at lists.llvm.org >>>>> *Subject:* Re: [llvm-dev] Query supported llvm intrinsic calls during >>>>> runtime. >>>>> >>>>> >>>>> >>>>> Both. Target specific intrinsics especially are important but ideally >>>>> I’d like to be able to query for both. The idea is to enable to directly >>>>> call any available llvm intrinsic. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Deepak >>>>> >>>>> >>>>> >>>>> On Wed, Feb 24, 2021 at 11:17 AM Craig Topper <craig.topper at gmail.com> >>>>> wrote: >>>>> >>>>> Are you asking about target independent intrinsics or target specific >>>>> intrinsics? >>>>> >>>>> >>>>> ~Craig >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 24, 2021 at 11:15 AM Deepak Rajendrakumaran via llvm-dev < >>>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I have a frontend which creates LLVM IR and uses LLVM optimizations >>>>> and codegen. Is there someway to query LLVM during runtime if a particular >>>>> intrinsic is supported? >>>>> >>>>> >>>>> >>>>> For example- during runtime user says call the following intrinsic - >>>>> ‘llvm.foo(<8 x i64>)’. I’m looking for a way to verify that llvm.foo(<8 x >>>>> i64>)’. is a valid llvm intrinsic before creating IR/inserting in IR. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Deepak >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210304/9c418af2/attachment.html>