How to debug ssa optimizer

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Yes and the type system which is defined by the language (see the language
>     hook, types_compatible_p) so, the types are considered compatiable.
>
> Unless I'm reading comptypes wrong, the two pointer types are *not*
> compatible anyway ...

The original code for your example is

  extern const char version_string[];
  const char *v = version_string;

which is, obviously, valid C.  I managed to get my hands on the
MODIFY_EXPR in question by setting a breakpoint at line 1383 of
tree-pretty-print.c, conditional on node->ssa_name.version == 263 
(yes, the number is not the same as in your quoted example; that's
what I see in my edition of c-cppbuiltin.i.t28.ch)

It is (please forgive my having redacted debug_tree() output into
something readable w.r.t. type nodes)

 <modify_expr type <pointer_type char *>
    side-effects
    arg 0 <ssa_name type <pointer_type char *>
       var <var_decl v type <pointer_type char *>>
       version 263>
    arg 1 <addr_expr type <pointer_type char *>
        readonly constant invariant
        arg 0 <var_decl version_string type <array_type char []>>>>

The documentation of MODIFY_EXPR and ADDR_EXPR (i.e. comments in
tree.def) says exactly nothing about types.  Naively, the type of the
ADDR_EXPR ought to be <pointer_type type <array_type char []>>, which
is not the type of the source-language expression per C semantics --
in fact it is impossible to express that type in C (although it would
be possible if the array had a definite size).  I think the C front
end is treating ADDR_EXPR as having a built-in NOP_EXPR, so it can get
the language-semantic expected type, <pointer_type char *>, without
inserting another node in the AST.  The tree-ssa optimizers are
obviously happy with this, so I see no actual problem here.

zw