On Tue, Mar 16, 2021 at 4:25 PM Michael Matz <m...@suse.de> wrote:
>
> Hello,
>
> On Tue, 16 Mar 2021, Thomas Schwinge wrote:
>
> > >>Indeed, given (Fortran) 'zzz = 1', we produce GIMPLE:
> > >>
> > >> gimple_assign <real_cst, zzz, 1.0e+0, NULL, NULL>
> > >>
> > >>..., and calling 'walk_stmt_load_store_addr_ops' on that, I see, as
> > >>expected, the 'visit_store' callback invoked, with 'rhs' and 'arg':
> > >>'<var_decl zzz>'.
> > >>
> > >>However, given (Fortran) 'zzz = r + r2', we produce GIMPLE:
> > >>
> > >> gimple_assign <plus_expr, zzz, r, r2, NULL>
>
> But that's pre-ssa form. After writing into SSA 'zzz' will be replaced by
> an SSA name, and the actual store into 'zzz' will happen in a store
> instruction.
>
> > >>..., and calling 'walk_stmt_load_store_addr_ops' on that, I see,
> > >>unexpectedly, no callback at all invoked: neither 'visit_load', nor
> > >>'visit_store' (nor 'visit_address', obviously).
> > >
> > > The variables involved are registers. You only get called on memory
> > > operands.
> >
> > How would I have told that from the 'walk_stmt_load_store_addr_ops'
> > function description? (How to improve that one "to reflect relatity"?)
> >
> > But 'zzz' surely is the same in 'zzz = 1' vs. 'zzz = r + r2' -- for the
> > former I *do* see the 'visit_store' callback invoked, for the latter I
> > don't?
>
> The walk_gimple functions are intended to be used on the SSA form of
> gimple (i.e. the one that it is in most of the time).
Actually they are fine to use pre-SSA. They just even pre-SSA distinguish
between registers and memory. That's what gimplification honors as well,
in 'zzz = r + r2' all operands are registers, otherwise GIMPLE requires loads
and stores split into separate stmts not doing any computation.
It's just less obivous in the dumps (compared to SSA name dumping).
Richard.
> And in that it's
> not the case that 'zzz = 1' and 'zzz = r + r2' are similar. The former
> can have memory as the lhs (that includes static variables, or indirection
> through pointers), the latter can not. The lhs of a binary statement is
> always an SSA name. A write to an SSA name is not a store, which is why
> it's not walked for walk_stmt_load_store_addr_ops.
>
> Maybe it helps to look at simple C examples:
>
> % cat x.c
> int zzz;
> void foo(void) { zzz = 1; }
> void bar(int i) { zzz = i + 1; }
> % gcc -c x.c -fdump-tree-ssa-vops
> % cat x.c.*ssa
> foo ()
> {
> <bb 2> :
> # .MEM_2 = VDEF <.MEM_1(D)>
> zzz = 1;
> # VUSE <.MEM_2>
> return;
> }
>
> bar (int i)
> {
> int _1;
>
> <bb 2> :
> _1 = i_2(D) + 1;
> # .MEM_4 = VDEF <.MEM_3(D)>
> zzz = _1;
> # VUSE <.MEM_4>
> return;
>
> }
>
> See how the instruction writing to zzz (a global, and hence memory) is
> going through a temporary for the addition in bar? This will always be
> the case when the expression is arithmetic.
>
> In SSA form gimple only very few instruction types can be stores, namely
> calls and stores like above (where the RHS is an unary tree). If you want
> to capture writes into SSA names as well (which are more appropriately
> thought of as 'setting the ssa name' or 'associating the ssa name with the
> rhs value') you need the per-operand callback indeed. But that depends on
> what you actually want to do.
>
>
> Ciao,
> Michael.
