This is an archive of the discontinued LLVM Phabricator instance.

Fix for lost FastMathFlags in 4 optimizations.
AbandonedPublic

Authored by v_klochkov on Nov 8 2016, 5:47 PM.

Details

Reviewers
dberlin
Summary

Hello,

Please review the trivial fixes in 4 different optimizations
that occasionally/wrongly lost FastMathFlags in FP operations.

I have more fixes for many cases in InstCombiner module,
but those are a bit more difficult and should be submitted for code-review separately.

Also, I added the developers, whose lines I changed, to the Subscribers list. (I used svn blame to get that list).

Thanks you,
Vyacheslav Klochkov

lib/Transforms/Scalar/GVN.cpp

Before GVN:  
  t1 = <fast> a+b
  store t1 to [mem1]
  ...
  t2 = load [mem1]
  use t2
After GVN:
  t1 = a+b // this operation must remain the <fast> flags!
  store t1 to [mem1]
  ...
  use t1 instead of original use of t2 (where t2=load from [mem1]).

The uses of t2 were replaced by uses of t1.
Unfortunately, both t1 and t2 can be cast to <FPMathOperator> 
(the load could be cast as well because the resulf of load was FP),
but here it is clear that math-flags of t1 and t2 should NOT be AND-ed.

lib/Transforms/Scalar/Reassociate.cpp

Before:
  ((a*b)*c)*d // all MUL operations have <fast> math flags.
After:
  (a*b)*(c*d) // all MUL operations lost <fast> math flags.

lib/Transforms/Vectorize/SLPVectorizer.cpp

FastMath flags were not propagated to a newly created FCmp operation.

lib/CodeGen/CodeGenPrepare.cpp

FastMath flags were not propagated to a newly created FCmp operation.

Diff Detail

Event Timeline

v_klochkov updated this revision to Diff 77294.Nov 8 2016, 5:47 PM
v_klochkov retitled this revision from to Fix for lost FastMathFlags in 4 optimizations..
v_klochkov updated this object.

Hi,

The SLP changes look good to me, but can we also add a test for it?

Thanks,
Michael

davide added a subscriber: davide.Nov 9 2016, 3:47 PM

You can probably split these in independent patches to facilitate review. Also each of this cases needs a test.

v_klochkov planned changes to this revision.Nov 10 2016, 9:54 AM

Ok, thank you for the response.
Initially I did not know how to test those test cases, but now I have some ideas.
Hopefully -run-pass switch will help me to test only 1 pass and check that FastMathFlags are not get lost in the affected opt passes.

For SLP you can take a look at Transforms/SLPVectorizer/X86/propagate_ir_flags.ll. I think in your case the test would be very similar.

Michael

majnemer added inline comments.Nov 10 2016, 10:27 AM
llvm/lib/Transforms/Scalar/Reassociate.cpp
1783–1785

This would be more obvious if you did: Builder.setFastMathFlags(cast<FPMathOperator>(I)->getFastMathFlags())

llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
2425

auto *CI

2431–2432

Please consistently brace.

Thank you for the code review and comments.
I decided to use Davide's advice and split this patch into 4 smaller and independent patches.

The first part (SLPVectorizer) was submitted here: https://reviews.llvm.org/D26543
The new SLPVectorizer patch is a bit different as the original patch was
not quite correct because it did not AND IR Flags for scalar FCmp operations.

Thank you,
v_klochkov

v_klochkov abandoned this revision.Mar 9 2018, 3:51 PM

3 opts out of 4 optimizations mentioned here (i.e. Reassociate, SLP, GVN) have been fixed by me in separate smaller patches.

Only 1 optimization (CodeGenPrepare) have NOT been fixed yet. Sorry, I do not have time and tools for doing that now. Perhaps, there are some volunteers who can do it later.