- Oct 31, 2009
-
-
Dan Gohman authored
previously running CodePlacementOpt. Also print headers before each dump in -print-machineinstrs mode, so that it's clear which dump is which. llvm-svn: 85681
-
Dan Gohman authored
to unfold loop-invariant loads. llvm-svn: 85657
-
- Oct 29, 2009
-
-
Bill Wendling authored
llvm-svn: 85460
-
Bill Wendling authored
--- Reverse-merging r85338 into '.': U lib/CodeGen/SimpleRegisterCoalescing.cpp U lib/CodeGen/SimpleRegisterCoalescing.h llvm-svn: 85454
-
- Oct 28, 2009
-
-
Bob Wilson authored
I'm going to redo this using the OptimizeForSize function attribute. llvm-svn: 85426
-
Bob Wilson authored
use it to control tail merging when there is a tradeoff between performance and code size. When there is only 1 instruction in the common tail, we have been merging. That can be good for code size but is a definite loss for performance. Now we will avoid tail merging in that case when the optimization level is "Aggressive", i.e., "-O3". Radar 7338114. Since the IfConversion pass invokes BranchFolding, it too needs to know the optimization level. Note that I removed the RegisterPass instantiation for IfConversion because it required a default constructor. If someone wants to keep that for some reason, we can add a default constructor with a hard-wired optimization level. llvm-svn: 85346
-
- Oct 16, 2009
-
-
Evan Cheng authored
llvm-svn: 84273
-
- Sep 30, 2009
-
-
Evan Cheng authored
llvm-svn: 83144
-
David Goodwin authored
Remove -post-RA-schedule flag and add a TargetSubtarget method to enable post-register-allocation scheduling. By default it is off. For ARM, enable/disable with -mattr=+/-postrasched. Enable by default for cortex-a8. llvm-svn: 83122
-
- Sep 25, 2009
-
-
Evan Cheng authored
llvm-svn: 82803
-
- Sep 16, 2009
-
-
Dan Gohman authored
constants out of loops. These aren't covered by the regular LICM pass, because in LLVM IR constants don't require separate instructions. They're not always covered by the MachineLICM pass either, because it doesn't know how to unfold folded constant-pool loads. This is somewhat experimental at this point, and off by default. llvm-svn: 82076
-
- Aug 26, 2009
-
-
Dan Gohman authored
llvm-svn: 80104
-
- Aug 23, 2009
-
-
Chris Lattner authored
upgrading a few things to use raw_ostream llvm-svn: 79811
-
- Aug 22, 2009
-
-
Chris Lattner authored
llvm-svn: 79763
-
- Aug 17, 2009
-
-
Jim Grosbach authored
more properly belong. This allows removing the front-end conditionalized SJLJ code, and cleans up the generated IR considerably. All of the infrastructure code (calling _Unwind_SjLj_Register/Unregister, etc) is added by the SjLjEHPrepare pass. llvm-svn: 79250
-
- Aug 15, 2009
-
-
Jakob Stoklund Olesen authored
llvm-svn: 79095
-
- Aug 14, 2009
-
-
Daniel Dunbar authored
AsmPrinter instance (instead of just a FunctionPass) llvm-svn: 78962
-
- Aug 13, 2009
-
-
Daniel Dunbar authored
TargetAsmInfo. This eliminates a dependency on TargetMachine.h from TargetRegistry.h, which technically was a layering violation. - Clients probably can only sensibly pass in the same TargetAsmInfo as the TargetMachine has, but there are only limited clients of this API. llvm-svn: 78928
-
- Aug 12, 2009
-
-
Chris Lattner authored
pair instead of from a virtual method on TargetMachine. This cuts the final ties of TargetAsmInfo to TargetMachine, meaning that MC can now use TargetAsmInfo. llvm-svn: 78802
-
- Aug 11, 2009
-
-
Dan Gohman authored
llvm-svn: 78677
-
Jim Grosbach authored
and short. Well, it's kinda short. Definitely nasty and brutish. The front-end generates the register/unregister calls into the SjLj runtime, call-site indices and landing pad dispatch. The back end fills in the LSDA with the call-site information provided by the front end. Catch blocks are not yet implemented. Built on Darwin and verified no llvm-core "make check" regressions. llvm-svn: 78625
-
- Aug 05, 2009
-
-
Evan Cheng authored
llvm-svn: 78179
-
- Jul 31, 2009
-
-
Dan Gohman authored
shouldn't do AU.setPreservesCFG(), because even though CodeGen passes don't modify the LLVM IR CFG, they may modify the MachineFunction CFG, and passes like MachineLoop are registered with isCFGOnly set to true. llvm-svn: 77691
-
Daniel Dunbar authored
failures when building assorted projects with clang. --- Reverse-merging r77654 into '.': U include/llvm/CodeGen/Passes.h U include/llvm/CodeGen/MachineFunctionPass.h U include/llvm/CodeGen/MachineFunction.h U include/llvm/CodeGen/LazyLiveness.h U include/llvm/CodeGen/SelectionDAGISel.h D include/llvm/CodeGen/MachineFunctionAnalysis.h U include/llvm/Function.h U lib/Target/CellSPU/SPUISelDAGToDAG.cpp U lib/Target/PowerPC/PPCISelDAGToDAG.cpp U lib/CodeGen/LLVMTargetMachine.cpp U lib/CodeGen/MachineVerifier.cpp U lib/CodeGen/MachineFunction.cpp U lib/CodeGen/PrologEpilogInserter.cpp U lib/CodeGen/MachineLoopInfo.cpp U lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp D lib/CodeGen/MachineFunctionAnalysis.cpp D lib/CodeGen/MachineFunctionPass.cpp U lib/CodeGen/LiveVariables.cpp llvm-svn: 77661
-
Dan Gohman authored
mechanism. To support this, make MachineFunctionPass a little more complete. llvm-svn: 77654
-
- Jul 16, 2009
-
-
Daniel Dunbar authored
(although we don't get a very good error message). llvm-svn: 75864
-
Daniel Dunbar authored
llvm-svn: 75862
-
Daniel Dunbar authored
- No functionality change. llvm-svn: 75859
-
Daniel Dunbar authored
- No intended functionality change. llvm-svn: 75848
-
- Jul 14, 2009
-
-
David Greene authored
Have asm printers use formatted_raw_ostream directly to avoid a dynamic_cast<>. llvm-svn: 75670
-
Evan Cheng authored
llvm-svn: 75553
-
- Jul 06, 2009
-
-
Bruno Cardoso Lopes authored
cleanup, removed some #includes and moved Object Code Emitter out-of-line. llvm-svn: 74813
-
- Jun 13, 2009
-
-
Evan Cheng authored
consecutive addresses togther. This makes it easier for the post-allocation pass to form ldm / stm. This is step 1. We are still missing a lot of ldm / stm opportunities because of register allocation are not done in the desired order. More enhancements coming. llvm-svn: 73291
-
- May 30, 2009
-
-
Bruno Cardoso Lopes authored
JITCodeEmitter and ObjectCodeEmitter. No functional changes yet. Patch by Aaron Gray llvm-svn: 72631
-
- May 22, 2009
-
-
Duncan Sands authored
code in preparation for code generation. The main thing it does is handle the case when eh.exception calls (and, in a future patch, eh.selector calls) are far away from landing pads. Right now in practice you only find eh.exception calls close to landing pads: either in a landing pad (the common case) or in a landing pad successor, due to loop passes shifting them about. However future exception handling improvements will result in calls far from landing pads: (1) Inlining of rewinds. Consider the following case: In function @f: ... invoke @g to label %normal unwind label %unwinds ... unwinds: %ex = call i8* @llvm.eh.exception() ... In function @g: ... invoke @something to label %continue unwind label %handler ... handler: %ex = call i8* @llvm.eh.exception() ... perform cleanups ... "rethrow exception" Now inline @g into @f. Currently this is turned into: In function @f: ... invoke @something to label %continue unwind label %handler ... handler: %ex = call i8* @llvm.eh.exception() ... perform cleanups ... invoke "rethrow exception" to label %normal unwind label %unwinds unwinds: %ex = call i8* @llvm.eh.exception() ... However we would like to simplify invoke of "rethrow exception" into a branch to the %unwinds label. Then %unwinds is no longer a landing pad, and the eh.exception call there is then far away from any landing pads. (2) Using the unwind instruction for cleanups. It would be nice to have codegen handle the following case: invoke @something to label %continue unwind label %run_cleanups ... handler: ... perform cleanups ... unwind This requires turning "unwind" into a library call, which necessarily takes a pointer to the exception as an argument (this patch also does this unwind lowering). But that means you are using eh.exception again far from a landing pad. (3) Bugpoint simplifications. When bugpoint is simplifying exception handling code it often generates eh.exception calls far from a landing pad, which then causes codegen to assert. Bugpoint then latches on to this assertion and loses sight of the original problem. Note that it is currently rare for this pass to actually do anything. And in fact it normally shouldn't do anything at all given the code coming out of llvm-gcc! But it does fire a few times in the testsuite. As far as I can see this is almost always due to the LoopStrengthReduce codegen pass introducing pointless loop preheader blocks which are landing pads and only contain a branch to another block. This other block contains an eh.exception call. So probably by tweaking LoopStrengthReduce a bit this can be avoided. llvm-svn: 72276
-
- May 16, 2009
-
-
Jakob Stoklund Olesen authored
The following is checked: * Operand counts: All explicit operands must be present. * Register classes: All physical and virtual register operands must be compatible with the register class required by the instruction descriptor. * Register live intervals: Registers must be defined only once, and must be defined before use. The machine code verifier is enabled with the command-line option '-verify-machineinstrs', or by defining the environment variable LLVM_VERIFY_MACHINEINSTRS to the name of a file that will receive all the verifier errors. llvm-svn: 71918
-
- May 12, 2009
-
-
Evan Cheng authored
Fixed a stack slot coloring with reg bug: do not update implicit use / def when doing forward / backward propagation. llvm-svn: 71574
-
- May 07, 2009
-
-
Evan Cheng authored
llvm-svn: 71150
-
Bill Wendling authored
llvm-svn: 71140
-
Bill Wendling authored
llvm-svn: 71138
-