Re: [PATCH] dwarf: Multi-register CFI address support.

[Jakub Jelinek <jakub@redhat.com>]

On Sun, Jun 13, 2021 at 02:27:38PM +0100, Hafiz Abid Qadeer wrote:
> *** with this patch (edited for brevity)***
> 
> 00000000 00000024 ffffffff CIE
> 
>   DW_CFA_def_cfa_expression: DW_OP_bregx SGPR49+0, DW_OP_const1u 0x20, DW_OP_shl, DW_OP_bregx SGPR48+0, DW_OP_plus
>   DW_CFA_expression: reg16 DW_OP_bregx SGPR51+0, DW_OP_const1u 0x20, DW_OP_shl, DW_OP_bregx SGPR50+0, DW_OP_plus
> 
> 00000028 0000003c 00000000 FDE cie=00000000 pc=00000000...000001ac
>   DW_CFA_advance_loc4: 96
>   DW_CFA_offset: reg46 0
>   DW_CFA_offset: reg47 4
>   DW_CFA_offset: reg50 8
>   DW_CFA_offset: reg51 12
>   DW_CFA_offset: reg16 8
>   DW_CFA_advance_loc4: 4
>   DW_CFA_def_cfa_expression: DW_OP_bregx SGPR47+0, DW_OP_const1u 0x20, DW_OP_shl, DW_OP_bregx SGPR46+0, DW_OP_plus, DW_OP_lit16, DW_OP_minus

I guess as a temporary solution until DWARF6 comes with something more
compact for cases like that it can be fine, but is there a DWARF issue
filed for it?  Is AMDGCN a DWARF2_ADDR_SIZE == 8 target?

> +/* This represents a register, in DWARF_FRAME_REGNUM space, for use in CFA
> +   definitions and expressions.
> +   Most architectures only need a single register number, but some (amdgcn)
> +   have pointers that span multiple registers.  DWARF permits arbitrary
> +   register sets but existing use-cases only require contiguous register
> +   sets, as represented here.  */
> +struct GTY(()) cfa_reg {
> +  unsigned int reg;
> +  unsigned int span;
> +  poly_uint16_pod span_width;  /* A.K.A. register mode size.  */

If this is only used for span > 1, wouldn't it be better to
make it
  unsigned int reg;
  unsigned short span;
  unsigned short span_width;
and keep span_width 0 for the span == 1 cases and only set span_width
to ....to_constant () if span > 1 is needed?  If at least for now
the only target that needs this is AMDGCN and the only target that has
NUM_POLY_INT_COEFFS != 1 is aarch64 (maybe eventually riscv?), then I don't
see why we should represent it in poly_uint16...
Of course we can change it later if a target which needs both
NUM_POLY_INT_COEFFS > 1 and span > 1 registers with non-constant span_width,
we can change it, but doing it just in case seems unnecessary
complication...

	Jakub