llvm-6502/lib/Transforms
Owen Anderson b0ba0f4170 LoadPRE was not properly checking that the load it was PRE'ing post-dominated the block it was being hoisted to.
Splitting critical edges at the merge point only addressed part of the issue; it is also possible for non-post-domination
to occur when the path from the load to the merge has branches in it.  Unfortunately, full anticipation analysis is
time-consuming, so for now approximate it.  This is strictly more conservative than real anticipation, so we will miss
some cases that real PRE would allow, but we also no longer insert loads into paths where they didn't exist before. :-)

This is a very slight net positive on SPEC for me (0.5% on average).  Most of the benchmarks are largely unaffected, but
when it pays off it pays off decently: 181.mcf improves by 4.5% on my machine.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114785 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-25 05:26:18 +00:00
..
Hello Reapply r110396, with fixes to appease the Linux buildbot gods. 2010-08-06 18:33:48 +00:00
InstCombine Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." 2010-09-13 23:59:48 +00:00
Instrumentation Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." 2010-09-13 23:59:48 +00:00
IPO Fix llvm-extract so that it changes the linkage of all GlobalValues to 2010-09-23 17:25:06 +00:00
Scalar LoadPRE was not properly checking that the load it was PRE'ing post-dominated the block it was being hoisted to. 2010-09-25 05:26:18 +00:00
Utils Get rid of pop_macro warnings on MSVC. 2010-09-24 19:48:47 +00:00
Makefile Revert r100896 and around - this breaks the only mingw32 buildbot we have. 2010-04-15 19:51:42 +00:00