- Oct 19, 2010
-
-
Dan Gohman authored
llvm-svn: 116858
-
Owen Anderson authored
they do not also require them. This allows us to reduce inter-pass linkage dependencies. llvm-svn: 116854
-
Dan Gohman authored
use uint64_t. llvm-svn: 116839
-
Owen Anderson authored
Get rid of static constructors for pass registration. Instead, every pass exposes an initializeMyPassFunction(), which must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize the pass's dependencies. Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h before parsing commandline arguments. I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass registration/creation, please send the testcase to me directly. llvm-svn: 116820
-
Dan Gohman authored
llvm-svn: 116815
-
- Oct 18, 2010
-
-
Dan Gohman authored
llvm-svn: 116743
-
- Oct 16, 2010
-
-
Benjamin Kramer authored
llvm-svn: 116670
-
Owen Anderson authored
forwarding is implemented with a load/store pair rather than a memcpy. llvm-svn: 116637
-
- Oct 13, 2010
-
-
Rafael Espindola authored
llvm-svn: 116387
-
- Oct 12, 2010
-
-
Owen Anderson authored
perform initialization without static constructors AND without explicit initialization by the client. For the moment, passes are required to initialize both their (potential) dependencies and any passes they preserve. I hope to be able to relax the latter requirement in the future. llvm-svn: 116334
-
- Oct 08, 2010
-
-
Dan Gohman authored
formulae which become illegal as a result of the offset updating don't escape. This is for rdar://8529692. No testcase yet, because the given cases hit use-list ordering differences. llvm-svn: 116093
-
Daniel Dunbar authored
llvm-svn: 116034
-
Dan Gohman authored
one user. This code will be restructured soon and FormulaSorter is getting in the way. llvm-svn: 116012
-
Dan Gohman authored
llvm-svn: 116011
-
Dan Gohman authored
not just base registers. llvm-svn: 116010
-
Dan Gohman authored
llvm-svn: 116009
-
Dan Gohman authored
the old use to the new one. llvm-svn: 116008
-
Dan Gohman authored
This doesn't usually matter, because the other heuristics usually succeed regardless, but it's good to keep the register use bookkeeping consistent. llvm-svn: 116005
-
Devang Patel authored
llvm-svn: 116004
-
Owen Anderson authored
llvm-svn: 115996
-
- Oct 07, 2010
-
-
Owen Anderson authored
initialization functions that initialize the set of passes implemented in that library. Add C bindings for these functions as well. llvm-svn: 115927
-
- Oct 01, 2010
-
-
Owen Anderson authored
Now that the profitable bits of EnableFullLoadPRE have been enabled by default, rip out the remainder. Anyone interested in more general PRE would be better served by implementing it separately, to get real anticipation calculation, etc. llvm-svn: 115337
-
Eric Christopher authored
memcpy alignment is the minimum of the incoming alignments. Fixes PR 8266. llvm-svn: 115305
-
Dale Johannesen authored
The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. llvm-svn: 115243
-
- Sep 30, 2010
-
-
Owen Anderson authored
We do want to allow LoadPRE to perform LICM-like transformations: we already consider PHI nodes to be negligible for code size (making this transform code size neutral), and it allows us to hoist values out of loops, which is always a good thing. llvm-svn: 115205
-
Jakob Stoklund Olesen authored
The bug that broke i386 linux has been fixed in r115191. llvm-svn: 115204
-
Benjamin Kramer authored
Tighten up prototype verification of strchr and strrchr to avoid a crash in the very unlikely case that someone passes an integer > i64 to strchr. llvm-svn: 115144
-
Benjamin Kramer authored
llvm-svn: 115116
-
Benjamin Kramer authored
llvm-svn: 115111
-
Benjamin Kramer authored
llvm-svn: 115095
-
- Sep 29, 2010
-
-
Benjamin Kramer authored
llvm-svn: 115091
-
Owen Anderson authored
Fix PR8247: JumpThreading can cause a block to become unreachable while still having predecessor, if it is part of a self-loop. Because of this, we cannot use the Simplify* APIs, as they can assert-fail on unreachable code. Since it's not easy to determine if a given threading will cause a block to become unreachable, simply defer simplifying simplification to later InstCombine and/or DCE passes. llvm-svn: 115082
-
Owen Anderson authored
llvm-svn: 115053
-
Oscar Fuentes authored
llvm-svn: 114999
-
- Sep 28, 2010
-
-
Owen Anderson authored
register pressure and thus excess spills, which we don't currently recover from well. This should be re-evaluated in the future if our ability to generate good spills/splits improves. Partial fix for <rdar://problem/7635585>. llvm-svn: 114919
-
- Sep 27, 2010
-
-
Jakob Stoklund Olesen authored
This reverts revision 114633. It was breaking llvm-gcc-i386-linux-selfhost. It seems there is a downstream bug that is exposed by -cgp-critical-edge-splitting=0. When that bug is fixed, this patch can go back in. Note that the changes to tailcallfp2.ll are not reverted. They were good are required. llvm-svn: 114859
-
Dan Gohman authored
llvm-svn: 114841
-
- Sep 25, 2010
-
-
Owen Anderson authored
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. llvm-svn: 114785
-
Eric Christopher authored
of the source, not the original alignment since it may no longer be valid. Fixes rdar://8400094 llvm-svn: 114781
-
- Sep 23, 2010
-
-
Evan Cheng authored
break critical edges on demand. llvm-svn: 114633
-