mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-11-01 00:11:00 +00:00
1d9ab25560
various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
58 lines
2.1 KiB
C++
58 lines
2.1 KiB
C++
//===- Passes.h - Parsing, selection, and running of passes -----*- C++ -*-===//
|
|
//
|
|
// The LLVM Compiler Infrastructure
|
|
//
|
|
// This file is distributed under the University of Illinois Open Source
|
|
// License. See LICENSE.TXT for details.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
/// \file
|
|
///
|
|
/// Interfaces for producing common pass manager configurations and parsing
|
|
/// textual pass specifications.
|
|
///
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef LLVM_TOOLS_OPT_PASSES_H
|
|
#define LLVM_TOOLS_OPT_PASSES_H
|
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
namespace llvm {
|
|
class ModulePassManager;
|
|
|
|
/// \brief Parse a textual pass pipeline description into a \c ModulePassManager.
|
|
///
|
|
/// The format of the textual pass pipeline description looks something like:
|
|
///
|
|
/// module(function(instcombine,sroa),dce,cgscc(inliner,function(...)),...)
|
|
///
|
|
/// Pass managers have ()s describing the nest structure of passes. All passes
|
|
/// are comma separated. As a special shortcut, if the very first pass is not
|
|
/// a module pass (as a module pass manager is), this will automatically form
|
|
/// the shortest stack of pass managers that allow inserting that first pass.
|
|
/// So, assuming function passes 'fpassN', CGSCC passes 'cgpassN', and loop passes
|
|
/// 'lpassN', all of these are valid:
|
|
///
|
|
/// fpass1,fpass2,fpass3
|
|
/// cgpass1,cgpass2,cgpass3
|
|
/// lpass1,lpass2,lpass3
|
|
///
|
|
/// And they are equivalent to the following (resp.):
|
|
///
|
|
/// module(function(fpass1,fpass2,fpass3))
|
|
/// module(cgscc(cgpass1,cgpass2,cgpass3))
|
|
/// module(function(loop(lpass1,lpass2,lpass3)))
|
|
///
|
|
/// This shortcut is especially useful for debugging and testing small pass
|
|
/// combinations. Note that these shortcuts don't introduce any other magic. If
|
|
/// the sequence of passes aren't all the exact same kind of pass, it will be
|
|
/// an error. You cannot mix different levels implicitly, you must explicitly
|
|
/// form a pass manager in which to nest passes.
|
|
bool parsePassPipeline(ModulePassManager &MPM, StringRef PipelineText,
|
|
bool VerifyEachPass = true);
|
|
|
|
}
|
|
|
|
#endif
|