[llvm-dev] EuroLLVM Numerics issues

[Michael Berg via llvm-dev]

Folding  a couple of topics back into this thread:

<email from cameron.mcinally at nyu.edu <mailto:cameron.mcinally at nyu.edu>>

I'd like to touch on a topic mentioned in the blog post. The constrained intrinsics work is at a road block on how to proceed with the constrained  implementation in the backends, i.e. D55506. Reviews/ideas in this area would be greatly appreciated (attn: target code owners). 

Thanks,
Cameron

<email from venkataramanan.kumar.llvm at gmail.com <mailto:venkataramanan.kumar.llvm at gmail.com>>

Just like to point out few things that I thought is related to FP Numerics.
LLVM could do some additional transformation with "sqrt" and "division" under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x.   These are long latency instructions and could get benefit if enabled under unsafe math.

 Also are we considering doing such FP transforms on vector floating point types?

regards,
Venkat.

> On Apr 3, 2019, at 9:30 AM, David Greene <dag at cray.com> wrote:
> 
> "Kaylor, Andrew via llvm-dev" <llvm-dev at lists.llvm.org> writes:
> 
>> ====================
>> 
>> Masked vector FP operations
>> 
>> ====================
>> 
>> We’ve resisted adding explicitly predicated operations other than load
>> and store in the past, but I think for vector FP operations we’re
>> going to need this in order to maintain strict FP semantics.
> 
> Yep, we definitely will.  This is one of the reasons Simon Moll's
> predication work (D57504) is so important.
> 
>> ====================
>> 
>> Complex types
>> 
>> ====================
>> 
>> There, I said it.
> 
> I'll echo my colleague's response.
> 
> Oh hell yes!  OH HELL YES!  :)
> 
>> ====================
>> 
>> Accuracy controls
>> 
>> ====================
>> 
>> We have a fast math flag that lets us substitute approximations for
>> some math library functions. It would be nice to have a mechanism to
>> control the accuracy of the approximations.
> 
> Indeed.  "Fast or not" is too coarse.
> 
>> ====================
>> 
>> Per function controls
>> 
>> ====================
>> 
>> Similarly, it would be nice to explicitly list which math library functions could be replaced.
> 
>> I’d also like to suggest the formation of a floating point working
>> group to try to get more organized about driving some of these things
>> (particularly the constrained intrinsics) toward completion.
> 
> That's a great idea.
> 
>                         -David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190403/226acbcc/attachment.html>