This is an archive of the discontinued LLVM Phabricator instance.

[LangRef] clarify the meaning of noimplicitfloat
ClosedPublic

Authored by inglorion on Jun 10 2021, 2:21 PM.

Details

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.

Diff Detail

Event Timeline

inglorion created this revision.Jun 10 2021, 2:21 PM
inglorion requested review of this revision.Jun 10 2021, 2:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 10 2021, 2:21 PM
rnk accepted this revision.Jun 10 2021, 2:50 PM
rnk added reviewers: pengfei, avl, RKSimon, craig.topper.

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.

This revision is now accepted and ready to land.Jun 10 2021, 2:51 PM

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

rnk added a comment.Jun 10 2021, 4:01 PM

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

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

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 updated this revision to Diff 351593.Jun 11 2021, 5:01 PM

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

avl added inline comments.Jun 12 2021, 12:19 AM
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.

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 accepted this revision.Jun 24 2021, 9:44 AM

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.

This revision was automatically updated to reflect the committed changes.

Thanks, everyone!