[LangRef] Clarify absence of rounding guarantees for fmuladd.

[fhahn]

Summary

During the review of D67434, it was recommended to make fmuladd's
behavior more explicit. D67434 depends on this interpretation.

[lebedev.ri]

Sounds good to me

[reames]

llvm/docs/LangRef.rst

13954 ↗

(On Diff #220099)

Please change:
"is equivalent to the expression a \* b + c, except that rounding will
not be performed between the multiplication and addition steps if the
code generator fuses the operations. "

To:
"is equivalent to the expression a \* b + c, except that it is unspecified whether rounding will be performed between the multiplication and addition steps. "

13956 ↗

(On Diff #220099)

Your added sentence does not parse for me.

[fhahn]

llvm/docs/LangRef.rst

13954 ↗

(On Diff #220099)

Sounds good, thanks! Do you think that clarification is enough, without the additional sentence?

13956 ↗

(On Diff #220099)

Do you mean when reading the sentence or with sphinx?

[reames]

llvm/docs/LangRef.rst

13954 ↗

(On Diff #220099)

Yes. LGTM.

13956 ↗

(On Diff #220099)

When reading.

[fhahn]

Updated with @reames' suggestion, thanks!

[fhahn]

llvm/docs/LangRef.rst

13954 ↗

(On Diff #220099)

Done, thanks!

[lebedev.ri]

Sounds good to me.

[fhahn]

@reames I think this should be good to go in now?

[spatel]

llvm/docs/LangRef.rst

13956 ↗

(On Diff #220216)

Worth adding a sentence to explain *why* we have this intrinsic at all? Something like:
"The optional fusion gives flexibility to the IR optimizer and code generator to select the best-performing target code sequence."

[spatel]

LGTM (though I think we're waiting for @reames).

llvm/docs/LangRef.rst

13956 ↗

(On Diff #220216)

On 2nd thought, strike that suggestion - it's redundant with the text in the 'Overview' above this.

[fhahn]

In D67552#1680844, @spatel wrote:

LGTM (though I think we're waiting for @reames).

Thanks!. From the previous comments my understanding is that the re-phrasing looks good to him, but I'll wait for a few more days, in case there are additional concerns.

[reames]

In D67552#1681287, @fhahn wrote:

In D67552#1680844, @spatel wrote:

LGTM (though I think we're waiting for @reames).

Thanks!. From the previous comments my understanding is that the re-phrasing looks good to him, but I'll wait for a few more days, in case there are additional concerns.

No need to wait.

In general, unless I ask explicitly to wait or indicate a desire to see a future version, you don't need to wait for me to circle back if someone else gave an LGTM.

llvm/trunk/docs/LangRef.rst

 """"""""""
 
 The expression:
 
 ::
 
       %0 = call float @llvm.fmuladd.f32(%a, %b, %c)
 
-is equivalent to the expression a \* b + c, except that rounding will
-not be performed between the multiplication and addition steps if the
-code generator fuses the operations. Fusion is not guaranteed, even if
-the target platform supports it. If a fused multiply-add is required, the
-corresponding :ref:`llvm.fma <int_fma>` intrinsic function should be used
-instead. This never sets errno, just as '``llvm.fma.*``'.
+is equivalent to the expression a \* b + c, except that it is unspecified
+whether rounding will be performed between the multiplication and addition
+steps. Fusion is not guaranteed, even if the target platform supports it.
+If a fused multiply-add is required, the corresponding
+:ref:`llvm.fma <int_fma>` intrinsic function should be used instead.
+This never sets errno, just as '``llvm.fma.*``'.
 
 Examples:
 """""""""
 
 .. code-block:: llvm
 
       %r2 = call float @llvm.fmuladd.f32(float %a, float %b, float %c) ; yields float:r2 = (a * b) + c