[llvm-commits] [llvm-testresults] lab-mini-01__O3-plain__clang_DEV__x86_64 test results

[Daniel Berlin]

>> But on to my real point. I think it's important not to arbitrarily
>> reassociate, or otherwise canonicalize, unless the canonical form is
>> clearly superior in exposing real optimization.
>
> Andy,
>
> What do you mean by 'clearly'? We'd need to define some metric for this,
> and I'm not sure what that should be.

Shouldn't this metric be: "We should canonicalize to some form if it
makes life significantly simpler for passes and/or enables performance
improvements" (with some tradeoffs involved, of course)

The advantage of canonicalizing is that you have less patterns to
recognize (in a vectorizer or elsewhere), whereas without
canonicalization, the space you have to pattern match against somewhat
infinite, and you start to get a large number of optimization issues
caused by not supporting every possible pattern in every possible
pass.

Similar things occur during value numbering and CSE-like passes.
One or two deep chains are fairly easy to eliminate, but without some
completely canonical form, you would never eliminate subexpressions in
a+b+c+d+e+f+g+h written once as (a+(b+(c+d))) + (e + (f + (g + h)))
and once as  ((a+b) + c) + d) + (((e + f) + g) + h).

Ignoring the flags issue, which is completely valid, is there a good
reason not to canonicalize *everything*, so that you have consistent
patterns  you can write code against?

(IE if you could get the flags right, and we get performance
improvements from reassoc, is there a good reason not to do it?)