spec: allow the use of fused multiply-add floating point instructions

[mundaym]

Fused multiply-add (FMA) floating point instructions typically provide improved accuracy and performance when compared to independent floating point multiply and add instructions. However they may change the result of such an operation because they omit the rounding operation that would normally take place between a multiply instruction and an add instruction.

This proposal seeks to clarify the guarantees that Go provides as to when rounding to float32 or float64 must be performed so that FMA operations can be safely extracted by SSA rules. I assume that complex{64,128} casts will be lowered to float{32,64} casts for the purposes of this proposal.

The consensus from previous discussions on the subject is that explicit casts should force rounding, as is already specified for constants:

❌ a := float64(x * y) + z  (1)
❌ z += float64(x * y)      (2)

There is also consensus that parentheses should not force rounding. So in the following cases the intermediate rounding stage can be omitted and a FMA used:

✅ a := x * y + z           (3)
✅ a := (x * y) + z         (4)
✅ z += x * y               (5)
✅ z += (x * y)             (6)

It is also proposed that assignments to local variables should not force rounding to take place:

✅ t := x * y; t += z       (7)

I also propose that an assignment to a memory location should force rounding (I lean towards forcing rounding whenever an intermediate result is visible to the program):

❌ *a = x * y; t := *a + z  (8)

(SSA rules could optimize example 8 because they will replace the load from a with a reuse of the result of x * y.)

I think the only real complexity in the implementation is how we plumb the casts from the compiler to the SSA backend so that optimization rules can be blocked as appropriate. I’m not sure if there is a pre-existing mechanism we can use.

See these links for previous discussion of this proposal on golang-dev:
https://groups.google.com/d/topic/golang-dev/qvOqcmAkKnA/discussion
https://groups.google.com/d/topic/golang-dev/cVnE1K08Aks/discussion

[rsc]

Note: The important part of this outcome is the precedent or more general rule it establishes for avoiding compiler optimization on float32/float64 arithmetic more generally.

[tombergan]

What is a "local variable", what is a "memory location", and what does it mean for an intermediate result to be "visible to the program"? These may seem like simple questions, but in practice the distinction is blurry and depends on choices made by the compiler. Examples:

var global float64
var globalPtr *float64

// z is changed after it escapes. Is rounding forced?
// Note that z is a "local variable", but also a "memory location", since it escapes.
func case1(x, y float64) {
  var z float64
  globalPtr = &z
  z = x + y
}

// z is changed before it escapes. Is rounding forced before or after Println?
func case2(x, y float64) {
  var z float64
  z = x + y
  fmt.Println(z)
  globalPtr = &z
}

// The first store into `global` may not be visible to other goroutines
// since there is no memory barrier between the two stores. The compiler
// may merge these stores into one. Is rounding forced on (x + y), or
// just (x + y + 2)?
func case3(x, y float64) {
  global = x + y
  global += 2
}

// A smart compiler might realize that z doesn't escape, even though its
// address is taken implicitly by the closure. Is rounding forced?
func case4(x, y float64) float64 {
  var z float64
  var wg sync.WaitGroup
  wg.Add(1)
  go func() {
    defer wg.Done()
    z = x + y
  }()
  wg.Wait()
  return z
}

I think I agree with rsc's suggestion from the second linked thread: "I would lean toward allowing FMA aggressively except for an explicit conversion."

[mundaym]

What is a "local variable", what is a "memory location", and what does it mean for an intermediate result to be "visible to the program"? These may seem like simple questions, but in practice the distinction is blurry and depends on choices made by the compiler.

Thanks. You're right of course, I was being imprecise. These properties aren't necessarily clear in code. They are somewhat clearer in the backend, but that might change as the compiler gets cleverer.

I think I agree with rsc's suggestion from the second linked thread: "I would lean toward allowing FMA aggressively except for an explicit conversion."

I think I also agree that would be a good rule but I'm starting to wonder if a strict interpretation of the spec already implies that assignment should force rounding. The spec defines float32 and float64 as:

float32     the set of all IEEE-754 32-bit floating-point numbers
float64     the set of all IEEE-754 64-bit floating-point numbers

Since the intermediate result of a fused multiply-add may not be a valid IEEE-754 32- or 64-bit floating-point number, this definition would seem to suggest that an assignment should prevent the optimization. However gri and rsc's comments on the thread would seem to imply that they don't agree (and they obviously know much better than me).

Assignments to variables currently block full precision constant propagation AFAICT, so forcing rounding at assignments would be in line with that behavior. Could the output of the following program change in future?

package main

import "fmt"

const x = 1.0000000000000001

func main() {
    x0 := x*10
    fmt.Println(x0) // prints 10.000000000000002
    x1 := x
    x1 *= 10
    fmt.Println(x1) // prints 10, but could be 10.000000000000002
}

