Re: rfc and [autovect patch] supporting reduction patterns

[Diego Novillo <dnovillo at redhat dot com>]

On Tue, Apr 05, 2005 at 05:37:46PM +0300, Dorit Naishlos wrote:

> If we go with option 1 (generic), there are still a couple of alternatives
> for how to define the semantics of the new optabs:
> 
I agree.  Option 1 sounds more appealing.  We can always have
generic expansion for targets that don't support the operations.

> - option 1.2: the type of the reduction variable is always X (some default
> predefined by each target). e.g., always sum into 32bit accumulators (if
> the target defines X to be 32). This may not be suitable for targets that
> have multiple accumulation sizes, however, one could often support the
> smaller-sized accumulations by truncating the final result produced by
> wider-sized accumulations, so this could potentially suffice to cover all
> reduction forms a target supports. If not, then we could resort to target
> specific builtins for the cases we can't express with these optabs.
> 
How often do you think we will have code that reduces into
such different type sizes?  It doesn't seem to be that this will
be too common.  Setting reduction sizes to some X seems easiest.


Diego.