This is an archive of the discontinued LLVM Phabricator instance.

FastMathFlags.allowContract should be init from FPFeatures.allowFPContractAcrossStatement
ClosedPublic

Authored by mibintc on May 13 2020, 12:38 PM.

Details

Summary

Previously, the IRBuilder.FMF.allowContract was initialized to true if either (ffp-contract=fast or ffp-contract=on) ; with this patch that bit will only be set if ffp-contract=fast. This problem was pointed out by michele.scandale in a reply to https://reviews.llvm.org/D72841

Diff Detail

Event Timeline

mibintc created this revision.May 13 2020, 12:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 13 2020, 12:38 PM
mibintc marked 3 inline comments as done.May 13 2020, 12:46 PM

added some inline explanation

clang/lib/Frontend/CompilerInvocation.cpp
2948

I changed this because the FAST version of this test clang/test/CodeGenOpenCL/relaxed-fpmath.cl wants the 'fast' attribute on the instruction dump. All the LLVM FMF bits must be set for the fast attribute print. By default, the value for OpenCL is ffp-contract=on

clang/lib/Sema/SemaAttr.cpp
460 ↗(On Diff #263826)

When i was adding a test, I realized that pragma float_control(push) then pop wasn't working as expected. If the stack is empty, which is most of the time, first need to push the current fp features onto the stack so they can be restored at the pop

clang/test/CodeGen/constrained-math-builtins.c
157

most of the test changes here are just a revert of the test changes from the original patch for float_control

rjmccall added inline comments.May 13 2020, 1:47 PM
clang/lib/Frontend/CompilerInvocation.cpp
2948

Is there an overall behavior change for OpenCL across these patches?

clang/lib/Sema/SemaAttr.cpp
460 ↗(On Diff #263826)

It seems that the way PragmaStack is supposed to be used is that we're supposed to be using its CurrentValue instead of having a separate CurFPFeatures. But mostly it looks like there's a lot of functionality associated with PragmaStack that we aren't using at all because this is a substantially simpler mode; we could really just be using a SmallVector<FPOptions, 2>.

Anyway, I guess this fix works, although it should be done in a separate patch.

mibintc marked an inline comment as done.May 13 2020, 2:27 PM
mibintc added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
2948

I think the answer to your question is no. Here is more details: OpenCL sets the default behavior to ffp-contract=on. In https://reviews.llvm.org/D72841 I added the function UpdateFastMathFlags, that function set the llvm FMF.allowContract bit to be ( ffp-contract=on or ffp-contract=fast). This patch just drops the check on ffp-contract=on. I didn't wind back to see how the llvm fast attribute was being set for this [opencl] test case originally.

rjmccall added inline comments.May 13 2020, 3:14 PM
clang/lib/Frontend/CompilerInvocation.cpp
2948

Well, to what extent are there (including this patch) overall test changes for the OpenCL tests, and what are tthey?

mibintc marked 2 inline comments as done.May 14 2020, 7:08 AM
mibintc added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
2948

In the #pragma float_control patch https://reviews.llvm.org/D72841, I changed 2 CodeGen/OpenCL tests: relaxed-fp-math.cl in the non-FAST cases to show the contract bit. Also 1 line in single-precision-constant.cl for the same reason, to show the contract bit. This patch undoes those test changes. I'll do more investigation to understand why the fast bit isn't being set in the FAST case in relaxed-fpmath.cl without the change to CompilerInovcaton

clang/lib/Sema/SemaAttr.cpp
460 ↗(On Diff #263826)

I'll submit it in a separate patch.

mibintc marked an inline comment as done.May 14 2020, 10:55 AM

reply about the incorrect setting of 'fast' during OpenCL compilation with option -cl-fast-relaxed-math

clang/lib/Frontend/CompilerInvocation.cpp
2948

Prior to the patch for #pragma float_control, the llvm.FastMathFlags was initialized from LangArgs.FastMath in the CodeGenFunction constructor approximately line 74, and the FMF values in IRBuilder were never changed--For the test clang/test/CodeGenOpenCL/relaxed-fpmath.cl with option -cl-fast-relaxed-math. (In ParseLangArgs, Opts.FastMath = Args.hasArg(OPT_ffast_math) || Args.hasArg(OPT_cl_fast_relaxed_math)) If FastMath is on, then all the llvm.FMF flags are set.

The #pragma float_control patch does change the IRBuilder settings in the course of visiting the Expr nodes, using the information in the Expr nodes, but the initial setting of FPFeatures from the command line overlooked the fact that FastMath, and therefore ffp-contract=fast, is enabled.

michele.scandale added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
2948

Prior to D72841 compiling something with -ffast-math -ffp-contract={on,off} was still producing fast as fast-math flags on the instructions for the same reason.
The clang driver does not consider the contraction mode for passing -ffast-math to CC1, which is consistent with the GCC behavior (I checked if the __FAST_MATH__ is defined if I compile with -ffast-math -ffp-contract=off).
According to this, the code in CodeGenFunction:

if (LangOpts.FastMath)
  FMF.setFast();

is not correct.

The OpenCL option -cl-fast-relaxed-math should be equivalent to -ffast-math for the user. I don't know what the interaction between -cl-fast-relaxed-math and -ffp-contract={on, off,fast}.

If we need to keep -cl-fast-relaxed-math a CC1 option, I guess the following might work:

if (Args.hasArg(OPTS_cl_fast_relaxed_math) && !Arg.hasArg(OPT_ffp_contractEQ))
  Opts.setDefaultFPContractMode)LangOptions::FPM_Fast);
rjmccall added inline comments.May 14 2020, 4:52 PM
clang/lib/Frontend/CompilerInvocation.cpp
2948

Okay, thanks for the investigation, I agree that that all makes sense. I'm not sure what it would mean to enable fast math but disable contraction — that combination doesn't seem useful.

I'm fine with going forward with the OpenCL changes as they are, but you might want to specifically reach out to the OpenCL people and let them know what's going on.

mibintc updated this revision to Diff 264241.May 15 2020, 7:40 AM
mibintc marked an inline comment as done.

This is the same as the previous patch, except I removed the fix for pragma push-pop that John said should be committed separately

mibintc added a subscriber: arsenm.May 15 2020, 7:47 AM
mibintc added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
2948

@arsenm Matt, I'm making this change to CompilerInvocation to fix a bug that was introduced by https://reviews.llvm.org/D72841 I see that you contribute to OpenCL will you please let interested folks know about this change?
D72841 erroneously set the llvm.FMF.contract bit to true whether the contraction status was "allow contraction across statements" or "allow contraction within statements". This patch corrects that error to set llvm.FMF.contract bit only when contraction status is "allow contraction across statements". D72841 mis-captured the initial contraction status, this patch corrects that by checking the specific OpenCL option OPTS_cl_fast_relaxed_math.
D72841 made a couple changes to OpenCL tests about the 'contract' flag in the IR, this patch undoes those test changes.

mibintc marked an inline comment as done.May 15 2020, 7:50 AM
mibintc added a subscriber: Anastasia.
mibintc added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
2948

@Anastasia Adding Anastasia about this issue

Anastasia added inline comments.May 18 2020, 1:30 PM
clang/lib/Frontend/CompilerInvocation.cpp
2948

This change seems reasonable as it indeed restores the correct OpenCL behavior. Thanks for looking into this!

I think we might also be able to set contract on -cl-mad-enable, but this can be done as a separate follow up improvement patch if we decide this is the right route forward.

This looks good to me. @rjmccall do you have any more feedback?

rjmccall accepted this revision.May 19 2020, 8:56 PM

No, go ahead.

This revision is now accepted and ready to land.May 19 2020, 8:56 PM
This revision was automatically updated to reflect the committed changes.