[llvm-dev] Query supported llvm intrinsic calls during runtime.

[Deepak Rajendrakumaran via llvm-dev]

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>