This is an archive of the discontinued LLVM Phabricator instance.

Set FMF for -ffp-contract=fast
ClosedPublic

Authored by anemet on Mar 20 2017, 8:12 PM.

Details

Summary

With this, FMF(contract) becomes an alternative way to express the request to
contract.

This is handled similarly to ApplyDebugLocation using an RAII to propagate
FPOptions from the BinaryOperator to the IRBuilder. Note that
CompoundAssignOperator (+=) can be an lvalue so it needs to be handled as such
as well.

This is toward fixing PR25721.

Diff Detail

Repository
rL LLVM

Event Timeline

anemet created this revision.Mar 20 2017, 8:12 PM

I think you can add a test case in this patch (after the llvm changes are checked in)?

lib/CodeGen/CGExprScalar.cpp
262 ↗(On Diff #92424)

Is it necessary to check CXXOperatorCallExpr too here?

Since CXXOperatorCallExpr has an FPFeatures field too, I was wondering how CodeGen was going to use that information.

Thanks, Akira. You're right on both accounts. I actually had a test written but failed to git add it.

anemet updated this revision to Diff 92564.Mar 21 2017, 4:03 PM

Address Akira's comments

anemet retitled this revision from Set FMF for -ffp-contract=fast rather than a TargetConfig to Set FMF for -ffp-contract=fast.Mar 21 2017, 4:04 PM
anemet edited the summary of this revision. (Show Details)
anemet marked an inline comment as done.
anemet updated this revision to Diff 93487.Mar 30 2017, 9:03 AM

Also add 'contract' for CompoundAssignOperator (+= and -=). For l-values,
these don't go through the expr-visitor in ScalarExprEmitter::Visit. This
again piggybacks on how debug-locations are added.

anemet edited the summary of this revision. (Show Details)Mar 30 2017, 9:04 AM
anemet added a comment.Apr 1 2017, 7:26 PM

Ping. This is the only patch in the series now that wasn't approved.

I may have missed earlier steps in this patch series. Why is this being done statefully and contextually in the IRBuilder instead of just applying the flag from the BinaryOperator to the instruction when building it? It's not like ScalarExprEmitter doesn't know that it's building an FMul.

I may have missed earlier steps in this patch series. Why is this being done statefully and contextually in the IRBuilder instead of just applying the flag from the BinaryOperator to the instruction when building it? It's not like ScalarExprEmitter doesn't know that it's building an FMul.

The main reason is that the other FMFlags are currently maintained in the IRBuilder (see CodeGenFunction.cpp:87). That said as we move those over to the operators as well, it makes more sense to move away from using the IRBuilder for this. See updated patch and thanks for the suggestion!

Also let me know if you have post-commit comments on the patches in the series. You can find them either on the cfe-dev thread or in the dependencies of D31276

anemet updated this revision to Diff 93882.Apr 3 2017, 10:28 AM

Address John's comment.

aaron.ballman edited edge metadata.Apr 4 2017, 6:52 AM

LGTM. but you should wait for someone more familiar with this part of codegen before committing.

anemet added a comment.Apr 4 2017, 8:05 AM

Thanks, Aaron! @rjmccall, does it look good to you too?

rjmccall accepted this revision.Apr 4 2017, 9:32 AM

Yes, thank you, that's great.

This revision is now accepted and ready to land.Apr 4 2017, 9:32 AM
This revision was automatically updated to reflect the committed changes.