search for: fmas

There is no way to disable FMAs with 'fast' ops in LLVM. I would like to propose that LLVM's -fp-contract=off should disable fusion, regardless of any other flags since the Clang option suggests this to be the case: $ clang --help | grep fp-contract -ffp-contract=<value> Form fused FP ops (e.g. FMAs): fas...

...ight thing with it, so it is unlikely any out-of-tree target is either...) To un-break your build after this patch goes through, you will need to rename isFMAFasterThanMulAndAdd to isFMAFasterThanFMulAndFAdd and ensure that it returns true for any type that eventually legalizes to a type for which FMAs are faster than FMul + FAdd (which usually means you have hardware support of the operation.). You can look at in-tree target implementations as an example. Please let me know if there are any objections before tomorrow morning. Stephen ---------- Forwarded message ---------- From: Stephen Lin &...

...l 10, 2019 at 2:52 PM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Jul 10, 2019, at 15:27, Scott Manley via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Is there context I am not aware of for ::Strict and ISD::FMAD? I could see > value in generating FMAs when its expanded form would be identical -- but > curious if that was actually the intent or not. If it is, perhaps we could > allow "Standard/on" to fuse ops if FMAD is available instead of the > "Strict" level? In any case, we should still have a way to explicitly tu...

...other options in both clang and llvm? At any rate, I was only offering an additional reason. Personally I think it's strange for an option to say "this will never fuse ops" and then under the covers will fuse ops, regardless of how FMAD is defined. However, my primary concern is for FMAs. They have both numeric and performance implications and I do not think it's unreasonable that off means off. On Wed, Jul 10, 2019 at 3:36 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Wed, 10 Jul 2019 at 21:09, Scott Manley via llvm-dev > <llvm-dev at lists.llvm.or...

On Mon, 2 Sep 2019 at 16:59, Roman Lebedev <lebedev.ri at gmail.com> wrote: > > It appears you need 'reassoc' on fmul/fadd: > https://godbolt.org/z/nuTzx2 Thanks very much, that was it. Either that or providing -enable-unsafe-fp-math to llc yielded FMAs. I didn't expect this since using FMAs here instead of mul/add appears to be safer (the reverse is unsafe). ~ Uday > > On Mon, Sep 2, 2019 at 2:20 PM Uday Kumar Reddy B via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > On the appe...

...ses another question about IR > > > canonicalization (and may affect the proposed revision to IR FMF): > > > > > > No, I think that we specifically don't want to canonicalize to > > fmuladd at the IR level at all. If the backend has the freedom to > > form FMAs as it sees fit, then we should delay the decision until > > whenever the backend finds most appropriate. Some backends, for > > example, form FMAs using the MachineCombiner pass which considers > > critical path, latency, throughputs, etc. in order to find the best > > fusio...

...com> wrote: > > At any rate, I was only offering an additional reason. Personally I think > it's strange for an option to say "this will never fuse ops" and then under > the covers will fuse ops, regardless of how FMAD is defined. However, my > primary concern is for FMAs. They have both numeric and performance > implications and I do not think it's unreasonable that off means off. > > > I think you have a different definition of fused then. Fused is a > description of how the operation is computed/rounded, not an instruction > count. The F in...

...t;> > >>> At any rate, I was only offering an additional reason. Personally I > think it's strange for an option to say "this will never fuse ops" and then > under the covers will fuse ops, regardless of how FMAD is defined. However, > my primary concern is for FMAs. They have both numeric and performance > implications and I do not think it's unreasonable that off means off. > >> > >> I think you have a different definition of fused then. Fused is a > description of how the operation is computed/rounded, not an instruction > cou...

...straight now (thanks for the explanation, Hal!), I think it raises another question about IR canonicalization (and may affect the proposed revision to IR FMF): No, I think that we specifically don't want to canonicalize to fmuladd at the IR level at all. If the backend has the freedom to form FMAs as it sees fit, then we should delay the decision until whenever the backend finds most appropriate. Some backends, for example, form FMAs using the MachineCombiner pass which considers critical path, latency, throughputs, etc. in order to find the best fusion opportunities. We only use fmuladd whe...

We're migrating to LLVM 3.1 and trying to use the upstream FMA patterns. Why is VFMADDSD4 defined with vector types? Is this simply because the gcc intrinsic uses vector types? It's quite unnatural if you have a compiler that generates FMAs as opposed to requiring user intrinsics. -Dave

