[LangRef] clarify the meaning of noimplicitfloat

[inglorion]

Summary

Adds some more text to the documentation for the noimplicitfloat
function attribute. Hopefully, this makes it clearer what
qualifies an implicit vs. explicit float, without becoming overly
long or going into target-specific details.

[rnk]

This matches my understanding of the semantics of noimplicitfloat, but I'd like to get a stamp from one of the other people I added to check my understanding.

[craig.topper]

This matches my understanding too. At least on X86, I think "floating-point" also includes integer SSE. Should we mention that?

[rnk]

That's a good point, if this attribute disables vectorization of integer math, the docs should say as much.

[craig.topper]

In D104061#2811804, @rnk wrote:

That's a good point, if this attribute disables vectorization of integer math, the docs should say as much.

The examples I know of are using vector ctpop instructions when

In D104061#2811804, @rnk wrote:

That's a good point, if this attribute disables vectorization of integer math, the docs should say as much.

Note, I don't know specifically about the vectorizer. I was referring to backend tricks like this https://godbolt.org/z/KaE9T8P1q where we use the vector unit to expand i64 popcnt on 32-bit target.

[inglorion]

Also specified that this inhibits the use of SIMD/vector registers
(which is true at least of x86_64 and armv8).

[avl]

llvm/docs/LangRef.rst

1641

Probably, it makes sense to explicitly describe which cases are "explicit/implicit"? something like this:

LLVM instructions that perform floating-point operations or require access to floating-point
registers may still cause floating-point code to be generated for the explicit floating-point cases:

1. LLVM instructions that are generated for the expressions from the source code where value has floating-point or vector type.
2. LLVM instructions that are generated to satisfy the platform`s ABI requirements.

[inglorion]

I avoided enumerating the cases to save space and to avoid pinning this down too much. My intention was to clarify that noimplicitfloat does not mean that no floating-point code will be generated under any circumstances, not necessarily to clarify exactly in which situations such code will or will not be generated. I'm happy to add the extra text, but before I do, I would like to get a second vote in favor of doing so vs. using the shorter text that I had written. @rnk, @craig.topper: What are your opinions?

[rnk]

lgtm

I think the current text is correct and clear, and we can elaborate later if others think more precision is needed.

llvm/docs/LangRef.rst

1641

I think the existing text is clear enough and more concise. Mainly, the proposed text adds a note about generating FP code to satisfy platform ABI requirements. I think the text "LLVM instructions ... that require access to FP registers" captures that well enough.

[craig.topper]

lgtm

[inglorion]

Thanks, everyone!

llvm/docs/LangRef.rst

``nofree``
     ``nosync`` would ensure such communication cannot happen and even captured
     pointers cannot be freed by the function.
 
     A ``nofree`` function is explicitly allowed to free memory which it
     allocated or (if not ``nosync``) arrange for another thread to free
     memory on it's behalf.  As a result, perhaps surprisingly, a ``nofree``
     function can return a pointer to a previously deallocated memory object.
 ``noimplicitfloat``
-    This attributes disables implicit floating-point instructions.
+    Disallows implicit floating-point code. This inhibits optimizations
+    that use floating-point code for operations that are not nominally
+    floating-point. LLVM instructions that perform floating-point
+    operations or require access to floating-point registers may still
+    cause floating-point code to be generated.
 ``noinline``
     This attribute indicates that the inliner should never inline this
     function in any situation. This attribute may not be used together
     with the ``alwaysinline`` attribute.
 ``nomerge``
     This attribute indicates that calls to this function should never be merged
     during optimization. For example, it will prevent tail merging otherwise
     identical code sequences that raise an exception or terminate the program.