- 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
-
Jim Grosbach authored
enable it for real. Leaving the CL option in place to it's easy to disable it again if (when) testers find something I've missed. llvm-svn: 114915
-
Rafael Espindola authored
makes files easier to diff. llvm-svn: 114898
-
- Sep 27, 2010
-
-
Jim Grosbach authored
llvm-svn: 114896
-
Rafael Espindola authored
llvm-svn: 114895
-
Jakob Stoklund Olesen authored
Usually we wouldn't do this anyway because llvm_fenv_testexcept would return an exception, but we have seen some cases where neither errno nor fenv detect an exception on arm-linux. llvm-svn: 114893
-
Jim Grosbach authored
enable it for real. Leaving the CL option in place to it's easy to disable it again if (when) testers find something I've missed. llvm-svn: 114892
-
Rafael Espindola authored
llvm-svn: 114891
-
Michael J. Spencer authored
llvm-svn: 114888
-
Daniel Dunbar authored
llvm-svn: 114862
-
Daniel Dunbar authored
llvm-svn: 114861
-
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
-
Rafael Espindola authored
llc now recognizes the "intent" to support MC/obj emission for ARM, but given that they are all stubs, it asserts on --filetype=obj --march=arm Patch by Jason Kim. llvm-svn: 114856
-
Rafael Espindola authored
llvm-svn: 114852
-
Benjamin Kramer authored
llvm-svn: 114847
-
Dale Johannesen authored
llvm-svn: 114844
-
Dale Johannesen authored
and asserts. llvm-svn: 114843
-
Dan Gohman authored
llvm-svn: 114841
-
Dan Gohman authored
llvm-svn: 114839
-
Dan Gohman authored
llvm-svn: 114832
-
Dan Gohman authored
llvm-svn: 114828
-
Michael J. Spencer authored
targeted at symbols into relocations relative to the containing section. Patch by Nathan Jeffords! llvm-svn: 114823
-
Chris Lattner authored
llvm-svn: 114822
-
-
-
rdar://8468087Chris Lattner authored
My previous fix for rdar://8456371 should only apply to fmulp/faddp, not to fmul/fadd. Instruction set orthogonality is overrated or something. llvm-svn: 114818
-
Chris Lattner authored
support aligned comm. Detect when compiling for 10.4 and don't emit an alignment for comm. THis will hopefully fix PR8198. llvm-svn: 114817
-
Chris Lattner authored
llvm-svn: 114815
-
Eric Christopher authored
divide support also. llvm-svn: 114813
-
Eric Christopher authored
llvm-svn: 114812
-
Eric Christopher authored
llvm-svn: 114811
-
-
- Sep 26, 2010
-
-
Lang Hames authored
Fixed some tests to avoid LiveIntervals::getInstructionFromIndex(..) overhead where possible. Thanks to Jakob for the suggestions. llvm-svn: 114798
-
- Sep 25, 2010
-
-
Jakob Stoklund Olesen authored
llvm-svn: 114794
-
Lang Hames authored
Removed VNInfo::isDefAccurate(). Def "accuracy" can be checked by testing whether LiveIntervals::getInstructionFromIndex(def) returns NULL. llvm-svn: 114791
-
Che-Liang Chiou authored
llvm-svn: 114788
-
Rafael Espindola authored
symbols defined in merge sections in independent atoms. llvm-svn: 114786
-
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
-
Evan Cheng authored
llvm-svn: 114784
-
Evan Cheng authored
llvm-svn: 114782
-