(https://play.golang.org/p/6OMMzRq0pr)

[rsc]

It sounds like we agree that a float64 conversion should be an explicit signal that a rounded float64 should be materialized, so that for example float64(x*y)+z cannot use an FMA, but x*y+z and (x*y)+z can.

The question raised in @mundaym's latest comment is whether we're sure about case (7) above: if the code does t := x*y; t += z, should we allow t to never be materialized as a float64, so that for example FMA can be used in that case? The argument in favor of allowing optimization here is that generated code or code transformations might introduce temporaries, and we probably don't want that to have optimization effects. The argument against is that there's an explicit variable of type float64. On balance it seems that having a very explicit signal, as in the float64 conversion, would be best, so I would lean toward keeping case (7) allowed to use FMA.

We don't know too much about what other languages do here.

We know Fortran uses parentheses, although that only helps for FMA because * has higher precedence than + so the parens are optional. We'd rather not overload parens this way.

We don't think the C or C++ languages give easy control over this (possibly writing to a volatile and reading it back?).

What about Java? How do they provide access to FMA?

/cc @MichaelTJones for thoughts or wisdom about any of this.

[bradfitz]

Looks like Java is making it explicit with library additions: https://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg39320.html

Commit: http://cr.openjdk.java.net/~darcy/4851642.0/

[ianlancetaylor]

When using GCC the -ffloat-store option can be used with C/C++ to force rounding when a floating-point value is assigned to a variable.

[MichaelTJones]

My sense (anecdotal…but lots of anecdata) is that there are three user postures here and one that touches on the question at hand: Oblivious--Fused MulAdd Everywhere Normal case: aggressive QMAF (IBM America/ etc.) is good for most everything…faster with greater precision so pervasive with the greatest reach possible is fine. Cautious--No Fused MulAdd if I disable it (sorry, a new complier option) Users who want their results to be unchanged from another machine, examples in a book, data in a database, etc. This may be important to Go users or not. I don’t know. Explicit—An absolute way to force not doing the fused MuliplyAdd in a specific hand-coded careful expression. This is the user case I was speaking for previously. It is a small group, but it includes the people like Professor Kahan, and all the math library authors who need to track the difference between the two computation modes when evaluating basic functions. Both IBM and Intel/HP figured out how to get +/- 1 ULP evaluation of intrinsic functions (sin, cos, log, exp, …) using QMAF-style math but it needs to be possible to keep track of error between the one rounding and the two rounding cases. The proposal for a float64(x*y)+z to mean two ops, each rounded and prevent the fused x*y+z is just fine for this purpose. Everywhere else is just like the oblivious case. Michael From: Ian Lance Taylor <notifications@github.com> Reply-To: golang/go <reply@reply.github.com> Date: Monday, November 28, 2016 at 1:47 PM To: golang/go <go@noreply.github.com> Cc: Michael T Jones <michael.jones@gmail.com>, Mention <mention@noreply.github.com> Subject: Re: [golang/go] proposal: allow the use of fused multiply-add floating point instructions (#17895) When using GCC the -ffloat-store option can be used with C/C++ to force rounding when a floating-point value is assigned to a variable. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[griesemer]

@MichaelTJones There's also the opposite explicit form: Have a mechanism (intrinsified function call) to specify when to use FMA (and never, otherwise). Go already allows control over when not to use FMA (if available) by forcing an explicit conversion; e.g. float64(x*y) + z (no FMA) vs x*y + z (possibly FMA).

[rsc]

@mundaym, I think everyone agrees about cases 1, 2, 3, 4, 5, 6.

We are less sure about 7 and 8, which may be the same case for a sufficiently clever compiler.
The argument for "no" on 7 and 8 is that the assignment implies a fixed storage format.
The argument for "yes" on 7 is that otherwise a source-to-source lowering of a program would inhibit certain floating-point optimizations, and also more generally source-to-source translations will have to consider whether they are changing program semantics by combining or splitting expressions. Another argument for "yes" on 7 is that it results in just one way to disable the optimization, instead of two.

I propose that we tentatively assume "yes" on 7 and 8, with the understanding that we can back down from that if a strong real-world example arrives showing that we've made a mistake.

[mundaym]

I propose that we tentatively assume "yes" on 7 and 8, with the understanding that we can back down from that if a strong real-world example arrives showing that we've made a mistake.

Thanks, that sounds good to me. I'll prototype it for ppc64{,le} and s390x.

[ianlancetaylor]

@rsc Can you clarify what "yes" and "no" mean in your comment?

[rsc]

"Yes" means check-mark above (FMA optimization allowed here), and "no" means X above (FMA optimization not allowed here).