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

Wed May 1 15:55:01 PDT 2019

>
>
>>
>> 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'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/f3d26cc0/attachment.html>