RFC: Modeling horizontal vector reductions

[Hal Finkel]

----- Original Message -----
> 
> On Sep 11, 2013, at 5:30 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> 
> > 
> > On Wed, Sep 11, 2013 at 3:17 PM, Arnold Schwaighofer
> > <aschwaighofer at apple.com> wrote:
> > Therefore, I would like to model horizontal reductions as either
> > versions depending on which is deemed cheaper by the cost model.
> > 
> > What would make the first pattern cheaper? I'd like to better
> > understand why we don't just all ways do the second form…
> 
> Less shuffles (because shuffle vec, <0,1, undef, undef> is free) so
> when you don’t have pairwise vector operations the first pattern is
> preferable.

+1

> 
> 
> > It is a bit unfortunate to not have one canonical form but I don’t
> > think this justifies adding fast-math flags to isel (which will
> > eventually go away).
> > 
> > I don't really understand this part.
> > 
> > We have some reason at the IR level to know that we can choose
> > either association and get equivalent results. Why isn't the
> > correct answer to pick a canonical form, but preserve that
> > information long enough to reassociate when it is needed?
> 
> We want to pick the right form at ISel time - which is too late to
> reassociate.

Why? We have TM.Options.UnsafeFPMath, is that what you mean?

 -Hal

> 
> At some point - before ISel - we have to reasscociate because at ISel
> time we don’t have the fast-math flags that would tell us that it is
> legal to reassociate.
> 
> So, we could for example reassociate in CodeGen prepare. We would
> still need an interface to tell us when to do so.

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory