This is an archive of the discontinued LLVM Phabricator instance.

Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations
ClosedPublic

Authored by mibintc on Apr 24 2020, 12:49 PM.

Details

Summary

The folks at Intel who program FPGA would like to be able to control the FastMathFlag that governs reassociating operations at the source level using pragma's e.g.
#pragma clang fp reassoc(on) // allow reassociation of operations across multiple statements

This patch builds on reviews.llvm.org/D72841

Diff Detail

Event Timeline

mibintc created this revision.Apr 24 2020, 12:49 PM
Herald added a project: Restricted Project. ยท View Herald TranscriptApr 24 2020, 12:49 PM
mibintc marked an inline comment as done.Apr 24 2020, 12:53 PM

added an inline comment

clang/include/clang/AST/Stmt.h
618 โ†—(On Diff #259968)

This correction belongs in the parent revision, i will move it there.

mibintc updated this revision to Diff 260381.Apr 27 2020, 10:57 AM
mibintc retitled this revision from Add support for #pragma clang fp reassoc(on|off) -- floating point control of associative math transformations to Add support for #pragma clang fp allow_reassociation(on|off) -- floating point control of associative math transformations.
mibintc added a reviewer: erichkeane.

Add user documentation, rename the pragma to be more user-friendly #pragma clang fp allow_reassociation

mibintc edited the summary of this revision. (Show Details)Apr 27 2020, 10:58 AM
erichkeane added inline comments.Apr 27 2020, 12:17 PM
clang/include/clang/Basic/DiagnosticParseKinds.td
1336

I think we'd want this combined with the one below. You can use a %select to enable/disable 'fast'. Something like:

"unexpected argument '%0' to '#pragma clang fp %select{contract|OTHERS}1; expected 'on'%select{, 'fast'|}1 or off"

sepavloff added inline comments.Apr 28 2020, 10:28 PM
clang/docs/LanguageExtensions.rst
3178

I would say the previous name, reassoc, was more consistent. We do not use allow_contraction.

clang/include/clang/Basic/DiagnosticParseKinds.td
1336

There was discussion on the same topic in D65997. Probably code from there could be used here. The point is that this pragma is likely to get additional parameters in future and it would be nice if this implementation would be prepared to such extensions.

clang/include/clang/Sema/Sema.h
9622

Duplication of function name in doc comments is outdated technique. Maybe it can be omitted? It would enhance readability a bit.

clang/test/CodeGen/fp-reassoc-pragma-fails.cpp
1 โ†—(On Diff #260381)

This test has nothing with code generation. It should be moved to Parser directory. There is already a file pragma-fp.cpp there, it could be amended with your tests.

mibintc updated this revision to Diff 261036.Apr 29 2020, 2:19 PM

Thanks for your review @sepavloff and @erichkeane, I have responded to your feedback and reverted the name back to reassoc which is what Serge prefers

mibintc retitled this revision from Add support for #pragma clang fp allow_reassociation(on|off) -- floating point control of associative math transformations to Add support for #pragma clang fp reassoc(on|off) -- floating point control of associative math transformations.Apr 29 2020, 2:19 PM
mibintc edited the summary of this revision. (Show Details)
rjmccall added inline comments.May 1 2020, 9:44 AM
clang/docs/LanguageExtensions.rst
3177

Let's go ahead and word this as if arbitrary things will be controllable in the future. So:

Currently, the following things can be controlled by this pragma:

3178

"contract" isn't a shortening, though, it's a verb. The idea is that a pragma is a directive to the compiler. So arguably the more consistent spelling would be something like #pragma clang fp reassociate.

3203

Please fix this typo while you're here.

clang/include/clang/Basic/LangOptions.h
186

I'm not sure I think this fusion was an improvement; the net effect was to remove a few lines from this header and make a bunch of switches unnecessarily non-exhaustive.

mibintc updated this revision to Diff 261875.May 4 2020, 10:58 AM
mibintc retitled this revision from Add support for #pragma clang fp reassoc(on|off) -- floating point control of associative math transformations to Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations.

Responded to @rjmccall 's review.

mibintc marked 4 inline comments as done.May 4 2020, 11:00 AM
mibintc added inline comments.
clang/include/clang/Basic/LangOptions.h
186

I dropped the on/off enumeration and just using boolean, where needed, to show the setting, do you like this better?

scanon added a subscriber: scanon.May 4 2020, 11:30 AM
scanon added inline comments.
clang/docs/LanguageExtensions.rst
3182

Is the intention that this allows reassociation only within statements (like fp contract on)? Based on the ir in the tests, I think the answer is "no".

If so, should "on" be called "fast" instead, since its semantics match the "fast" semantics for contract, and reserve "on" for reassociation within a statement (that seems like it would also be useful, potentially)?

Otherwise, please add some tests with multiple statements.

I agree with John that pragma clang fp reassociate is a reasonable spelling.

Just minor requests now.

clang/docs/LanguageExtensions.rst
3177

Thanks. Please put the first sentence in its own paragraph and end it with a colon so that it logically leads into both of the following blocks.

3182

Do you want to add an example here?

3205

Oh, and there's a missing period here.

clang/include/clang/Basic/LangOptions.h
186

Yeah, thanks.

clang/include/clang/Sema/Sema.h
9624

Please name this the same as the language feature.

clang/lib/Parse/ParsePragma.cpp
2894

Please make this a single block by making the condition something like if (!FlagValue || (FlagKind == TokFPAnnotValue::Reassociate && FlagValue == TokFPAnnotValue::Fast)).

mibintc marked an inline comment as done.May 4 2020, 12:02 PM

A reply to @scanon

clang/docs/LanguageExtensions.rst
3182

The intention is that the pragma can be placed at either file scope or at the start of a compound statement, if at file scope it affects the functions following the pragma. If at compound statement it is effective for the compound statement, i can modify the test to have multiple statements. I disagree with the suggestion of "fast" instead of on/off. at the command line you can use -f[no-]associative-math; of course that command line option isn't specific to floating point, but the point is it's on/off ; i can't speak to whether "fast" would be a useful setting. Thanks for your review

ychen added a subscriber: ychen.May 4 2020, 12:05 PM
scanon added inline comments.May 4 2020, 12:43 PM
clang/docs/LanguageExtensions.rst
3182

I don't think you understood my comment, so I'll try to explain more clearly: I am not asking if it applies to multiple statements or a single statement; I am asking within what scope reassociation is allowed.

An example: fp contract on allows:

double r = a*b + c;

to be contracted to an fma, but does not allow:

double t = a*b;
double r = t + c;

to be contracted. fp contract fast allows both to be contracted.

Your reassociate pragma, if I am understanding correctly, allows:

double t = a + b;
double r = t + c;

to be reassociated; this matches the behavior of fp contract fast. I am asking if, for the sake of understandability and orthogonality of the floating-point model, it would make more sense for this option to be named fast, reserving on for a mode that only allows reassociation within expressions.

kpn added a subscriber: kpn.May 4 2020, 12:45 PM
mibintc updated this revision to Diff 261921.May 4 2020, 1:44 PM

I fixed the issues that @rjmccall mentioned. I don't yet have an answer for @scanon, need to get back to you about that.

mibintc updated this revision to Diff 262108.May 5 2020, 7:42 AM
mibintc retitled this revision from Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations to Add support for #pragma clang fp reassociate(fast|off) -- floating point control of associative math transformations.
mibintc edited the summary of this revision. (Show Details)

I checked with FPGA folks and confirm what @scanon says is correct, the reassoc fast math flag enables reassociation across multiple statements, so i changed the syntax to use 'fast' and 'off', and changed the documentation

The reason we call FP contraction "fast" instead of "on" when it's cross-statement is because "on" is supposed to be consistent with the C language rules, whereas "fast" is stronger. There's no analogous situation with reassociation; I don't think the C standard is likely to ever bless reassociative FP math with an expression-local restriction. Steve, do you actually think that would be a useful optimization mode?

I don't think the C standard is likely to ever bless reassociative FP math with an expression-local restriction. Steve, do you actually think that would be a useful optimization mode?

I think it's pretty unlikely that C would do this, as well. It is plausibly a useful semantic mode, but I don't know that we need to reserve the name for it. I only want to raise the question, and be sure that we're aware that we're making a decision here (also, either way we need to document it clearly).

That makes sense, thanks. I think I'm comfortable using on/off for this, but it's definitely good to stop and consider, and you're absolutely right that it needs to be documented.

mibintc updated this revision to Diff 262217.May 5 2020, 1:47 PM
mibintc retitled this revision from Add support for #pragma clang fp reassociate(fast|off) -- floating point control of associative math transformations to Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations.
mibintc edited the summary of this revision. (Show Details)

Here it is again with the on/off spelling

scanon accepted this revision.May 5 2020, 6:14 PM

My concerns have been addressed. Thanks for bearing with me, Melanie!

This revision is now accepted and ready to land.May 5 2020, 6:14 PM
scanon added a comment.May 5 2020, 6:15 PM

(Please get one additional sign off before committing; I'm mainly signing off on the numerics model aspect).

rjmccall accepted this revision.May 5 2020, 10:28 PM

LGTM, too. Thanks!

This revision was automatically updated to reflect the committed changes.

BTW there is a proposal http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2421.pdf at the ISO C meeting to support some new floating point pragmas including
#pragma STDC FENV_ALLOW_ASSOCIATIVE_LAW on-off-switch
The committee wants to see an implementation(s) to ensure that it's viable.

That's actually really interesting. Is there a paper describing the desired model in more detail?

I think the natural interpretation of this pragma is to say that the specific operations written within the pragma are considered to be associative and are therefore allowed to be re-associated with other associative operators. However, that might not be the committee's formal interpretation, given how contraction works.

The ISO C proposal is here http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2407.pdf but the details are in the IEEE standards documents.

scanon added a comment.May 6 2020, 1:48 PM

TS18661-5 is quite vague on what the intended semantics for the pragma are.

These pragmas are intended to be bindings of clause 10.4 of IEEE 754, which is also pretty wishy-washy on the whole, but it's worth noting that clause 10 is titled *expression evaluation* specifically. The relevant text here is:

A language standard should also define, and require implementations to provide, attributes that allow and disallow value-changing optimizations, separately or collectively, for a block. These optimizations might include, but are not limited to:
โ€• Applying the associative or distributive laws.
โ€• Synthesis of a fusedMultiplyAdd operation from a multiplication and an addition.
โ€• Synthesis of a formatOf operation from an operation and a conversion of the result of the 40 operation.
โ€• Use of wider intermediate results in expression evaluation.

So IEEE-754 appears to view this as being "just like" contraction. (Note that this is all under a "should", so #yolo).