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

[Shuxin Yang]

On 1/2/13 5:10 PM, Chandler Carruth wrote:
> On Wed, Jan 2, 2013 at 5:01 PM, Shuxin Yang <shuxin.llvm at gmail.com 
> <mailto:shuxin.llvm at gmail.com>> wrote:
>
>     Hi,
>
>        The attached patch is to implement following rules. (Please
>     ignore the changes to APFloat.{h,cpp}).
>
>        1. X/C1 * C2 => X * (C2/C1) (if C2/C1 is neither special FP nor
>     denormal)
>        2. X/C1 * C2 -> X/(C1/C2)   (if C2/C1 is either specical FP or
>     denormal, but C1/C2 is a normal Fp)
>
>         Let MDC denote multiplication or dividion with one & only one
>     operand being a constant
>       3. (MDC +/- C1) * C2 => (MDC * C2) +/- (C1 * C2)
>         (so long as the constant-folding doesn't yield any denormal or
>     special value)
>
>
> I would separate this into two patches: one for #1 and #2, the second 
> patch for #3.
   I can separate them into two parts, but I don't think it will make 
things tons better as both set of optimizations are pretty trivial (
at very least, conceptually so).

>
> I feel like this (and a lot of future transformations) would be 
> greatly simplified by two things:
>
> a) Have InstCombine do operand order canonicalization when it can due 
> to fastmath the same as we do for integers. This is a key element of 
> bounding the complexity of implementing fundamental scalar math 
> simplifications, and it will remove a lot of the testing for which 
> side of an operation a constant is on.
Canonicalization will help if one of the operands 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 ...)?

In my code I use 2-iteration-loop to tackle the symmetric situations in 
order to avoid code duplication.
I guess this may alleviate the problem a bit.
>
> b) Build up a set of rich pattern matching routines for the floating 
> point properties your checking here: is normal, is denormal, etc etc.
I agree with you in general.
The biggest problem is how to factor things out and implement them by 
some pattern matching routines, and
in the mean time keep the interface clean and easy to understand. This 
is difficult in practice.
If the pattern match routines are used only once, you are better off 
directly implementing the logic.

Pattern matching is intrinsically messy. I don't expect it is as clean 
as loop nest optimizations.

>
>
> Once we have these two in place, optimizations such as this should be 
> able to be written in a very short, declarative pattern that is easier 
> to maintain and organize in the long-term.
>
> Thoughts?

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