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

Thu May 2 09:37:18 PDT 2019

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/20190502/0b5fd6e0/attachment.html>