| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
This reverts commit r288046.
Trying to see if the revert fixes a compiler crash during a stage2 LTO
build with a GVN backtrace.
llvm-svn: 288179
|
|
|
|
|
|
|
|
|
| |
This reverts commit r288047.
Trying to see if the revert fixes a compiler crash during a stage2 LTO
build with a GVN backtrace.
llvm-svn: 288178
|
|
|
|
|
|
|
|
|
|
|
| |
load-elimination"
This reverts commit r288090.
Trying to see if the revert fixes a compiler crash during a stage2 LTO
build with a GVN backtrace.
llvm-svn: 288177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
load-elimination
This includes the intervening store and the load/store that we're trying
to forward from in the optimization remark for the missed load
elimination.
This is hooked up under a new mode in ORE that allows for compile-time
budget for a bit more analysis to print more insightful messages. This
mode is currently enabled for -fsave-optimization-record (-Rpass is
trickier since it is controlled in the front-end).
With this we can now print the red remark in http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L446
Differential Revision: https://reviews.llvm.org/D26490
llvm-svn: 288090
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires some changes to the opt-diag API. Hal and I have
discussed this at the Dev Meeting and came up with a streaming delimiter
(setExtraArgs) to solve this.
Arguments after this delimiter are only included in the optimization
records and not in the remarks printed in the compiler output. (Note,
how in the test the content of the YAML file changes but the remarks on
the compiler output don't.)
This implements the green GVN message with a bug fix at line
http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L446
The fix is that now we properly include the constant value in the
message: "load of type i32 eliminated in favor of 7"
Differential Revision: https://reviews.llvm.org/D26489
llvm-svn: 288047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-on patches will add more interesting cases.
The goal of this patch-set is to get the GVN messages printed in
opt-viewer from Dhrystone as was presented in my Dev Meeting talk. This
is the optimization view for the function (the last remark in the
function has a bug which is fixed in this series):
http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L430
Differential Revision: https://reviews.llvm.org/D26488
llvm-svn: 288046
|
|
|
|
|
|
|
| |
Reviewer: Hal Finkel.
Differential Revision: https://reviews.llvm.org/D26952
llvm-svn: 287700
|
|
|
|
|
|
|
|
|
| |
There's no agreement about this patch. I personally find the
PRE machinery of the current GVN hard enough to reason about
that I'm not sure I'll try to land this again, instead of working
on the rewrite).
llvm-svn: 284796
|
|
|
|
|
|
|
|
|
|
|
| |
In theory this could be generalized to move anything where
we prove the operands are available, but that would require
rewriting PRE. As NewGVN will hopefully come soon, and we're
trying to rewrite PRE in terms of NewGVN+MemorySSA, it's probably
not worth spending too much time on it. Fix provided by
Daniel Berlin!
llvm-svn: 284311
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
While walking defs of pointer operands we were assuming that the pointer
size would remain constant. This is not true, because addresspacecast
instructions may cast the pointer to an address space with a different
pointer width.
This partial reverts r282612, which was a more conservative solution
to this problem.
Reviewers: reames, sanjoy, apilipenko
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D24772
llvm-svn: 283557
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pointers in different addrspaces can have different sizes, so it's not valid to look through addrspace cast calculating base and offset for a value.
This is similar to D13008.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D24729
llvm-svn: 282612
|
|
|
|
| |
llvm-svn: 282161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Widening load in GVN is too early because it will block other optimizations like PRE, LICM.
https://llvm.org/bugs/show_bug.cgi?id=29110
The SPECCPU2006 benchmark impact of this patch:
Reference: o2_nopatch
(1): o2_patched
Benchmark Base:Reference (1)
-------------------------------------------------------
spec/2006/fp/C++/444.namd 25.2 -0.08%
spec/2006/fp/C++/447.dealII 45.92 +1.05%
spec/2006/fp/C++/450.soplex 41.7 -0.26%
spec/2006/fp/C++/453.povray 35.65 +1.68%
spec/2006/fp/C/433.milc 23.79 +0.42%
spec/2006/fp/C/470.lbm 41.88 -1.12%
spec/2006/fp/C/482.sphinx3 47.94 +1.67%
spec/2006/int/C++/471.omnetpp 22.46 -0.36%
spec/2006/int/C++/473.astar 21.19 +0.24%
spec/2006/int/C++/483.xalancbmk 36.09 -0.11%
spec/2006/int/C/400.perlbench 33.28 +1.35%
spec/2006/int/C/401.bzip2 22.76 -0.04%
spec/2006/int/C/403.gcc 32.36 +0.12%
spec/2006/int/C/429.mcf 41.04 -0.41%
spec/2006/int/C/445.gobmk 26.94 +0.04%
spec/2006/int/C/456.hmmer 24.5 -0.20%
spec/2006/int/C/458.sjeng 28 -0.46%
spec/2006/int/C/462.libquantum 55.25 +0.27%
spec/2006/int/C/464.h264ref 45.87 +0.72%
geometric mean +0.23%
For most benchmarks, it's a wash, but we do see stable improvements on some benchmarks, e.g. 447,453,482,400.
Reviewers: davidxl, hfinkel, dberlin, sanjoy, reames
Subscribers: gberry, junbuml
Differential Revision: https://reviews.llvm.org/D24096
llvm-svn: 281074
|
|
|
|
|
|
| |
supports) pointer arguments, and these intrinsics have vector of pointer arguments. Remove ArgMemOnly until we either have the machinery, define a new attribute, or something similar
llvm-svn: 280143
|
|
|
|
| |
llvm-svn: 278404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes PR 28933 by making sure GVNHoist does not try to recreate memory
accesses when it has not actually moved them.
Reviewers: sebpop
Subscribers: llvm-commits, george.burgess.iv
Differential Revision: https://reviews.llvm.org/D23411
llvm-svn: 278401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We teach alias analysis that invariant.start is readonly.
This helps with GVN and memcopy optimizations that currently treat.
invariant.start as a clobber.
We need to treat this as readonly, so that DSE does not incorrectly
remove stores prior to the invariant.start
Reviewers: sanjoy, reames, majnemer, dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23214
llvm-svn: 278138
|
|
|
|
|
|
|
|
|
|
| |
The patch splits a complex && if condition into easier to read and understand
logic. That wrong early exit condition was letting some instructions with not
all operands available pass through when HoistingGeps was true.
Differential Revision: https://reviews.llvm.org/D23174
llvm-svn: 277785
|
|
|
|
| |
llvm-svn: 277767
|
|
|
|
|
|
|
|
| |
With this patch we compute the MemorySSA once and update it in the code generator.
Differential Revision: https://reviews.llvm.org/D22966
llvm-svn: 277649
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When loading or storing in a field of a struct like "a.b.c", GVN is able to
detect the equivalent expressions, and GVN-hoist would fail in the code
generation. This is because the GEPs are not hoisted as scalar operations to
avoid moving the GEPs too far from their ld/st instruction when the ld/st is not
movable. So we end up having to generate code for the GEP of a ld/st when we
move the ld/st. In the case of a GEP referring to another GEP as in "a.b.c" we
need to code generate all the GEPs necessary to make all the operands available
at the new location for the ld/st. With this patch we recursively walk through
the GEP operands checking whether all operands are available, and in the case of
a GEP operand, it recursively makes all its operands available. Code generation
happens from the inner GEPs out until reaching the GEP that appears as an
operand of the ld/st.
Differential Revision: https://reviews.llvm.org/D22599
llvm-svn: 276841
|
|
|
|
|
|
| |
Use isEliminableCastPair to determine if a pair of casts are foldable.
llvm-svn: 276777
|
|
|
|
|
|
|
| |
This reverts commit r276700 and reapplies r276698.
The relevant clang tests have been updated.
llvm-svn: 276727
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of DFS numbering basic blocks we now DFS number instructions that avoids
the costly operation of which instruction comes first in a basic block.
Patch mostly written by Daniel Berlin.
Differential Revision: https://reviews.llvm.org/D22777
llvm-svn: 276714
|
|
|
|
|
|
|
| |
This reverts commit r276698. Clang has tests which rely on the
optimizer :(
llvm-svn: 276700
|
|
|
|
|
|
|
| |
BitCasts of BitCasts can be folded away as can BitCasts which don't
change the type of the operand.
llvm-svn: 276698
|
|
|
|
|
|
|
| |
We can combine metadata from multiple instructions intelligently for
certain metadata nodes.
llvm-svn: 276602
|
|
|
|
|
|
|
|
|
| |
If we two loads of two different alignments, we must use the minimum of
the two alignments when hoisting. Same deal for stores.
For allocas, use the maximum of the two allocas.
llvm-svn: 276601
|
|
|
|
|
|
|
|
|
| |
Do not clone stored values unless they are GEPs that are special cased to avoid
hoisting them without hoisting their associated ld/st.
Differential revision: https://reviews.llvm.org/D22652
llvm-svn: 276358
|
|
|
|
|
|
|
| |
If we have optimization hints with agree with each other along different
paths, preserve them.
llvm-svn: 276248
|
|
|
|
|
|
|
| |
We hoisted loads/stores without taking into account which can cause
miscompiles.
llvm-svn: 276240
|
|
|
|
|
|
|
|
|
| |
We hoisted PHIs without respecting their special insertion point in the
block, leading to verfier errors.
This fixes PR28626.
llvm-svn: 276181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While debugging GVNHoist, I found it confusing that the entries in a
VNtoInsns were not always value numbers. They _usually_ were except for
StoreInst in which case they were a hash of two different value numbers.
This leads to two observations:
- It is more difficult to debug things when the semantic contents of
VNtoInsns changes over time.
- Using a single value number is not much cheaper, the value of
VNtoInsns is a SmallVector.
- It is not immediately clear what the algorithm would do if there were
hash collisions in the StoreInst case.
Using a DenseMap of std::pair sidesteps all of this.
N.B. The changes in the test were due their sensitivity to the
iteration order of VNtoInsns which has changed.
llvm-svn: 275761
|
|
|
|
| |
llvm-svn: 275742
|
|
|
|
| |
llvm-svn: 275741
|
|
|
|
| |
llvm-svn: 275739
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass hoists duplicated computations in the program. The primary goal of
gvn-hoist is to reduce the size of functions before inline heuristics to reduce
the total cost of function inlining.
Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki.
Important algorithmic contributions by Daniel Berlin under the form of reviews.
Differential Revision: http://reviews.llvm.org/D19338
llvm-svn: 275561
|
|
|
|
|
|
|
|
|
| |
We didn't consider the inbounds flag on GEPs leading to downstream users
introducing UB.
This fixes PR28562.
llvm-svn: 275532
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for PR 28418.
opt never finishes compiling a test when -gvn option is passed.
The problem is caused by the fact that GVN fails to fold a constant expression.
Differential Revision: https://reviews.llvm.org/D22185
llvm-svn: 275483
|
|
|
|
| |
llvm-svn: 275420
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass hoists duplicated computations in the program. The primary goal of
gvn-hoist is to reduce the size of functions before inline heuristics to reduce
the total cost of function inlining.
Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki.
Important algorithmic contributions by Daniel Berlin under the form of reviews.
Differential Revision: http://reviews.llvm.org/D19338
llvm-svn: 275401
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r274327 since the tests fail. E.g.:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/17240
It looks like this commit is building on r274305, but that commit caused
a miscompile and was reverted in r274320.
llvm-svn: 274332
|
|
|
|
|
|
|
| |
https://llvm.org/bugs/show_bug.cgi?id=20242
https://llvm.org/bugs/show_bug.cgi?id=22005
llvm-svn: 274327
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r274305, since it breaks self-hosting:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/22349/
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/17232
Note that the blamelist on lab.llvm.org:8011 is incorrect. The previous
build was r274299, but somehow r274305 wasn't included in the blamelist:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules
llvm-svn: 274320
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass hoists duplicated computations in the program. The primary goal of
gvn-hoist is to reduce the size of functions before inline heuristics to reduce
the total cost of function inlining.
Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki.
Important algorithmic contributions by Daniel Berlin under the form of reviews.
Differential Revision: http://reviews.llvm.org/D19338
llvm-svn: 274305
|
|
|
|
|
|
|
|
|
|
| |
r273711 was reverted by r273743. The inliner needs to know about any
call sites in the inlined function. These were obscured if we replaced
a call to undef with an undef but kept the call around.
This fixes PR28298.
llvm-svn: 273753
|
|
|
|
| |
llvm-svn: 273743
|
|
|
|
|
|
|
| |
We cannot remove an instruction with no uses just because
SimplifyInstruction succeeds. It may have side effects.
llvm-svn: 273711
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dberlin, reames, george.burgess.iv
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D20743
llvm-svn: 271034
|
|
|
|
|
|
| |
Again, fairly simple. Only change is ensuring that we actually copy the property of the load correctly. The aliasing legality constraints were already handled by the FRE patches. There's nothing special about unorder atomics from the perspective of the PRE algorithm itself.
llvm-svn: 268804
|