[llvm-commits] [PATCH][Instcombine, FAST-MATH] Some enhancement to Fmul

[Shuxin Yang]

On 01/02/2013 05:53 PM, Chandler Carruth wrote:
> On Wed, Jan 2, 2013 at 5:48 PM, Shuxin Yang <shuxin.llvm at gmail.com 
> <mailto:shuxin.llvm at gmail.com>> wrote:
>
>     Canonicalization will help if one of the operands is constant.
>
>
> And in both of these patches, the optimizations only trigger when one 
> of the operands is constant.

Maybe I were not clear in my previous mail(s). I said "I give up if both 
operands are constant", it
refers to the "X" in "f = x * c and x = c1 op c2".
In this situation, I give up because I think "c1 op c2" must be folded 
earlier.

For any multiplication with constant, be it in the form of x * c or c * 
x, I can handle it uniformly.
This is because I call std::swap() to switch multiplication operands if 
the 1st one is constant.

>     Otherwise, its meaning is pretty vague.  Consider the the case
>     "(select c ? v1 : v2) * (m + n)", which form is canonical?
>        (select ...) * (.. + ... ) or "(..+...) * (select ...)?
>
>
> Even here, I think it is fundamentally the right architecture to pick 
> a canonical form and rewrite to that form. If we get it wrong, it is 
> easy to fix. The codegen layer should reorder things however is best 
> on the architecture regardless of the particular ordering we 
> canonicalize to in the IR. The point of canonicalization is not that 
> one form is "better" than another, but merely to constrain the search 
> space and improve our ability to match patterns consistently.

You may define "add" should permute after "select", and "sub" should be 
permute before "select".
What if I need to handle "(select cond ? 1 : 0) * whatever"?

I believe my way to tackle this situation is not too ugly -- it is at 
the cost of no more than 5 lines of code to enclose
a big chunk of logic which handle symmetric opportunities.

   for (int i = 0; i < 2 ; i++) {
       ...detect the pattern ..
       std::swap(operands)
   }






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130102/2776d24d/attachment.html>