llvm-6502/include/llvm/CodeGen/Passes.h

211 lines
8.3 KiB
C
Raw Normal View History

//===-- Passes.h - Target independent code generation passes ----*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines interfaces to access the target independent code generation
// passes provided by the LLVM backend.
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_CODEGEN_PASSES_H
#define LLVM_CODEGEN_PASSES_H
#include "llvm/Target/TargetMachine.h"
#include <string>
namespace llvm {
class FunctionPass;
class MachineFunctionPass;
class PassInfo;
class TargetLowering;
class RegisterCoalescer;
class raw_ostream;
/// createUnreachableBlockEliminationPass - The LLVM code generator does not
/// work well with unreachable basic blocks (what live ranges make sense for a
/// block that cannot be reached?). As such, a code generator should either
/// not instruction select unreachable blocks, or it can run this pass as it's
/// last LLVM modifying pass to clean up blocks that are not reachable from
/// the entry block.
FunctionPass *createUnreachableBlockEliminationPass();
/// MachineFunctionPrinter pass - This pass prints out the machine function to
/// the given stream, as a debugging tool.
MachineFunctionPass *
createMachineFunctionPrinterPass(raw_ostream &OS,
const std::string &Banner ="");
/// MachineLoopInfo pass - This pass is a loop analysis pass.
///
extern const PassInfo *const MachineLoopInfoID;
/// MachineDominators pass - This pass is a machine dominators analysis pass.
///
extern const PassInfo *const MachineDominatorsID;
/// PHIElimination pass - This pass eliminates machine instruction PHI nodes
/// by inserting copy instructions. This destroys SSA information, but is the
/// desired input for some register allocators. This pass is "required" by
/// these register allocator like this: AU.addRequiredID(PHIEliminationID);
///
extern const PassInfo *const PHIEliminationID;
/// StrongPHIElimination pass - This pass eliminates machine instruction PHI
/// nodes by inserting copy instructions. This destroys SSA information, but
/// is the desired input for some register allocators. This pass is
/// "required" by these register allocator like this:
/// AU.addRequiredID(PHIEliminationID);
/// This pass is still in development
extern const PassInfo *const StrongPHIEliminationID;
extern const PassInfo *const PreAllocSplittingID;
/// SimpleRegisterCoalescing pass. Aggressively coalesces every register
/// copy it can.
///
extern const PassInfo *const SimpleRegisterCoalescingID;
/// TwoAddressInstruction pass - This pass reduces two-address instructions to
/// use two operands. This destroys SSA information but it is desired by
/// register allocators.
extern const PassInfo *const TwoAddressInstructionPassID;
/// UnreachableMachineBlockElimination pass - This pass removes unreachable
/// machine basic blocks.
extern const PassInfo *const UnreachableMachineBlockElimID;
/// DeadMachineInstructionElim pass - This pass removes dead machine
/// instructions.
///
FunctionPass *createDeadMachineInstructionElimPass();
/// Creates a register allocator as the user specified on the command line.
///
FunctionPass *createRegisterAllocator();
/// LocalRegisterAllocation Pass - This pass register allocates the input code
/// a basic block at a time, yielding code better than the simple register
/// allocator, but not as good as a global allocator.
///
FunctionPass *createLocalRegisterAllocator();
/// LinearScanRegisterAllocation Pass - This pass implements the linear scan
/// register allocation algorithm, a global register allocator.
///
FunctionPass *createLinearScanRegisterAllocator();
/// PBQPRegisterAllocation Pass - This pass implements the Partitioned Boolean
/// Quadratic Prograaming (PBQP) based register allocator.
///
FunctionPass *createPBQPRegisterAllocator();
/// SimpleRegisterCoalescing Pass - Coalesce all copies possible. Can run
/// independently of the register allocator.
///
RegisterCoalescer *createSimpleRegisterCoalescer();
/// PrologEpilogCodeInserter Pass - This pass inserts prolog and epilog code,
/// and eliminates abstract frame references.
///
FunctionPass *createPrologEpilogCodeInserter();
/// LowerSubregs Pass - This pass lowers subregs to register-register copies
/// which yields suboptimal, but correct code if the register allocator
/// cannot coalesce all subreg operations during allocation.
///
FunctionPass *createLowerSubregsPass();
/// createPostRAScheduler - This pass performs post register allocation
/// scheduling.
FunctionPass *createPostRAScheduler(CodeGenOpt::Level OptLevel);
/// BranchFolding Pass - This pass performs machine code CFG based
/// optimizations to delete branches to branches, eliminate branches to
/// successor blocks (creating fall throughs), and eliminating branches over
/// branches.
FunctionPass *createBranchFoldingPass(bool DefaultEnableTailMerge);
/// TailDuplicate Pass - Duplicate blocks with unconditional branches
/// into tails of their predecessors.
FunctionPass *createTailDuplicatePass(bool PreRegAlloc = false);
/// IfConverter Pass - This pass performs machine code if conversion.
FunctionPass *createIfConverterPass();
/// Code Placement Pass - This pass optimize code placement and aligns loop
/// headers to target specific alignment boundary.
FunctionPass *createCodePlacementOptPass();
/// getRegisterAllocator - This creates an instance of the register allocator
/// for the Sparc.
FunctionPass *getRegisterAllocator(TargetMachine &T);
/// IntrinsicLowering Pass - Performs target-independent LLVM IR
/// transformations for highly portable strategies.
FunctionPass *createGCLoweringPass();
/// MachineCodeAnalysis Pass - Target-independent pass to mark safe points in
/// machine code. Must be added very late during code generation, just prior
/// to output, and importantly after all CFG transformations (such as branch
/// folding).
FunctionPass *createGCMachineCodeAnalysisPass();
/// Deleter Pass - Releases GC metadata.
///
FunctionPass *createGCInfoDeleter();
/// Creates a pass to print GC metadata.
///
FunctionPass *createGCInfoPrinter(raw_ostream &OS);
/// createMachineCSEPass - This pass performs global CSE on machine
/// instructions.
FunctionPass *createMachineCSEPass();
/// createMachineLICMPass - This pass performs LICM on machine instructions.
///
FunctionPass *createMachineLICMPass(bool PreRegAlloc = true);
/// createMachineSinkingPass - This pass performs sinking on machine
/// instructions.
FunctionPass *createMachineSinkingPass();
/// createOptimizeExtsPass - This pass performs sign / zero extension
/// optimization by increasing uses of extended values.
FunctionPass *createOptimizeExtsPass();
/// createOptimizePHIsPass - This pass optimizes machine instruction PHIs
/// to take advantage of opportunities created during DAG legalization.
FunctionPass *createOptimizePHIsPass();
/// createStackSlotColoringPass - This pass performs stack slot coloring.
FunctionPass *createStackSlotColoringPass(bool);
/// createStackProtectorPass - This pass adds stack protectors to functions.
FunctionPass *createStackProtectorPass(const TargetLowering *tli);
/// createMachineVerifierPass - This pass verifies cenerated machine code
/// instructions for correctness.
///
/// @param allowDoubleDefs ignore double definitions of
/// registers. Useful before LiveVariables has run.
FunctionPass *createMachineVerifierPass(bool allowDoubleDefs);
Add a new codegen pass that normalizes dwarf exception handling 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72276 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-22 20:36:31 +00:00
/// createDwarfEHPass - This pass mulches exception handling code into a form
/// adapted to code generation. Required if using dwarf exception handling.
FunctionPass *createDwarfEHPass(const TargetLowering *tli, bool fast);
Add a new codegen pass that normalizes dwarf exception handling 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72276 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-22 20:36:31 +00:00
/// createSjLjEHPass - This pass adapts exception handling code to use
/// the GCC-style builtin setjmp/longjmp (sjlj) to handling EH control flow.
FunctionPass *createSjLjEHPass(const TargetLowering *tli);
} // End llvm namespace
#endif