Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader

[Bernd Schmidt <bschmidt at redhat dot com>]

On 10/05/2016 06:15 PM, David Malcolm wrote:
> +;; MEM[(struct isl_obj *)&obj1] = &isl_obj_map_vtable;
> +(insn 1045 0 1046 2 (set (reg:SI 480)
> +        (high:SI (symbol_ref:SI ("isl_obj_map_vtable")
> +                    [flags 0xc0]
> +                    <var_decl 0x7fa0363ea240 isl_obj_map_vtable>)))
> +     y.c:12702 -1
> +     (nil))
> +(insn 1046 1045 1047 2 (set (reg/f:SI 479)
> +        (lo_sum:SI (reg:SI 480)
> +            (symbol_ref:SI ("isl_obj_map_vtable")
> +               [flags 0xc0]
> +               <var_decl 0x7fa0363ea240 isl_obj_map_vtable>)))
> +     y.c:12702 -1
> +     (expr_list:REG_EQUAL (symbol_ref:SI ("isl_obj_map_vtable")
> +                             [flags 0xc0]
> +                             <var_decl 0x7fa0363ea240 isl_obj_map_vtable>)
> +        (nil)))

I hate saying this, since you've obviously spent a lot of effort, but I 
think we're still at a too early stage to construct testcases. One issue 
that came up while discussing previous patch kits is that the format 
here is still too verbose, and I'd like to settle on a format first. 
There's all manner of things that are pointless in a testcase and impede 
readability:

 * INSN_UIDs and NEXT/PREV fields (could be constructed from scratch,
   except for labels)
 * INSN_CODE_NUMBERs in both textual and number form.
 * Various (nil) fields
 * VAR_DECL addresses.

What does the RTL reader actually do with MEM_ATTRs? Do these survive 
the dump/read process?

There was also a testcase where virtual regs still occurred with 
register number, I think it would be best to disallow this and add the 
ability to parse "(reg:DI virtual-outgoing-args)".

Also I think I'd prefer testcases submitted separately from the RTL 
frontend. It seems we have two different frontend approaches here, one 
RTL frontend and one modification for the C frontend - which do you prefer?


Bernd