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

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>

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

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>