[llvm-dev] Handling node through TargetLowering::LowerOperation vs TargetLowering::ReplaceNodeResults

Przemyslaw Ossowski via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 29 06:38:10 PST 2020


Thanks Craig,
that's helped me a lot with understanding of ordering of legalize related
stuff.
I think your description should be added to documentation:)

Best regards,
Przemek

On Wed, Jan 29, 2020 at 1:13 AM Craig Topper <craig.topper at gmail.com> wrote:

> Node results are always legalized first. So ReplaceNodeResults will be
> called first. The custom code generated must start and end with the illegal
> types. Instructions like concat_vectors, extract_subvector, zero_extend,
> sign_extend, truncate, and build_pair will be used to bridge between the
> illegal types and the legal type your custom code uses. All of the nodes
> that are custom emitted will also go through type legalization. So those
> connecting nodes will also get legalized.
>
> If the node that's being custom legalized is something that has the result
> type and the input type always the same like an add instruction. Then
> legalizing the output should be enough to fully replace the node. If some
> instruction that doesn't have a fixed relationship between input and output
> type and they are both illegal then its up to the custom code that handles
> the result as to whether or not it wants to fix the input too. Once the new
> code has been emitted from ReplaceNodeResults then the original node is
> dead and will be not be legalized further. Only the custom code that
> replace it will be looked at. It's fine to emit code from
> ReplaceNodeResults with illegal types as long as some of the types are
> legal or you emit different nodes than what you started with that can
> undergo their own legalization.
>
> I hope that helped.
>
> ~Craig
>
>
> On Tue, Jan 28, 2020 at 12:40 PM Przemyslaw Ossowski <
> przemyslaw.ossowski at googlemail.com> wrote:
>
>> Thank you Craig for explanation.
>>
>> Could be the same algorithm used for custom legalizing given node in
>> LowerOperation and ReplaceNodeResults in case results and inputs of the
>> node are illegal?
>> Or actually such situation is impossible and for given node either
>> LowerOperation or ReplaceNodeResults can be only called?
>>
>> Przemek
>>
>>
>> wt., 28 sty 2020, 18:48 u┼╝ytkownik Craig Topper <craig.topper at gmail.com>
>> napisał:
>>
>>> ReplaceNodeResults is called by the type legalizer for custom legalizing
>>> any of the results of a node that have an illegal type.
>>>
>>> LowerOperation is called by the type legalizer to custom legalize node
>>> inputs that have an illegal type. I believe technically it calls
>>> LowerOperationWrapper, but that forwards to LowerOperation by default.
>>>
>>> LowerOperation is also called for custom legalizing nodes with legal
>>> types after type legalization by both the vector op legalizer and the DAG
>>> legalizer. In those cases LowerOperation is called directly and does not
>>> call LowerOperationWrapper.
>>>
>>> On Tue, Jan 28, 2020 at 9:10 AM Przemyslaw Ossowski via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> I see that for different targets in classes which inherits from
>>>> TargetLowering there are implemented both methods:
>>>>
>>>> LowerOperation and ReplaceNodeResults
>>>>
>>>>
>>>>
>>>> What decides that for one given ISD we have to add handling in
>>>> LowerOperation and for other in ReplaceNodeResults, when for both
>>>> SetOperationAction is configured to be Custom?
>>>>
>>>>
>>>> Is it related with number of results of given operation and
>>>> LowerOperation is called when there is only one SDValue?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Przemek
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> --
>>> ~Craig
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200129/17c5e80d/attachment.html>


More information about the llvm-dev mailing list