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

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/20190430/99887740/attachment.html>

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.
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?

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/20190501/4857bbe1/attachment.html>

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/20190501/ba61c6b5/attachment.html>