[llvm-commits] [PATCH][Fastmath, Instcombine] Enhancement of Fdiv

[Michael Ilseman]

On Jan 11, 2013, at 3:20 PM, dag at cray.com wrote:

> Shuxin Yang <shuxin.llvm at gmail.com> writes:
> 
>>> I would like to see this changed to produce X / (C1 * C2) precisely
>>> because of the reciprocal.  X / (C1 * C2) may still be acceptable even
>>> when the reciprocal is not.  In our compiler, for example, we have
>>> multiple levels of fp math safety and users can pick what they want.  It
>>> would be nice to map those to LLVM's optimizations when possible.
>>> 
>>>                                     -David
> 
>> We don't have flags to control this. This xform is controlled by
>> "fast-math", which implies
>> "unsafe algebra" which is the highest relax level. Maybe we should
>> introduce more flags to control
>> the precision? Michael?
> 
> I'm not saying we need to add more flags.  It sounded like there is a
> separate flag for reciprocal, but if not, it's not a big deal.  Don't
> worry too much about it.
> 
>> BTW,  I realized my previous response to this issue is not quite
>> to-the-point.
>> I didn't divide X/C1/C2 => X * 1/(C1*C2) in two steps:
>>   X/ (C1*C2) and optionally X * 1/(C1*C2)
>> due to the structure of the my code.  It is more convenient to fold
>> these two steps in one shot.
> 
> Yeah, I understand.
> 
>> I guess the reciprocal problem bug you as well. I will discuss with my
>> coworker Michale soliciting his insight about how to do it right.
> 
> Again, it's not too big a deal.  I might go in later and add a couple
> other flags that we could map to different optimization levels but that
> wouldn't be for a while.  I'll need to gain some experience with the
> code first.
> 
> What we did with 3.1 was add an FPOptLevel flag and mapped that to a few
> checks in instcombine.  I haven't submitted that patch yet but I
> probably will sometime this year.
> 
> Not your problem, so think no more about it.
> 

Does (X / C1) / C2 ==> X / (C1 * C2) preserve more precision than reciprocal? The idea behind UnsafeAlgebra (commonly denoted as "fast") is that if you're allowing unsafe algebraic transformations like reassociation, then you're already throwing a level of caution to the wind, and all other flags should be implied. If allowing reassociation of constants does guarantee more precision, and there are users who would desire that but not reciprocal or other aspects of "fast", then I'm ok with the idea of splitting out another flag. It'd be nice having help/guidance doing so, of course :-)

>                                    -David
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits