Re: auto vectorization in gcc

[Daniel Berlin <dberlin at dberlin dot org>]

On Thursday, July 17, 2003, at 2:15 PM, David Edelsohn wrote:

> > > > > > Daniel Berlin writes:
>
> Dan> Especially since it's a matter of just making tree nodes with a 
> vector
> Dan> type, and performing standard tree ops on them.
>
> Dan> IE PLUS_EXPR of two trees with types of V4SF_type_node should 
> work just
> Dan> fine, and convert to the right vector RTL.
>
> Dan> If it doesn't, we should make it work.
>
> 	I believe part of the concern is alignment issues.
Then you *definitely* want to work on trees, not RTL.
You can force proper alignment at the tree level, but you don't have 
the original DECL at the RTL level, so you can't.

>  If the code
> was not originally written with vector types, we cannot guarantee that
> objects will have the appropriate alignment for SIMD instructions.

This is part of the analysis you perform before packing, with the added 
benefit that we can change alignment if we really want, or generate 
code to handle misalignment if we can't be sure.


>   We may
> not know this until the storage layout occurs during RTL generation.  
> Once
> we have committed to auto-vectorization in the trees and possible 
> skipped
> some scalar loop optimizations, how do we roll back once we determine 
> that
> the SIMD instructions cannot be generated efficiently?

> 	The issue isn't that we *have to* do auto-vectorization in RTL,
> but how do we deal with reality intervening at later compilation 
> stages?
>
> David