Hello,
On Wed, 17 Mar 2021, Richard Biener wrote:
> > 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.
Structurally, sure.
> They just even pre-SSA distinguish between registers and memory.
And that's of course the thing.
I probably should have used a different term, but used "SSA rewriting" to
name the point where this distinction really starts to matter. Before it
a binary gimple statement could conceivably contain a non-register in the
LHS (perhaps not right now, but there's nothing that would inherently
break with that), and then would include a store that
walk_stmt_load_store_addr_ops would "miss".
So, yeah, using SSA as name for that was sloppy, it's gimple itself that
has the invariant of only registers in binary statements.
Ciao,
Michael.
> 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.
>
