[llvm-dev] returning from LowerOperation()

[Hal Finkel via llvm-dev]

On 01/23/2017 11:36 PM, Jonas Paulsson wrote:
>
> Hi all,
>
> thanks!
>
> >  Not sure if it's described anywhere off the top of my head; if 
> there isn't a comment describing this on the declaration of 
> LowerOperation or LowerOperationWrapper, it would probably be good to 
> add one.  Returning SDValue() should be "fine" in all cases (it might 
> lead to a fatal error if we can't actually lower the operation).
>
> Does this sound good?
>

Why don't we just say, "Returning SDValue() indicates that the input 
node should be expanded."?

  -Hal

> diff --git a/include/llvm/Target/TargetLowering.h 
> b/include/llvm/Target/TargetLowering.h
> index 01c5c51..41edcc6 100644
> --- a/include/llvm/Target/TargetLowering.h
> +++ b/include/llvm/Target/TargetLowering.h
> @@ -2830,7 +2830,8 @@ public:
>    /// target, which are registered to use 'custom' lowering, and 
> whose defined
>    /// values are all legal.  If the target has no operations that 
> require custom
>    /// lowering, it need not implement this.  The default 
> implementation of this
> -  /// aborts.
> +  /// aborts. Returning SDValue() is ok and signals that the input node
> +  /// should be further handled by the caller instead.
>    virtual SDValue LowerOperation(SDValue Op, SelectionDAG &DAG) const;
>
>    /// This callback is invoked when a node result type is illegal for the
>
> / Jonas
>
>
> On 2017-01-23 22:59, Hal Finkel via llvm-dev wrote:
>>
>>
>> On 01/23/2017 02:41 PM, Matt Arsenault via llvm-dev wrote:
>>>
>>>> On Jan 23, 2017, at 12:36, Friedman, Eli via llvm-dev 
>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>
>>>> On 1/23/2017 5:21 AM, Jonas Paulsson wrote:
>>>>> Hi Eli,
>>>>>
>>>>> I would like to clarify generally what the difference is between 
>>>>> returning SDValue() and Op (input argument unchanged) from 
>>>>> LowerOperation()?
>>>>>
>>>>> My understanding is that returning SDValue() means that Target 
>>>>> gives up, and the common code is supposed to handle it. Returning 
>>>>> Op, the unchanged argument, means that the Target is happy with 
>>>>> the node as it is, and the common code can move on to something else.
>>>>
>>>> This is right.
>>>
>>> This sounds backwards. Returning SDValue() means the node should be 
>>> treated as legal. Returning the original operation should hit the 
>>> expand path.
>>
>> No, I think that was correct. The code in 
>> lib/CodeGen/SelectionDAG/LegalizeDAG.cpp reads:
>>
>>     switch (Action) {
>>     case TargetLowering::Legal:
>>       return;
>>     case TargetLowering::Custom: {
>>       // FIXME: The handling for custom lowering with multiple results is
>>       // a complete mess.
>>       if (SDValue Res = TLI.LowerOperation(SDValue(Node, 0), DAG)) {
>>         if (!(Res.getNode() != Node || Res.getResNo() != 0))
>>           return;
>>
>>         ...
>>
>>         ReplaceNode(Node, ResultVals.data());
>>         return;
>>       }
>>       LLVM_FALLTHROUGH;
>>     }
>>     case TargetLowering::Expand:
>>       if (ExpandNode(Node))
>>         return;
>>
>> So, if you return an SDValue() then it will Expand. If you return the 
>> original node, that is equivalent to Legal. Otherwise, you're 
>> requesting a replacement. The logic for loads/stores and vectors is 
>> handled separately (but is similar).
>>
>>  -Hal
>>
>>>
>>> -Matt
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> -- 
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170124/33f6dac6/attachment.html>