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

260 lines
9.9 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 TargetRegisterClass;
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 run this pass as its
/// 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 char &MachineLoopInfoID;
/// MachineLoopRanges pass - This pass is an on-demand loop coverage
/// analysis pass.
///
extern char &MachineLoopRangesID;
/// MachineDominators pass - This pass is a machine dominators analysis pass.
///
extern char &MachineDominatorsID;
/// EdgeBundles analysis - Bundle machine CFG edges.
///
extern char &EdgeBundlesID;
/// 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 char &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 char &StrongPHIEliminationID;
/// LiveStacks pass. An analysis keeping track of the liveness of stack slots.
extern char &LiveStacksID;
/// TwoAddressInstruction pass - This pass reduces two-address instructions to
/// use two operands. This destroys SSA information but it is desired by
/// register allocators.
extern char &TwoAddressInstructionPassID;
/// RegisteCoalescer pass - This pass merges live ranges to eliminate copies.
extern char &RegisterCoalescerPassID;
/// MachineScheduler pass - This pass schedules machine instructions.
extern char &MachineSchedulerID;
/// SpillPlacement analysis. Suggest optimal placement of spill code between
/// basic blocks.
///
extern char &SpillPlacementID;
/// UnreachableMachineBlockElimination pass - This pass removes unreachable
/// machine basic blocks.
extern char &UnreachableMachineBlockElimID;
/// DeadMachineInstructionElim pass - This pass removes dead machine
/// instructions.
///
FunctionPass *createDeadMachineInstructionElimPass();
/// Creates a register allocator as the user specified on the command line, or
/// picks one that matches OptLevel.
///
FunctionPass *createRegisterAllocator(CodeGenOpt::Level OptLevel);
/// FastRegisterAllocation Pass - This pass register allocates as fast as
/// possible. It is best suited for debug code where live ranges are short.
///
FunctionPass *createFastRegisterAllocator();
/// BasicRegisterAllocation Pass - This pass implements a degenerate global
/// register allocator using the basic regalloc framework.
///
FunctionPass *createBasicRegisterAllocator();
/// Greedy register allocation pass - This pass implements a global register
/// allocator for optimized builds.
///
FunctionPass *createGreedyRegisterAllocator();
/// PBQPRegisterAllocation Pass - This pass implements the Partitioned Boolean
/// Quadratic Prograaming (PBQP) based register allocator.
///
FunctionPass *createDefaultPBQPRegisterAllocator();
/// PrologEpilogCodeInserter Pass - This pass inserts prolog and epilog code,
/// and eliminates abstract frame references.
///
FunctionPass *createPrologEpilogCodeInserter();
/// ExpandPostRAPseudos Pass - This pass expands pseudo instructions after
/// register allocation.
///
FunctionPass *createExpandPostRAPseudosPass();
/// 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();
Implement a block placement pass based on the branch probability and block frequency analyses. This differs substantially from the existing block-placement pass in LLVM: 1) It operates on the Machine-IR in the CodeGen layer. This exposes much more (and more precise) information and opportunities. Also, the results are more stable due to fewer transforms ocurring after the pass runs. 2) It uses the generalized probability and frequency analyses. These can model static heuristics, code annotation derived heuristics as well as eventual profile loading. By basing the optimization on the analysis interface it can work from any (or a combination) of these inputs. 3) It uses a more aggressive algorithm, both building chains from tho bottom up to maximize benefit, and using an SCC-based walk to layout chains of blocks in a profitable ordering without O(N^2) iterations which the old pass involves. The pass is currently gated behind a flag, and not enabled by default because it still needs to grow some important features. Most notably, it needs to support loop aligning and careful layout of loop structures much as done by hand currently in CodePlacementOpt. Once it supports these, and has sufficient testing and quality tuning, it should replace both of these passes. Thanks to Nick Lewycky and Richard Smith for help authoring & debugging this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm forgetting for reviewing and answering all my questions. Writing a backend pass is *sooo* much better now than it used to be. =D git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142641 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 06:46:38 +00:00
/// MachineBlockPlacement Pass - This pass places basic blocks based on branch
/// probabilities.
FunctionPass *createMachineBlockPlacementPass();
/// MachineBlockPlacementStats Pass - This pass collects statistics about the
/// basic block placement using branch probabilities and block frequency
/// information.
FunctionPass *createMachineBlockPlacementStatsPass();
/// Code Placement Pass - This pass optimize code placement and aligns loop
/// headers to target specific alignment boundary.
FunctionPass *createCodePlacementOptPass();
/// 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();
/// createMachineCopyPropagationPass - This pass performs copy propagation on
/// machine instructions.
FunctionPass *createMachineCopyPropagationPass();
/// createPeepholeOptimizerPass - This pass performs peephole optimizations -
/// like extension and comparison eliminations.
FunctionPass *createPeepholeOptimizerPass();
/// 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.
FunctionPass *createMachineVerifierPass(const char *Banner = 0);
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 TargetMachine *tm);
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);
/// createLocalStackSlotAllocationPass - This pass assigns local frame
/// indices to stack slots relative to one another and allocates
/// base registers to access them when it is estimated by the target to
/// be out of range of normal frame pointer or stack pointer index
/// addressing.
FunctionPass *createLocalStackSlotAllocationPass();
/// createExpandISelPseudosPass - This pass expands pseudo-instructions.
///
FunctionPass *createExpandISelPseudosPass();
/// createExecutionDependencyFixPass - This pass fixes execution time
/// problems with dependent instructions, such as switching execution
/// domains to match.
///
/// The pass will examine instructions using and defining registers in RC.
///
FunctionPass *createExecutionDependencyFixPass(const TargetRegisterClass *RC);
/// createUnpackMachineBundles - This pass unpack machine instruction bundles.
///
FunctionPass *createUnpackMachineBundlesPass();
/// createFinalizeMachineBundles - This pass finalize machine instruction
/// bundles (created earlier, e.g. during pre-RA scheduling).
///
FunctionPass *createFinalizeMachineBundlesPass();
} // End llvm namespace
#endif