Re: rfc and [autovect patch] supporting reduction patterns

[Richard Henderson <rth at redhat dot com>]

On Tue, Apr 05, 2005 at 05:37:46PM +0300, Dorit Naishlos wrote:
> I think option 1 (generic) is suitable here because the idioms in question
> are general and pretty common, and this way we can avoid code duplication
> between different targets.

What idioms, precisely?  Because I don't see anything of the kind for
any of the Intel architectures.  Before I accept the assertion that
they are "pretty common" I would like to know that they actually ocurr
on more than just Altivec.

> If we go with option 1 (generic), there are still a couple of alternatives
> for how to define the semantics of the new optabs:
> 
> - option 1.1: the type-size of the reduction variable (which is also the
> result of the computation) is exactly double the type-size of the reduction
> arguments. i.e, we can express summation of QI into HI, but we can't
> express summation of QI into SI. We can solve this by either introducing an
> additional tree-code&optab for "wider_widen_sum" (for which the type-size
> of the reduction variable is 4 times the type-size of the other arguments),
> or, leave the wider reduction forms for target specific builtins.
> 
> - 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.

I am aware of some targets that have, e.g. 40 bit accumulators.  But
these are scalars, not vectors, and so don't really apply in your case.


r~