[llvm-commits] Reassociating for vectors
atrick at apple.com
Tue May 29 14:42:34 PDT 2012
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
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.
More information about the llvm-commits