Re: [tree-ssa] vectorizer related issues

[Diego Novillo <dnovillo at redhat dot com>]

On Tue, 2003-12-16 at 08:05, Dorit Naishlos wrote:

> (2) virtual defs/uses.
>       This issue goes back to an action item on the tree-ssa todo list:
> "SSA information for arrays
>       The existing implementation treats arrays as an opaque object. A
> definition to an array location is treated as a definition for the whole
> array".
> 
> Q2.1: Is anyone planning to address this issue? (so that the vdefs/vuses of
> arrays will be connected only to may/must aliased references?)
> 
It's in my long term todo list but I haven't thought about it much.  One
vague idea was to try out the various SSA-for-arrays papers that are
floating about.  I don't know how they compare to the traditional
dependency analysis, though.


> By the way, (Q2.2:) is there an API that provides a mapping between a
> virtual def/use and the operand it corresponds to?
>
No, there isn't.  You're right.  GIMPLE is pretty explicit in memory
references.

> I currently do that as follows: if a (GIMPLE) stmt has any vdefs
> (vuses), I check that it has exactly one vdef (vuse), I assume that it
> corresponds to op0 (op1), and I expect that the stmt is of the form: op0 =
> SSA_NAME/CONST (SSA_NAME = op1). Then I verify that op0 (op1) is an
> ARRAY_REF. Is there a better way to do that?
>
Yes, that should be fine.  tree-sra.c does something similar for
structure references.  We could probably grow a few generic functions if
you find enough commonalities.

The only places you have to be careful are call-sites where you can have
multiple VDEFs for all call-clobbered variables or a single VDEF for
.GLOBAL_VAR (when num_call_sites x num_call_clobbered_vars is above some
threshold).

Other than that, I would first filter by statement code.  Array
references can only be found inside MODIFY_EXPRs.  To determine whether
it's an array or not, you can check the type of the variable in the
VDEF/VUSE operand.  If TREE_TYPE (SSA_NAME_VAR (VDEF_RESULT)) ==
ARRAY_TYPE, then you have an array store.  Similarly for loads.

> Q3.3: I'm assuming that if a stmt has multiple vdefs/vuses then it's either
> a non vectorizable stmt (CALL_EXPR, asm) or there are aliasing problems
> which also prevent vectorization. Are there cases involving stmts with
> multiple vdefs/vuses that are relevant for vectorization?
> 
There shouldn't be.  In fact, that's something interesting to add to the
SSA verifier.

> The vectorizer can take care of these inefficiency issues by itself. Q3.1:
> should it?
>
In principle, I would avoid doing this.  I'd rather have the vectorizer
specify what scalar cleanups need to be performed after it runs.  This
would be part of the info we give to the pass manager that we discussed
briefly recently
(http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00416.html).


> (4) naming conventions:
>       The vectorizer creates many new variables; looking at the tree-dumps,
> having more informative names for variables would be helpful; for example,
> when creating a pointer which is used to point to array b, maybe use p_b as
> a prefix. Q4.1: Are there any naming conventions?
> 
None.  Though we have loosely named them with a prefix that denotes
where they came from:

MT.n		Memory tags
SR.n		Scalar replacements
iftmp.n		Expanded ?: predicates
pretmp.n	PRE generated temporaries
T.n		Any other temporary

> 
> (5) stmt_info data structure:
>       During the analysis phases the vectorizer records some information
> per stmt. For example, a pointer to the vectorized version of each stmt;
> [ ... ]
>  Q5.2: Is it OK to
> add such a field (assuming the answer to Q5.1 is "no")?
>
Yes.  stmt_ann is meant to be an extensible scratch pad for this kind of
thing.  In the future we may want to split it up or convert some fields
into hash tables or have a more generic statement/variable annotation
machinery.

> Q5.3: In GIMPLE, are there stmts that have more than one def, and I mean
> vectorizable stmts, not CALL_EXPRs and such? are they conceivable, even if
> not exist today?
> 
Only asms.  Other than that, the only statements that generate values
are MODIFY_EXPR and CALL_EXPR.


Diego.