On 01/11/16 16:48, Jason Merrill wrote:
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?
I was demoing the RTX based on my current approach, and simplfy want to
say we only need to
define one unspec number (UNSPEC_PRIVATE_DW), while if we putting the OP
in the number field
of both UNSPECs, we need two unspec number, and we might need more for
other similar expressions.
If we don't need to worry about the conflicts, then your suggestion is
definitely better. I will do more tests
on this.
Besides this issue, do you think the PARALLEL + UNSPEC based approach to
represent DWARF RAW expression is acceptable?
Thanks.
Regards,
Jiong
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
