[llvm-commits] Reassociating for vectors

[Duncan Sands]

Hi Hal,

>> it would be easy enough to have reassociate always write things out as
>> some kind of balanced tree rather than linearly,
>
> Duncan,
>
> Can you sketch out how this would be done? It looks like you'd just
> want to change the recursion used by Reassociate::RewriteExprTree, is
> that right?

yes.

>> though I'm not sure
>> what the best output order is.  For example in a+b+c+d+e+f+g+h with
>> these being ever more complicated (i.e. ordered by increasing 'rank'
>> as computed by reassociate), how should they be grouped?  Should it
>> be
>>     ((a+b)+(c+d))+((e+f)+(g+h))
>> ?  That would put high rank elements together (eg g+h).  Or should it
>> be something like
>>     ((a+e)+(c+g))+((d+h)+(b+f))
>> which tries to spread low rank around.  Or something else?
>
> I'm not sure there is a best answer here, we'd probably want some kind
> of relative-disbalance metric to decide. It probably also depends on
> what else is going on (if there is other work to be scheduled
> concurrently, then spreading the low rank around would probably be good
> because it will leave plenty of interspersed spare cycles in which to
> put other things). Does instruction scheduling also understand about
> associative instructions? If it does, then the choice may not matter in
> the same way.
>
> If it is easy enough to choose, we could implement both and then
> experiment.
>
> Also, do we need to be careful about changing the default ordering as it
> is used now because doing so might hurt CSE?

It should be easy enough to experiment with different versions of
RewriteExprTree, I may try to whip something up.

Also, if the needs of the vectorizer turn out to not match those of reassociate,
it would be easy to factorize LinearizeExprTree out of reassociate so it could
be used both by reassociate and the vectorizer.

Ciao, Duncan.