Fused multiply-add?

[mun...@ca.ibm.com]

Hi all,

I've been experimenting with SSA rules for fused multiply-add operations on s390x and I'm wondering what people's opinions on fused multiply-adds are. I found some discussion here: https://groups.google.com/d/topic/golang-dev/qvOqcmAkKnA/discussion and the consensus seems to be that fused multiply-add extraction should be allowed provided it is blocked by an explicit cast or assignment (for example, fused multiply-adds could be used for x*y±z, but not for float64(x*y)±z or t:=x*y;t+=z). I think we'd need to add a way for the SSA backend to explicitly block the optimization in these cases (I haven't done this yet).

Up until now I hadn't really considered using them because of the changes they might make to program output, but I'm wondering if the benefits (improved accuracy, faster operation) outweigh such costs.

My prototype passes ./all.bash and I haven't found any evidence yet that the tests would need to be modified to accommodate this optimization.

Any thoughts? I'd be happy to attempt to formalize the rules in a proposal for 1.9. I think the only architectures with fused multiply-add instructions in the base-level instruction sets are arm64, ppc64 and s390x.

Thanks,
Michael

[cherry]

I assume you mean floating point operations.

I think we already generate multiply-add for integers on some architectures.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[mun...@ca.ibm.com]

Ah yes, good point, I'm just talking about floating point fused multiply-adds here.

[Russ Cox]

You found the right past discussion. By all means please write up a proposal for Go 1.9. I would lean toward allowing FMA aggressively except for an explicit conversion. That is:

x*y+z // can FMA (obviously)
(x*y)+z // can FMA (parens can't be overloaded with new semantics)

t := x*y; t += z; // can FMA (unless someone has a compelling argument against)
float64(x*y) + z // cannot FMA (float64 conversion overrides)

t := float64(x*y); t += z // cannot FMA (float64 conversion overrides)

Thanks.

Russ

On Fri, Nov 11, 2016 at 11:46 AM, <mun...@ca.ibm.com> wrote:

--

You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[mun...@ca.ibm.com]

Thanks, I'll write something up.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[smans...@netflix.com]

Would you be able to ignore the conversion to float64 if the two values are already float64? Or is it that you're going to be carrying too much precision through the operation and therefore possibly changing the results?

[Russ Cox]

On Fri, Nov 11, 2016 at 2:05 PM, smansfield via golang-dev <golan...@googlegroups.com> wrote:

Would you be able to ignore the conversion to float64 if the two values are already float64? Or is it that you're going to be carrying too much precision through the operation and therefore possibly changing the results?

Conversion to float64 would mean "make a float64 of this value" which disallows the higher precision implied computation in an FMA. This is analogous to what happens today with const expressions, or with explicit conversion from float64 to float32 and back. 

https://play.golang.org/p/2iyTg_87Vq

Russ