[tree-ssa] vectorizer related issues

[Richard Henderson]

On Tue, Dec 16, 2003 at 03:05:16PM +0200, Dorit Naishlos wrote:
> (1) Array addressing using pointers.
...
> Is anyone planning to fix this situation?

Yes.  I've been fixing is slowly, but there appear to be quite a lot
of hidden problems.  My last patch, which mearly *preserves* array_ref
on arrays in situations that we lower to pointer arithmetic in the 
front end, had to be reverted because of bootstrap miscompilation.  
I've not yet figured out what went wrong.

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

Eh?  I thought this was already the case...

> The vectorizer can take care of these inefficiency issues by itself. Q3.1:
> should it? It's simply a design decision.

I think the answer is "how difficult is it to do locally relative to
re-running other scalar cleanup operations?"  I.e.  if it's simple
enough to do locally then do so, but don't work so hard as to duplicate
one of the existing scalar cleanup passes.

Certainly as a starting point I wouldn't bother doing any cleanups
yourself.  We should just re-run other optimizers as needed.  We can
decide what needs doing here later.

> Q4.1: Are there any naming conventions?

Not to my knowledge, but there should be.

> (6) modeling the target vector support:

Looking at optabs for specific operations is reasonable.

As for knowing whether a vector mode ought to be handlable at all
is available from VECTOR_MODE_SUPPORTED_P.  The interface isn't
ideal, since you have to iterate over all modes, but all required
information is present.

Note that checking "the vector size" isn't reasonable, because
there is no fixed vector size.  Consider i386 which has both
MMX (8 byte vectors) and SSE (16 byte vectors).

> Q6.3: Should we add new TREE_CODES (and corresponding optabs?) for the
> new types of operations we want to express?

Generic concepts such as dot product and saturating arithmetic should
not be handled with target-specific additions.  Whether this should be
tree codes or target-independent builtins is an open question.  Myself
I kinda like tree codes, but I seem to recall we're pressed for space
there.

> (Q6.6: ) how to address the problem that the
> compiler doesn't attempt to perform any optimizations around target
> specific builtins, not even to SSA their arguments

This should be fixed, IMO.



r~