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). 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.
