On Tue, Nov 1, 2016 at 11:59 AM, Jiong Wang <jiong.w...@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.w...@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
