[llvm-commits] Reassociating for vectors

[Andrew Trick]

On May 26, 2012, at 6:13 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> On Sat, 26 May 2012 00:06:29 -0700
> Andrew Trick <atrick at apple.com> wrote:
> 
>> On May 25, 2012, at 7:38 PM, Hal Finkel wrote:
>>> This interests me because I also need some procedure for
>>> reassociating in order to have basic-block vectorization do
>>> something interesting for reductions. To start, I'd want
>>> a+b+c+d+e+f+g+h, regardless of the original association, to be
>>> transformed into: (a+b)+(c+d)+(e+f)+(g+h) or (a+b+c+d)+(e+f+g+h)
>>> [the number of groups should depend on the target's vector length,
>>> and maybe some other things as well].
>>> 
>>> I'm not sure whether I should try to bake this into Reassociate, or
>>> refactor Reassociate so that parts of it can be used by
>>> BBVectorize, or something else. Do you have an opinion?
>> 
>> This sounds to me like something BBVectorize should do only after
>> determining the expression is vectorizable.
> 
> It seems like, in general, such a transformation exposes
> ILP, and that would be good even if the result did not vectorize. Do
> you think I'm wrong about that?

I'd like think think about three levels of reassociation. I'm kind of making this up, so people should feel free to correct me:

1) Canonical reassociation (early)
   - fold constants
   - reduce total number of operations
   - order operands by rank to simplify CSE, InstCombine, etc.

2) On-demand reassociation (middle)

   A specific optimization pass may benefit from a particular form. We
   can take a purely canonical view of the expression, determine
   whether it matches the optimization, then rewrite IR using
   associative properties to fit the optimization.

   I think your vectorization is a good example of this.

   We just need a utility to query the canonical expression. SCEV is
   one such example. Duncan also seems to have created a light weight
   utility in Reassociate.cpp.

   Rewriting is really the hard part. I personally think you need to
   map expressions back to the IR to do it safely, not like
   SCEVExpander. I just don't think it makes sense for the purely
   canonical expression to capture every bit of information from the
   IR.

3) Reassociation for CodeGen (late)

   This needs to be done after all the optimization run that depend on
   the canonical form. Also, it only makes sense in the context of a
   specific target. This mainly has to do with balancing register
   pressure and ILP.

   I think it's tempting to do this in IR during CodeGenPrepare. It
   might not be a bad idea, but would depend on some shady heuristics
   and may pessimize code. We currently have an intention of doing
   this more precisely during the MISched pass. After building the
   DAG, before scheduling, we know register pressure and critical path
   in the DAG. The idea is to reassociate on-the-fly and update the
   DAG and LiveIntervals accordingly.

-Andy