[llvm-dev] Assigning custom information to IR instruction and passing it to its correspondent in Selection DAG

Fri May 3 14:41:40 PDT 2019

This could be interesting alternative to utilizing metadata. Now I will
consider usage of each other - metadata vs. intrinsic.

Thanks Mehdi for these ideas! I haven't thought about usage intrinsic just
for pointer.

Best regards,
Przemek

czw., 2 maj 2019, 18:37 użytkownik Mehdi AMINI <joker.eph at gmail.com>
napisał:

>
>
> On Wed, May 1, 2019 at 3:55 PM Przemyslaw Ossowski <
> przemyslaw.ossowski at googlemail.com> wrote:
>
>>
>>
>>
>>>
>>>
>>>>
>>>> I want to customize handling of 'load' instruction during processing
>>>> DAG, but on IR level I want the 'load' to be treated in different passes as
>>>> common load. So I'm afraid that replacing 'load' with Intrinsic would cause
>>>> different handling it comparing to LoadInst.
>>>>
>>>
>>> Yes this is the kind of replacement you would do after the general
>>> optimizations.
>>> If you need to attach this information when you create the IR (from the
>>> front-end directly for example) then intrinsics or metadatas are the only
>>> two ways I know of.
>>> Depending on what is it exactly that you are trying to model, function
>>> attributes can be used but they would apply to the whole function (or
>>> specific arguments). It may also be possible to use an intrinsic to mark
>>> the pointer itself instead of the instructions manipulating it, again it
>>> depends on what you are modelling.
>>>
>>> So you are suggesting to replace something like:
>> %ptr = alloca i32
>> %val = load i32, i32* %ptr
>>  with
>> %ptr = alloca i32
>> %custom.ptr = call i32* @llvm.customhandling(i32*
>> %ptr)
>> %val = load i32, i32* %custom.ptr
>> ?
>>
>
> I had in mind something like:
>
> %ptr = alloca i32
> %custom.ptr = call i32* @llvm.customhandling(i32* %ptr)
>
> Then use only the `custom.ptr`, never `ptr`.
> But every approach will have its tradeoff, so it really depends on the
> use-case.
>
>
>>> I've found that in the DAGBuilder metadata information connected with
>>>> LoadInst instruction is utilized:
>>>> bool isInvariant = I.getMetadata(LLVMContext::MD_invariant_load) !=
>>>> nullptr;
>>>>
>>>> Is this metadata somehow protected against dropping - as you mentioned?
>>>>
>>>
>>> Nothing is protected as far as I know, the design is that it should
>>> always be legal to drop a metadata.
>>> I don’t know what the invariant_load information is used for at the
>>> place you looked at, but I assume that I can take the IR, strip it out of
>>> the “invariant_load” metadata from the loads, and optimizations/codegen
>>> should still be correct. If your use-case fits in this model then metadata
>>> is likely a good starting point.
>>>
>>> In my case dropping metadata shouldn't cause functional issues, eventual
>> only performance - different pattern would be chosen. So I will start with
>> utilizing metadata.
>>
>> Regards,
>> Przemek
>>
>>
>> On Thu, May 2, 2019 at 12:05 AM Mehdi AMINI <joker.eph at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, May 1, 2019 at 2:48 PM Przemyslaw Ossowski <
>>> przemyslaw.ossowski at googlemail.com> wrote:
>>>
>>>> Thanks Mehdi for the suggestion.
>>>> I want to customize handling of 'load' instruction during processing
>>>> DAG, but on IR level I want the 'load' to be treated in different passes as
>>>> common load. So I'm afraid that replacing 'load' with Intrinsic would cause
>>>> different handling it comparing to LoadInst.
>>>>
>>>
>>> Yes this is the kind of replacement you would do after the general
>>> optimizations.
>>> If you need to attach this information when you create the IR (from the
>>> front-end directly for example) then intrinsics or metadatas are the only
>>> two ways I know of.
>>> Depending on what is it exactly that you are trying to model, function
>>> attributes can be used but they would apply to the whole function (or
>>> specific arguments). It may also be possible to use an intrinsic to mark
>>> the pointer itself instead of the instructions manipulating it, again it
>>> depends on what you are modelling.
>>>
>>>
>>> I've found that in the DAGBuilder metadata information connected with
>>>> LoadInst instruction is utilized:
>>>> bool isInvariant = I.getMetadata(LLVMContext::MD_invariant_load) !=
>>>> nullptr;
>>>>
>>>> Is this metadata somehow protected against dropping - as you mentioned?
>>>>
>>>
>>> Nothing is protected as far as I know, the design is that it should
>>> always be legal to drop a metadata.
>>> I don’t know what the invariant_load information is used for at the
>>> place you looked at, but I assume that I can take the IR, strip it out of
>>> the “invariant_load” metadata from the loads, and optimizations/codegen
>>> should still be correct. If your use-case fits in this model then metadata
>>> is likely a good starting point.
>>>
>>> Best,
>>>
>>> —
>>> Mehdi
>>>
>>>
>>>> Thanks,
>>>> Przemek
>>>>
>>>> On Wed, May 1, 2019 at 5:57 AM Mehdi AMINI <joker.eph at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 30, 2019 at 3:51 PM Przemyslaw Ossowski via llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>> as I wrote in mu previous post I wanted to somehow mark one IR
>>>>>> instruction (in this particular case it would be 'load') during dedicated
>>>>>> pass, which will set the marking based on neighboring instructions. Next I
>>>>>> wanted to somehow to convey this marking from 'load' IR instruction to
>>>>>> 'load' SDNode in order to use it during DAG Instruction Selection -
>>>>>> information stored in this marking would 'enable' or 'disable' particular
>>>>>> pattern... I was thinking about usage metadata for it, but I didn't get any
>>>>>> feedback.
>>>>>> So now I'm wondering if solution with metadata is the best one or it
>>>>>> maybe it doesn't make any sense an something else would be better.
>>>>>>
>>>>>> I don't have big experience with metadata, but what I've read it
>>>>>> would allow for customizing IR instruction without modifying the
>>>>>> instruction. Or maybe I'm unnecessarily thinking about metadata, because
>>>>>> 'load' instruction has already some fields which could be used for storing
>>>>>> 'flags', which might represent any custom information. Obviously I don't
>>>>>> want to modify 'load'.
>>>>>> Any suggestions?
>>>>>>
>>>>>
>>>>> In general metadata aren't recommended for carrying semantically
>>>>> important information as they can be dropped at any time.
>>>>>
>>>>> What about using a target specific intrinsic? Your pass could convert
>>>>> the instructions to your intrinsic that you can then easily match in
>>>>> SelectionDAG.
>>>>>
>>>>> --
>>>>> Mehdi
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 25, 2019 at 11:54 AM Przemyslaw Ossowski <
>>>>>> przemyslaw.ossowski at googlemail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I’m looking for the best approach which would allow for marking
>>>>>>> given LLVM IR instruction during IR custom pass and later utilizing that
>>>>>>> information during DAG Instruction Selection in order to match given
>>>>>>> pattern based on this marking.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I’m wondering if marking IR instruction utilizing Metadata is good
>>>>>>> idea.
>>>>>>>
>>>>>>> But how later pass that information to DAG and appropriately mark in
>>>>>>> DAGBuilder SDNode, which represents the earlier marked instruction in IR?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Any suggestion how to implement the most efficiently?
>>>>>>>
>>>>>>> I’m expecting there are already similar solutions – maybe someone
>>>>>>> would be able to indicate the exact example?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Przemek
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20190503/436f58be/attachment.html>