Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

[Jason Merrill <jason at redhat dot com>]

On Tue, Nov 1, 2016 at 11:59 AM, Jiong Wang <jiong.wang@foss.arm.com> wrote:
> On 01/11/16 15:24, Jason Merrill wrote:
>> On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang <jiong.wang@foss.arm.com> wrote:
>>> On 31/10/16 19:50, Jason Merrill wrote:
>>>> On 10/21/2016 04:30 AM, Jiong Wang wrote:
>>>>>
>>>>> All DW_OP_* of the expression are grouped together inside the PARALLEL,
>>>>> and those operations which don't have RTL mapping are wrapped by
>>>>> UNSPEC.  The parsing algorithm is simply something like:
>>>>>
>>>>>    foreach elem inside PARALLEL
>>>>>      if (UNSPEC)
>>>>>        {
>>>>>          dw_op_code = INTVAL (XVECEXP (elem, 0, 0));
>>>>>          oprnd1 = INTVAL (XVECEXP (elem, 0, 1));
>>>>>          oprnd2 = INTVAL (XVECEXP (elem, 0, 2));
>>>>>        }
>>>>>      else
>>>>>        call standard RTL parser.
>>>>>
>>>>> Any comments on the approach?
>>>>
>>>> If you're going to use UNSPEC, why not put the DWARF operator in the
>>>> second operand?
>>>
>>>    Thanks for the review, but I still don't understand your meaning.
>>>
>>>    Do you mean I should simply put the DWARF operator at XVECEXP
>>> (UNSPEC_RTX, 0, 2) instead of at XVECEXP (UNSPEC_RTX, 0, 0)
>>
>> No, at XINT (UNSPEC_RTX, 1).  The documentation of UNSPEC says,
>>
>> /* A machine-specific operation.
>>     1st operand is a vector of operands being used by the operation so
>> that any needed reloads can be done.
>>     2nd operand is a unique value saying which of a number of
>> machine-specific operations is to be performed.
>
> Aha, understood now, thanks for the clarification.
>
> You mean we simply reuse the UNSPEC number field, so the RTX will be
>
>       (UNSPEC
>          [((reg) (reg)]
>        DW_OP_XXX)
>
> Yeah, I do have tried to do that, but later give up, one reason I remember is suppose we
> want to push two value on the stack, the second value is an address, which we want a
> follow up DW_OP_deref to operate on that. then the value expression will be
>
>    (set (reg A)
>     (parallel
>       [(reg A)
>
>         (UNSPEC
>           [DW_OP_deref, const0_rtx, const0_rtx]
>         UNSPEC_PRIVATE_DW);
>
>        (UNSPEC
>          [DW_OP_XXX (const0_rtx) (const0_rtx)]
>         UNSPEC_PRIVATE_DW))
>
> And there might be some other expressions we need some complex RAW encoding,

Why can't you do this putting the OP in the number field of both UNSPECs?

> so it seems to me if we want to offer user the most general way to do this, then it's
> better to encode the DWARF operation inside UNSPEC as reuse the UNSPEC number then you need to make
> sure there is no overlap with other backend UNSPEC enumeration number.

It seems to me that a CFA_*expression note would never use target
UNSPEC codes, and a DWARF UNSPEC would never appear outside of such a
note, so we don't need to worry about conflicts.

Jason