Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

[Michael Matz <matz@suse.de>]

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