On Wed, Sep 12, 2018 at 10:54 AM, jimmy frasche <soapboxcic...@gmail.com> wrote:
>
> Given a platform that supports the fused multiply add (FMA)
> instruction and the code:
>
> contract MA(t T) {
> t * t + t
> }
>
> func ma(type T MA)(a, b, c T) T {
> return a*b + c
> }
>
> Does the compiled-for-any-type version support the FMA optimization
> when called with a floating-point type?
I think that in practice it's going to be up to the compiler. The
language spec permits but does not require using an FMA instruction
for the expression `x*y + z`. Whether that specific expression
appears in a contract is going to be irrelevant. If it appears in the
body of the generic function, the compiler may or may not recognize
it.
> If I specifically want to not use the optimization when instantiated
> with floats, can I do:
>
> func maNoFMA(type T MA)(a, b, c T) T {
> return T(a*b) + c
> }
Yes, adding an explicit type conversion always disables the use of
FMA, as explained in the language spec. Again, that is independent of
whether the expression appears in the contract.
> If I need it to use the guaranteed FMA intrinsic (see
> https://github.com/golang/go/issues/25819 ) when instantiated with
> floats, I can't do
>
> func maMustFMA(type T MA)(a, b, c T) T {
> switch a.(type) {
> case float32:
> return T(math.Fma(
> float64(a.(float32)),
> float64(b.(float32)),
> float64(c.(float32)),
> ))
> case float64:
> return T(math.Fma(a.(float64), b.(float64), c.(float64)))
> }
> return a*b + c
> }
>
> because that misses cases like
> type Float float64
> so I have to use reflect which can't be dead-code eliminated during
> specialization.
You could perhaps choose an implementation based on unsafe.Sizeof.
But I agree that it's pretty ugly.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