...t: [LLVMdev] X86 FMA4 > > We're migrating to LLVM 3.1 and trying to use the upstream FMA patterns. > > Why is VFMADDSD4 defined with vector types?  Is this simply because the > gcc intrinsic uses vector types?  It's quite unnatural if you have a > compiler that generates FMAs as opposed to requiring user intrinsics. > >                               -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu        http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

...'s only unsafe in so far as one's code > is actually depending on an imprecise result. Giving more-than-expected precision can be just as bad for the user as less. It tends to come up in situations where the optimization would break some symmetry, the same way that aggressively forming FMAs can break user code. Consider this example: float foo(float a, float b) { return pow2(a) - pow2(sqrt(b)); } float bar(float c) { return foo(sqrt(b), b); } The author *should* be able to assume that for any positive c, the only possible output values are Inf and zero. However, if we apply t...

> This is not true. The mathematically correct result for sqrt might not be a representable value in floating point, so rounding may occur between the two steps. In that case, pow2(sqrt(x)) != x. > > --Owen I think what Christoph is saying is that x will always be at least as accurate as pow2(sqrt(x)), so it's only unsafe in so far as one's code is actually depending on an

Am Dienstag, 23. April 2013, 22:50:51 schrieben Sie: > [...] > Giving more-than-expected precision can be just as bad for the user as less. > It tends to come up in situations where the optimization would break some > symmetry, the same way that aggressively forming FMAs can break user code. > [...] > > It boils down to the fact that giving excess precision in > some-places-but-not-others can lead to bad behavior. Ok, I didn't think about excess precision resulting in problems. Now it's clear to me that fast-math is neccessary for this optimi...

...; no signed zeros (S) > - ignore the existence of negative zero when convenient while the above flags make perfect sense for me, the other two seem more dubious: > allow fusion (F) > - fuse FP operations when convenient, despite possible differences in rounding > (e.g. form FMAs) > unsafe algebra (A) > - allow for algebraically equivalent transformations that may dramatically > change results in floating point. (e.g. reassociation) They don't seem to be capturing a clear concept, they seem more like a grab-bag of "everything else" (A) or &qu...

...eve that the term "legal" is associated with the Legalize phase. Please see: http://llvm.org/docs/CodeGenerator.html#selectiondag-legalize-phase The x86 backend has a good example of this in llvm/lib/Target/X86/X86ISelLowering.cpp: > if (Subtarget->hasFMA()) { > // Support FMAs! > setOperationAction(ISD::FMA, MVT::f64, Legal); > setOperationAction(ISD::FMA, MVT::f32, Legal); > } > else { > // We don't support FMA. > setOperationAction(ISD::FMA, MVT::f64, Expand); > setOperationAction(ISD::FMA, MVT::f32, Expand); > } Hope tha...

...gt; > > We're migrating to LLVM 3.1 and trying to use the upstream FMA patterns. > > > > Why is VFMADDSD4 defined with vector types? Is this simply because the > > gcc intrinsic uses vector types? It's quite unnatural if you have a > > compiler that generates FMAs as opposed to requiring user intrinsics. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120726/23bfe115/attachment.html>

...initial proposal, it could be ok. But if more complex metadata is possible (like I've described), then this approach could consume more bitcode size, than expected. And I'm sure there will be attempts to add fine-grain precision control. And the first candidate is probably enabling/disable FMAs. Inlining is a valid concern, though inside the single module fp model will be the same in absolute majority of cases. People also tend to have consistent flags across the project, so it shouldn't be rare case when it's consistent between modules. Function or module level default setting...

...se unique identifier lines and perform all other checks localized to between the appropriate blocks; it can ever recover from an error in one block and move on to another. As an example, I purposely introduced the a switch fall-through bug in the last patch I submitted to llvm-commits ("Allow FMAs in safe math mode in some cases when one operand of the fmul is either exactly 0.0 or exactly 1.0")... Bug diff: diff --git a/lib/CodeGen/SelectionDAG/DAGCombiner.cpp b/lib/CodeGen/SelectionDAG/DAGCombiner.cpp index 0290afc..239b119 100644 --- a/lib/CodeGen/SelectionDAG/DAGCombiner.cpp +++ b...

On Fri, 2014-09-26 at 12:09 -0400, Stephen Canon wrote: > > On Sep 26, 2014, at 11:59 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > > >> I know it's part of test-suite/external, but this constant fold code has > >> been around 5+ years. Was the bug lying dormant all this time, only visible > >> on PPC, or something else? > > >