From isanbard at gmail.com Mon Mar 2 01:42:15 2009 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 02 Mar 2009 07:42:15 -0000 Subject: [llvm-commits] [llvm] r65813 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903020742.n227gFbk025952@zion.cs.uiuc.edu> Author: void Date: Mon Mar 2 01:42:15 2009 New Revision: 65813 URL: http://llvm.org/viewvc/llvm-project?rev=65813&view=rev Log: Fix typos. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65813&r1=65812&r2=65813&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 01:42:15 2009 @@ -235,7 +235,7 @@

LDC is an implementation of the D Programming Language using the LLVM optimizer and code generator. -LDC project works great with the LLVM 2.5 release. General improvmenets in this +LDC project works great with the LLVM 2.5 release. General improvements in this cycle have included new inline asm constraint handling, better debug info support, general bugfixes, and better x86-64 support. This has allowed some major improvements in LDC, getting us much closer to being as @@ -283,7 +283,7 @@

  • LLVM 2.5 includes a brand new XCore backend.
  • -
  • llvm-gcc now generally supports the GFortan front-end, and the precompiled +
  • llvm-gcc now generally supports the GFortran front-end, and the precompiled release binaries now support Fortran, even on Mac OS/X.
  • CMake is now used by the LLVM build process From isanbard at gmail.com Mon Mar 2 01:54:15 2009 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 02 Mar 2009 07:54:15 -0000 Subject: [llvm-commits] [llvm] r65815 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903020754.n227sFSn026341@zion.cs.uiuc.edu> Author: void Date: Mon Mar 2 01:54:14 2009 New Revision: 65815 URL: http://llvm.org/viewvc/llvm-project?rev=65815&view=rev Log: Random formatting changes. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65815&r1=65814&r2=65815&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 01:54:14 2009 @@ -470,37 +470,39 @@

    - @@ -518,15 +520,16 @@ types.
  • Function calls involving basic types work now.
  • Support for integer arrays.
  • -
  • Compiler can now emit libcalls for operations not support by m/c insns.
  • -
  • Support for both data and rom address spaces.
  • +
  • Compiler can now emit libcalls for operations not support by m/c +instructions.
  • +
  • Support for both data and ROM address spaces.
  • Things not yet supported:

    - - @@ -675,8 +675,8 @@ From foldr at codedgers.com Mon Mar 2 03:01:14 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:01:14 -0000 Subject: [llvm-commits] [llvm] r65821 - in /llvm/trunk: include/llvm/CompilerDriver/ lib/ lib/CompilerDriver/ tools/llvmc/ tools/llvmc/driver/ tools/llvmc/plugins/ tools/llvmc/plugins/Base/ tools/llvmc/plugins/Clang/ tools/llvmc/plugins/Hello/ tools/llvmc/plugins/Simple/ Message-ID: <200903020901.n2291FVT003122@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:01:14 2009 New Revision: 65821 URL: http://llvm.org/viewvc/llvm-project?rev=65821&view=rev Log: Reorganize llvmc code. Move the code from 'llvmc/driver' into a new CompilerDriver library, and change the build system accordingly. Makes it easier for projects using LLVM to build their own llvmc-based drivers. Tested with objdir != srcdir. Added: llvm/trunk/include/llvm/CompilerDriver/Error.h - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/Error.h llvm/trunk/lib/CompilerDriver/ llvm/trunk/lib/CompilerDriver/Action.cpp - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/Action.cpp llvm/trunk/lib/CompilerDriver/CMakeLists.txt - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/CMakeLists.txt llvm/trunk/lib/CompilerDriver/CompilationGraph.cpp - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp llvm/trunk/lib/CompilerDriver/Makefile - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/Makefile llvm/trunk/lib/CompilerDriver/Plugin.cpp - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/Plugin.cpp llvm/trunk/lib/CompilerDriver/Tool.cpp - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/Tool.cpp llvm/trunk/tools/llvmc/Makefile.llvmc - copied, changed from r65815, llvm/trunk/tools/llvmc/plugins/Makefile llvm/trunk/tools/llvmc/driver/Main.cpp - copied, changed from r65815, llvm/trunk/tools/llvmc/driver/llvmc.cpp Removed: llvm/trunk/tools/llvmc/driver/Action.cpp llvm/trunk/tools/llvmc/driver/CMakeLists.txt llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp llvm/trunk/tools/llvmc/driver/Error.h llvm/trunk/tools/llvmc/driver/Plugin.cpp llvm/trunk/tools/llvmc/driver/Tool.cpp llvm/trunk/tools/llvmc/driver/llvmc.cpp Modified: llvm/trunk/lib/Makefile llvm/trunk/tools/llvmc/CMakeLists.txt llvm/trunk/tools/llvmc/Makefile llvm/trunk/tools/llvmc/driver/Makefile llvm/trunk/tools/llvmc/plugins/Base/Makefile llvm/trunk/tools/llvmc/plugins/Clang/Makefile llvm/trunk/tools/llvmc/plugins/Hello/Makefile llvm/trunk/tools/llvmc/plugins/Makefile llvm/trunk/tools/llvmc/plugins/Simple/Makefile Copied: llvm/trunk/include/llvm/CompilerDriver/Error.h (from r65815, llvm/trunk/tools/llvmc/driver/Error.h) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Error.h?p2=llvm/trunk/include/llvm/CompilerDriver/Error.h&p1=llvm/trunk/tools/llvmc/driver/Error.h&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== (empty) Copied: llvm/trunk/lib/CompilerDriver/Action.cpp (from r65815, llvm/trunk/tools/llvmc/driver/Action.cpp) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CompilerDriver/Action.cpp?p2=llvm/trunk/lib/CompilerDriver/Action.cpp&p1=llvm/trunk/tools/llvmc/driver/Action.cpp&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== (empty) Copied: llvm/trunk/lib/CompilerDriver/CMakeLists.txt (from r65815, llvm/trunk/tools/llvmc/driver/CMakeLists.txt) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CompilerDriver/CMakeLists.txt?p2=llvm/trunk/lib/CompilerDriver/CMakeLists.txt&p1=llvm/trunk/tools/llvmc/driver/CMakeLists.txt&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== (empty) Copied: llvm/trunk/lib/CompilerDriver/CompilationGraph.cpp (from r65815, llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CompilerDriver/CompilationGraph.cpp?p2=llvm/trunk/lib/CompilerDriver/CompilationGraph.cpp&p1=llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp (original) +++ llvm/trunk/lib/CompilerDriver/CompilationGraph.cpp Mon Mar 2 03:01:14 2009 @@ -11,8 +11,8 @@ // //===----------------------------------------------------------------------===// -#include "Error.h" #include "llvm/CompilerDriver/CompilationGraph.h" +#include "llvm/CompilerDriver/Error.h" #include "llvm/ADT/STLExtras.h" #include "llvm/Support/CommandLine.h" Copied: llvm/trunk/lib/CompilerDriver/Makefile (from r65815, llvm/trunk/tools/llvmc/driver/Makefile) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CompilerDriver/Makefile?p2=llvm/trunk/lib/CompilerDriver/Makefile&p1=llvm/trunk/tools/llvmc/driver/Makefile&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/driver/Makefile (original) +++ llvm/trunk/lib/CompilerDriver/Makefile Mon Mar 2 03:01:14 2009 @@ -1,4 +1,4 @@ -##===- tools/llvmc/driver/Makefile -------------------------*- Makefile -*-===## +##===- lib/CompilerDriver/Makefile -------------------------*- Makefile -*-===## # # The LLVM Compiler Infrastructure # @@ -7,13 +7,13 @@ # ##===----------------------------------------------------------------------===## -LEVEL = ../../.. -TOOLNAME = $(DRIVER_NAME) +LEVEL = ../.. + +# We don't want this library to appear in `llvm-config --libs` output, so its +# name doesn't start with "LLVM". + +LIBRARYNAME = CompilerDriver LINK_COMPONENTS = support system REQUIRES_EH := 1 -ifneq ($(BUILTIN_PLUGINS),) -USEDLIBS = $(patsubst %,plugin_llvmc_%,$(BUILTIN_PLUGINS)) -endif - include $(LEVEL)/Makefile.common Copied: llvm/trunk/lib/CompilerDriver/Plugin.cpp (from r65815, llvm/trunk/tools/llvmc/driver/Plugin.cpp) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CompilerDriver/Plugin.cpp?p2=llvm/trunk/lib/CompilerDriver/Plugin.cpp&p1=llvm/trunk/tools/llvmc/driver/Plugin.cpp&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== (empty) Copied: llvm/trunk/lib/CompilerDriver/Tool.cpp (from r65815, llvm/trunk/tools/llvmc/driver/Tool.cpp) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CompilerDriver/Tool.cpp?p2=llvm/trunk/lib/CompilerDriver/Tool.cpp&p1=llvm/trunk/tools/llvmc/driver/Tool.cpp&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== (empty) Modified: llvm/trunk/lib/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/lib/Makefile (original) +++ llvm/trunk/lib/Makefile Mon Mar 2 03:01:14 2009 @@ -9,7 +9,7 @@ LEVEL = .. PARALLEL_DIRS = VMCore AsmParser Bitcode Archive Analysis Transforms CodeGen \ - Target ExecutionEngine Debugger Linker + Target ExecutionEngine Debugger Linker CompilerDriver include $(LEVEL)/Makefile.common Modified: llvm/trunk/tools/llvmc/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/CMakeLists.txt?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/CMakeLists.txt (original) +++ llvm/trunk/tools/llvmc/CMakeLists.txt Mon Mar 2 03:01:14 2009 @@ -1,4 +1,4 @@ -add_subdirectory(driver) +# add_subdirectory(driver) # TODO: support plugins and user-configured builds. # See ./doc/LLVMC-Reference.rst "Customizing LLVMC: the compilation graph" Modified: llvm/trunk/tools/llvmc/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/Makefile (original) +++ llvm/trunk/tools/llvmc/Makefile Mon Mar 2 03:01:14 2009 @@ -9,11 +9,12 @@ LEVEL = ../.. -BUILTIN_PLUGINS = Base Clang -DRIVER_NAME = llvmc -DIRS = plugins driver +# The current plan is to make the user copy the skeleton project and change only +# this file (and plugins/UserPlugin, of course). + +export LLVMC_BASED_DRIVER_NAME = llvmc +export LLVMC_BUILTIN_PLUGINS = Base Clang -export BUILTIN_PLUGINS -export DRIVER_NAME +DIRS = plugins driver include $(LEVEL)/Makefile.common Copied: llvm/trunk/tools/llvmc/Makefile.llvmc (from r65815, llvm/trunk/tools/llvmc/plugins/Makefile) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/Makefile.llvmc?p2=llvm/trunk/tools/llvmc/Makefile.llvmc&p1=llvm/trunk/tools/llvmc/plugins/Makefile&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Makefile (original) +++ llvm/trunk/tools/llvmc/Makefile.llvmc Mon Mar 2 03:01:14 2009 @@ -1,4 +1,4 @@ -##===- tools/llvmc/plugins/Makefile.plugins ----------------*- Makefile -*-===## +##===- tools/llvmc/Makefile.llvmc --------------------------*- Makefile -*-===## # # The LLVM Compiler Infrastructure # @@ -7,35 +7,29 @@ # ##===----------------------------------------------------------------------===## -ifndef LLVMC_PLUGIN +# TODO: This must be eventually merged into Makefile.rules. -LEVEL = ../../.. -DIRS = $(BUILTIN_PLUGINS) +ifdef LLVMC_PLUGIN -# TOFIX: Should we also build DSO versions of plugins? -export BUILTIN_LLVMC_PLUGIN=1 - -include $(LEVEL)/Makefile.common - -else # LLVMC_PLUGIN +# We are included from plugins/PluginName/Makefile... LEVEL = ../../../.. LIBRARYNAME := $(patsubst %,plugin_llvmc_%,$(LLVMC_PLUGIN)) -REQUIRES_EH = 1 +REQUIRES_EH := 1 -ifndef BUILTIN_LLVMC_PLUGIN +# Build a dynamic library if the user runs `make` from plugins/PluginName +ifndef LLVMC_BUILTIN_PLUGIN LOADABLE_MODULE = 1 endif +# TableGen stuff... ifneq ($(BUILT_SOURCES),) BUILD_AUTOGENERATED_INC=1 endif include $(LEVEL)/Makefile.common -# TOFIX: This probably should go into Makefile.rules - ifdef BUILD_AUTOGENERATED_INC TOOLS_SOURCE := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) Removed: llvm/trunk/tools/llvmc/driver/Action.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/Action.cpp?rev=65820&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/driver/Action.cpp (original) +++ llvm/trunk/tools/llvmc/driver/Action.cpp (removed) @@ -1,78 +0,0 @@ -//===--- Action.cpp - The LLVM Compiler Driver ------------------*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open -// Source License. See LICENSE.TXT for details. -// -//===----------------------------------------------------------------------===// -// -// Action class - implementation and auxiliary functions. -// -//===----------------------------------------------------------------------===// - -#include "llvm/CompilerDriver/Action.h" - -#include "llvm/Support/CommandLine.h" -#include "llvm/System/Program.h" - -#include -#include - -using namespace llvm; -using namespace llvmc; - -extern cl::opt DryRun; -extern cl::opt VerboseMode; - -namespace { - int ExecuteProgram(const std::string& name, - const StrVector& args) { - sys::Path prog = sys::Program::FindProgramByName(name); - - if (prog.isEmpty()) - throw std::runtime_error("Can't find program '" + name + "'"); - if (!prog.canExecute()) - throw std::runtime_error("Program '" + name + "' is not executable."); - - // Build the command line vector and the redirects array. - const sys::Path* redirects[3] = {0,0,0}; - sys::Path stdout_redirect; - - std::vector argv; - argv.reserve((args.size()+2)); - argv.push_back(name.c_str()); - - for (StrVector::const_iterator B = args.begin(), E = args.end(); - B!=E; ++B) { - if (*B == ">") { - ++B; - stdout_redirect.set(*B); - redirects[1] = &stdout_redirect; - } - else { - argv.push_back((*B).c_str()); - } - } - argv.push_back(0); // null terminate list. - - // Invoke the program. - return sys::Program::ExecuteAndWait(prog, &argv[0], 0, &redirects[0]); - } - - void print_string (const std::string& str) { - std::cerr << str << ' '; - } -} - -int llvmc::Action::Execute() const { - if (DryRun || VerboseMode) { - std::cerr << Command_ << " "; - std::for_each(Args_.begin(), Args_.end(), print_string); - std::cerr << '\n'; - } - if (DryRun) - return 0; - else - return ExecuteProgram(Command_, Args_); -} Removed: llvm/trunk/tools/llvmc/driver/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/CMakeLists.txt?rev=65820&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/driver/CMakeLists.txt (original) +++ llvm/trunk/tools/llvmc/driver/CMakeLists.txt (removed) @@ -1,10 +0,0 @@ -set(LLVM_LINK_COMPONENTS support system) -set(LLVM_REQUIRES_EH 1) - -add_llvm_tool(llvmc - Action.cpp - CompilationGraph.cpp - llvmc.cpp - Plugin.cpp - Tool.cpp - ) Removed: llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp?rev=65820&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp (original) +++ llvm/trunk/tools/llvmc/driver/CompilationGraph.cpp (removed) @@ -1,534 +0,0 @@ -//===--- CompilationGraph.cpp - The LLVM Compiler Driver --------*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open -// Source License. See LICENSE.TXT for details. -// -//===----------------------------------------------------------------------===// -// -// Compilation graph - implementation. -// -//===----------------------------------------------------------------------===// - -#include "Error.h" -#include "llvm/CompilerDriver/CompilationGraph.h" - -#include "llvm/ADT/STLExtras.h" -#include "llvm/Support/CommandLine.h" -#include "llvm/Support/DOTGraphTraits.h" -#include "llvm/Support/GraphWriter.h" - -#include -#include -#include -#include -#include -#include -#include - -using namespace llvm; -using namespace llvmc; - -extern cl::list InputFilenames; -extern cl::list Languages; - -namespace llvmc { - - const std::string& LanguageMap::GetLanguage(const sys::Path& File) const { - LanguageMap::const_iterator Lang = this->find(File.getSuffix()); - if (Lang == this->end()) - throw std::runtime_error("Unknown suffix: " + File.getSuffix()); - return Lang->second; - } -} - -namespace { - - /// ChooseEdge - Return the edge with the maximum weight. - template - const Edge* ChooseEdge(const C& EdgesContainer, - const InputLanguagesSet& InLangs, - const std::string& NodeName = "root") { - const Edge* MaxEdge = 0; - unsigned MaxWeight = 0; - bool SingleMax = true; - - for (typename C::const_iterator B = EdgesContainer.begin(), - E = EdgesContainer.end(); B != E; ++B) { - const Edge* e = B->getPtr(); - unsigned EW = e->Weight(InLangs); - if (EW > MaxWeight) { - MaxEdge = e; - MaxWeight = EW; - SingleMax = true; - } else if (EW == MaxWeight) { - SingleMax = false; - } - } - - if (!SingleMax) - throw std::runtime_error("Node " + NodeName + - ": multiple maximal outward edges found!" - " Most probably a specification error."); - if (!MaxEdge) - throw std::runtime_error("Node " + NodeName + - ": no maximal outward edge found!" - " Most probably a specification error."); - return MaxEdge; - } - -} - -void Node::AddEdge(Edge* Edg) { - // If there already was an edge between two nodes, modify it instead - // of adding a new edge. - const std::string& ToolName = Edg->ToolName(); - for (container_type::iterator B = OutEdges.begin(), E = OutEdges.end(); - B != E; ++B) { - if ((*B)->ToolName() == ToolName) { - llvm::IntrusiveRefCntPtr(Edg).swap(*B); - return; - } - } - OutEdges.push_back(llvm::IntrusiveRefCntPtr(Edg)); -} - -CompilationGraph::CompilationGraph() { - NodesMap["root"] = Node(this); -} - -Node& CompilationGraph::getNode(const std::string& ToolName) { - nodes_map_type::iterator I = NodesMap.find(ToolName); - if (I == NodesMap.end()) - throw std::runtime_error("Node " + ToolName + " is not in the graph"); - return I->second; -} - -const Node& CompilationGraph::getNode(const std::string& ToolName) const { - nodes_map_type::const_iterator I = NodesMap.find(ToolName); - if (I == NodesMap.end()) - throw std::runtime_error("Node " + ToolName + " is not in the graph!"); - return I->second; -} - -// Find the tools list corresponding to the given language name. -const CompilationGraph::tools_vector_type& -CompilationGraph::getToolsVector(const std::string& LangName) const -{ - tools_map_type::const_iterator I = ToolsMap.find(LangName); - if (I == ToolsMap.end()) - throw std::runtime_error("No tool corresponding to the language " - + LangName + " found"); - return I->second; -} - -void CompilationGraph::insertNode(Tool* V) { - if (NodesMap.count(V->Name()) == 0) - NodesMap[V->Name()] = Node(this, V); -} - -void CompilationGraph::insertEdge(const std::string& A, Edge* Edg) { - Node& B = getNode(Edg->ToolName()); - if (A == "root") { - const char** InLangs = B.ToolPtr->InputLanguages(); - for (;*InLangs; ++InLangs) - ToolsMap[*InLangs].push_back(IntrusiveRefCntPtr(Edg)); - NodesMap["root"].AddEdge(Edg); - } - else { - Node& N = getNode(A); - N.AddEdge(Edg); - } - // Increase the inward edge counter. - B.IncrInEdges(); -} - -// Pass input file through the chain until we bump into a Join node or -// a node that says that it is the last. -void CompilationGraph::PassThroughGraph (const sys::Path& InFile, - const Node* StartNode, - const InputLanguagesSet& InLangs, - const sys::Path& TempDir, - const LanguageMap& LangMap) const { - sys::Path In = InFile; - const Node* CurNode = StartNode; - - while(true) { - Tool* CurTool = CurNode->ToolPtr.getPtr(); - - if (CurTool->IsJoin()) { - JoinTool& JT = dynamic_cast(*CurTool); - JT.AddToJoinList(In); - break; - } - - Action CurAction = CurTool->GenerateAction(In, CurNode->HasChildren(), - TempDir, InLangs, LangMap); - - if (int ret = CurAction.Execute()) - throw error_code(ret); - - if (CurAction.StopCompilation()) - return; - - CurNode = &getNode(ChooseEdge(CurNode->OutEdges, - InLangs, - CurNode->Name())->ToolName()); - In = CurAction.OutFile(); - } -} - -// Find the head of the toolchain corresponding to the given file. -// Also, insert an input language into InLangs. -const Node* CompilationGraph:: -FindToolChain(const sys::Path& In, const std::string* ForceLanguage, - InputLanguagesSet& InLangs, const LanguageMap& LangMap) const { - - // Determine the input language. - const std::string& InLanguage = - ForceLanguage ? *ForceLanguage : LangMap.GetLanguage(In); - - // Add the current input language to the input language set. - InLangs.insert(InLanguage); - - // Find the toolchain for the input language. - const tools_vector_type& TV = getToolsVector(InLanguage); - if (TV.empty()) - throw std::runtime_error("No toolchain corresponding to language " - + InLanguage + " found"); - return &getNode(ChooseEdge(TV, InLangs)->ToolName()); -} - -// Helper function used by Build(). -// Traverses initial portions of the toolchains (up to the first Join node). -// This function is also responsible for handling the -x option. -void CompilationGraph::BuildInitial (InputLanguagesSet& InLangs, - const sys::Path& TempDir, - const LanguageMap& LangMap) { - // This is related to -x option handling. - cl::list::const_iterator xIter = Languages.begin(), - xBegin = xIter, xEnd = Languages.end(); - bool xEmpty = true; - const std::string* xLanguage = 0; - unsigned xPos = 0, xPosNext = 0, filePos = 0; - - if (xIter != xEnd) { - xEmpty = false; - xPos = Languages.getPosition(xIter - xBegin); - cl::list::const_iterator xNext = llvm::next(xIter); - xPosNext = (xNext == xEnd) ? std::numeric_limits::max() - : Languages.getPosition(xNext - xBegin); - xLanguage = (*xIter == "none") ? 0 : &(*xIter); - } - - // For each input file: - for (cl::list::const_iterator B = InputFilenames.begin(), - CB = B, E = InputFilenames.end(); B != E; ++B) { - sys::Path In = sys::Path(*B); - - // Code for handling the -x option. - // Output: std::string* xLanguage (can be NULL). - if (!xEmpty) { - filePos = InputFilenames.getPosition(B - CB); - - if (xPos < filePos) { - if (filePos < xPosNext) { - xLanguage = (*xIter == "none") ? 0 : &(*xIter); - } - else { // filePos >= xPosNext - // Skip xIters while filePos > xPosNext - while (filePos > xPosNext) { - ++xIter; - xPos = xPosNext; - - cl::list::const_iterator xNext = llvm::next(xIter); - if (xNext == xEnd) - xPosNext = std::numeric_limits::max(); - else - xPosNext = Languages.getPosition(xNext - xBegin); - xLanguage = (*xIter == "none") ? 0 : &(*xIter); - } - } - } - } - - // Find the toolchain corresponding to this file. - const Node* N = FindToolChain(In, xLanguage, InLangs, LangMap); - // Pass file through the chain starting at head. - PassThroughGraph(In, N, InLangs, TempDir, LangMap); - } -} - -// Sort the nodes in topological order. -void CompilationGraph::TopologicalSort(std::vector& Out) { - std::queue Q; - Q.push(&getNode("root")); - - while (!Q.empty()) { - const Node* A = Q.front(); - Q.pop(); - Out.push_back(A); - for (Node::const_iterator EB = A->EdgesBegin(), EE = A->EdgesEnd(); - EB != EE; ++EB) { - Node* B = &getNode((*EB)->ToolName()); - B->DecrInEdges(); - if (B->HasNoInEdges()) - Q.push(B); - } - } -} - -namespace { - bool NotJoinNode(const Node* N) { - return N->ToolPtr ? !N->ToolPtr->IsJoin() : true; - } -} - -// Call TopologicalSort and filter the resulting list to include -// only Join nodes. -void CompilationGraph:: -TopologicalSortFilterJoinNodes(std::vector& Out) { - std::vector TopSorted; - TopologicalSort(TopSorted); - std::remove_copy_if(TopSorted.begin(), TopSorted.end(), - std::back_inserter(Out), NotJoinNode); -} - -int CompilationGraph::Build (const sys::Path& TempDir, - const LanguageMap& LangMap) { - - InputLanguagesSet InLangs; - - // Traverse initial parts of the toolchains and fill in InLangs. - BuildInitial(InLangs, TempDir, LangMap); - - std::vector JTV; - TopologicalSortFilterJoinNodes(JTV); - - // For all join nodes in topological order: - for (std::vector::iterator B = JTV.begin(), E = JTV.end(); - B != E; ++B) { - - const Node* CurNode = *B; - JoinTool* JT = &dynamic_cast(*CurNode->ToolPtr.getPtr()); - - // Are there any files in the join list? - if (JT->JoinListEmpty()) - continue; - - Action CurAction = JT->GenerateAction(CurNode->HasChildren(), - TempDir, InLangs, LangMap); - - if (int ret = CurAction.Execute()) - throw error_code(ret); - - if (CurAction.StopCompilation()) - return 0; - - const Node* NextNode = &getNode(ChooseEdge(CurNode->OutEdges, InLangs, - CurNode->Name())->ToolName()); - PassThroughGraph(sys::Path(CurAction.OutFile()), NextNode, - InLangs, TempDir, LangMap); - } - - return 0; -} - -int CompilationGraph::CheckLanguageNames() const { - int ret = 0; - // Check that names for output and input languages on all edges do match. - for (const_nodes_iterator B = this->NodesMap.begin(), - E = this->NodesMap.end(); B != E; ++B) { - - const Node & N1 = B->second; - if (N1.ToolPtr) { - for (Node::const_iterator EB = N1.EdgesBegin(), EE = N1.EdgesEnd(); - EB != EE; ++EB) { - const Node& N2 = this->getNode((*EB)->ToolName()); - - if (!N2.ToolPtr) { - ++ret; - std::cerr << "Error: there is an edge from '" << N1.ToolPtr->Name() - << "' back to the root!\n\n"; - continue; - } - - const char* OutLang = N1.ToolPtr->OutputLanguage(); - const char** InLangs = N2.ToolPtr->InputLanguages(); - bool eq = false; - for (;*InLangs; ++InLangs) { - if (std::strcmp(OutLang, *InLangs) == 0) { - eq = true; - break; - } - } - - if (!eq) { - ++ret; - std::cerr << "Error: Output->input language mismatch in the edge '" << - N1.ToolPtr->Name() << "' -> '" << N2.ToolPtr->Name() << "'!\n"; - - std::cerr << "Expected one of { "; - - InLangs = N2.ToolPtr->InputLanguages(); - for (;*InLangs; ++InLangs) { - std::cerr << '\'' << *InLangs << (*(InLangs+1) ? "', " : "'"); - } - - std::cerr << " }, but got '" << OutLang << "'!\n\n"; - } - - } - } - } - - return ret; -} - -int CompilationGraph::CheckMultipleDefaultEdges() const { - int ret = 0; - InputLanguagesSet Dummy; - - // For all nodes, just iterate over the outgoing edges and check if there is - // more than one edge with maximum weight. - for (const_nodes_iterator B = this->NodesMap.begin(), - E = this->NodesMap.end(); B != E; ++B) { - const Node& N = B->second; - unsigned MaxWeight = 0; - - // Ignore the root node. - if (!N.ToolPtr) - continue; - - for (Node::const_iterator EB = N.EdgesBegin(), EE = N.EdgesEnd(); - EB != EE; ++EB) { - unsigned EdgeWeight = (*EB)->Weight(Dummy); - if (EdgeWeight > MaxWeight) { - MaxWeight = EdgeWeight; - } - else if (EdgeWeight == MaxWeight) { - ++ret; - std::cerr - << "Error: there are multiple maximal edges stemming from the '" - << N.ToolPtr->Name() << "' node!\n\n"; - break; - } - } - } - - return ret; -} - -int CompilationGraph::CheckCycles() { - unsigned deleted = 0; - std::queue Q; - Q.push(&getNode("root")); - - // Try to delete all nodes that have no ingoing edges, starting from the - // root. If there are any nodes left after this operation, then we have a - // cycle. This relies on '--check-graph' not performing the topological sort. - while (!Q.empty()) { - Node* A = Q.front(); - Q.pop(); - ++deleted; - - for (Node::iterator EB = A->EdgesBegin(), EE = A->EdgesEnd(); - EB != EE; ++EB) { - Node* B = &getNode((*EB)->ToolName()); - B->DecrInEdges(); - if (B->HasNoInEdges()) - Q.push(B); - } - } - - if (deleted != NodesMap.size()) { - std::cerr << "Error: there are cycles in the compilation graph!\n" - << "Try inspecting the diagram produced by " - "'llvmc --view-graph'.\n\n"; - return 1; - } - - return 0; -} - -int CompilationGraph::Check () { - // We try to catch as many errors as we can in one go. - int ret = 0; - - // Check that output/input language names match. - ret += this->CheckLanguageNames(); - - // Check for multiple default edges. - ret += this->CheckMultipleDefaultEdges(); - - // Check for cycles. - ret += this->CheckCycles(); - - return ret; -} - -// Code related to graph visualization. - -namespace llvm { - template <> - struct DOTGraphTraits - : public DefaultDOTGraphTraits - { - - template - static std::string getNodeLabel(const Node* N, const GraphType&) - { - if (N->ToolPtr) - if (N->ToolPtr->IsJoin()) - return N->Name() + "\n (join" + - (N->HasChildren() ? ")" - : std::string(": ") + N->ToolPtr->OutputLanguage() + ')'); - else - return N->Name(); - else - return "root"; - } - - template - static std::string getEdgeSourceLabel(const Node* N, EdgeIter I) { - if (N->ToolPtr) { - return N->ToolPtr->OutputLanguage(); - } - else { - const char** InLangs = I->ToolPtr->InputLanguages(); - std::string ret; - - for (; *InLangs; ++InLangs) { - if (*(InLangs + 1)) { - ret += *InLangs; - ret += ", "; - } - else { - ret += *InLangs; - } - } - - return ret; - } - } - }; - -} - -void CompilationGraph::writeGraph() { - std::ofstream O("compilation-graph.dot"); - - if (O.good()) { - llvm::WriteGraph(this, "compilation-graph"); - O.close(); - } - else { - throw std::runtime_error("Error opening file 'compilation-graph.dot'" - " for writing!"); - } -} - -void CompilationGraph::viewGraph() { - llvm::ViewGraph(this, "compilation-graph"); -} Removed: llvm/trunk/tools/llvmc/driver/Error.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/Error.h?rev=65820&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/driver/Error.h (original) +++ llvm/trunk/tools/llvmc/driver/Error.h (removed) @@ -1,33 +0,0 @@ -//===--- Error.h - The LLVM Compiler Driver ---------------------*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open -// Source License. See LICENSE.TXT for details. -// -//===----------------------------------------------------------------------===// -// -// Exception classes for LLVMC. -// -//===----------------------------------------------------------------------===// - -#ifndef LLVM_TOOLS_LLVMC2_ERROR_H -#define LLVM_TOOLS_LLVMC2_ERROR_H - -#include - -namespace llvmc { - - class error_code: public std::runtime_error { - int Code_; - public: - error_code (int c) - : std::runtime_error("Tool returned error code"), Code_(c) - {} - - int code() const { return Code_; } - }; - -} - -#endif //LLVM_TOOLS_LLVMC2_ERROR_H Copied: llvm/trunk/tools/llvmc/driver/Main.cpp (from r65815, llvm/trunk/tools/llvmc/driver/llvmc.cpp) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/Main.cpp?p2=llvm/trunk/tools/llvmc/driver/Main.cpp&p1=llvm/trunk/tools/llvmc/driver/llvmc.cpp&r1=65815&r2=65821&rev=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/driver/llvmc.cpp (original) +++ llvm/trunk/tools/llvmc/driver/Main.cpp Mon Mar 2 03:01:14 2009 @@ -1,4 +1,4 @@ -//===--- llvmc.cpp - The LLVM Compiler Driver -------------------*- C++ -*-===// +//===--- Main.cpp - The LLVM Compiler Driver -------------------*- C++ -*-===// // // The LLVM Compiler Infrastructure // @@ -14,9 +14,8 @@ // //===----------------------------------------------------------------------===// -#include "Error.h" - #include "llvm/CompilerDriver/CompilationGraph.h" +#include "llvm/CompilerDriver/Error.h" #include "llvm/CompilerDriver/Plugin.h" #include "llvm/System/Path.h" Modified: llvm/trunk/tools/llvmc/driver/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/driver/Makefile (original) +++ llvm/trunk/tools/llvmc/driver/Makefile Mon Mar 2 03:01:14 2009 @@ -8,12 +8,15 @@ ##===----------------------------------------------------------------------===## LEVEL = ../../.. -TOOLNAME = $(DRIVER_NAME) -LINK_COMPONENTS = support system -REQUIRES_EH := 1 -ifneq ($(BUILTIN_PLUGINS),) -USEDLIBS = $(patsubst %,plugin_llvmc_%,$(BUILTIN_PLUGINS)) +TOOLNAME = $(LLVMC_BASED_DRIVER_NAME) +USEDLIBS = CompilerDriver + +ifneq ($(LLVMC_BUILTIN_PLUGINS),) +USEDLIBS += $(patsubst %,plugin_llvmc_%,$(LLVMC_BUILTIN_PLUGINS)) endif +LINK_COMPONENTS = support system +REQUIRES_EH := 1 + include $(LEVEL)/Makefile.common Removed: llvm/trunk/tools/llvmc/driver/Plugin.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/Plugin.cpp?rev=65820&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/driver/Plugin.cpp (original) +++ llvm/trunk/tools/llvmc/driver/Plugin.cpp (removed) @@ -1,73 +0,0 @@ -//===--- Plugin.cpp - The LLVM Compiler Driver ------------------*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open -// Source License. See LICENSE.TXT for details. -// -//===----------------------------------------------------------------------===// -// -// Plugin support. -// -//===----------------------------------------------------------------------===// - -#include "llvm/CompilerDriver/Plugin.h" - -#include -#include - -namespace { - - // Registry::Add<> does not do lifetime management (probably issues - // with static constructor/destructor ordering), so we have to - // implement it here. - // - // All this static registration/life-before-main model seems - // unnecessary convoluted to me. - - static bool pluginListInitialized = false; - typedef std::vector PluginList; - static PluginList Plugins; - - struct ByPriority { - bool operator()(const llvmc::BasePlugin* lhs, - const llvmc::BasePlugin* rhs) { - return lhs->Priority() < rhs->Priority(); - } - }; -} - -namespace llvmc { - - PluginLoader::PluginLoader() { - if (!pluginListInitialized) { - for (PluginRegistry::iterator B = PluginRegistry::begin(), - E = PluginRegistry::end(); B != E; ++B) - Plugins.push_back(B->instantiate()); - std::sort(Plugins.begin(), Plugins.end(), ByPriority()); - } - pluginListInitialized = true; - } - - PluginLoader::~PluginLoader() { - if (pluginListInitialized) { - for (PluginList::iterator B = Plugins.begin(), E = Plugins.end(); - B != E; ++B) - delete (*B); - } - pluginListInitialized = false; - } - - void PluginLoader::PopulateLanguageMap(LanguageMap& langMap) { - for (PluginList::iterator B = Plugins.begin(), E = Plugins.end(); - B != E; ++B) - (*B)->PopulateLanguageMap(langMap); - } - - void PluginLoader::PopulateCompilationGraph(CompilationGraph& graph) { - for (PluginList::iterator B = Plugins.begin(), E = Plugins.end(); - B != E; ++B) - (*B)->PopulateCompilationGraph(graph); - } - -} Removed: llvm/trunk/tools/llvmc/driver/Tool.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/Tool.cpp?rev=65820&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/driver/Tool.cpp (original) +++ llvm/trunk/tools/llvmc/driver/Tool.cpp (removed) @@ -1,74 +0,0 @@ -//===--- Tool.cpp - The LLVM Compiler Driver --------------------*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open -// Source License. See LICENSE.TXT for details. -// -//===----------------------------------------------------------------------===// -// -// Tool base class - implementation details. -// -//===----------------------------------------------------------------------===// - -#include "llvm/CompilerDriver/Tool.h" - -#include "llvm/System/Path.h" -#include "llvm/Support/CommandLine.h" - -using namespace llvm; -using namespace llvmc; - -extern cl::opt OutputFilename; - -namespace { - sys::Path MakeTempFile(const sys::Path& TempDir, const std::string& BaseName, - const std::string& Suffix) { - sys::Path Out; - - // Make sure we don't end up with path names like '/file.o' if the - // TempDir is empty. - if (TempDir.empty()) { - Out.set(BaseName); - } - else { - Out = TempDir; - Out.appendComponent(BaseName); - } - Out.appendSuffix(Suffix); - // NOTE: makeUnique always *creates* a unique temporary file, - // which is good, since there will be no races. However, some - // tools do not like it when the output file already exists, so - // they have to be placated with -f or something like that. - Out.makeUnique(true, NULL); - return Out; - } -} - -sys::Path Tool::OutFilename(const sys::Path& In, - const sys::Path& TempDir, - bool StopCompilation, - const char* OutputSuffix) const { - sys::Path Out; - - if (StopCompilation) { - if (!OutputFilename.empty()) { - Out.set(OutputFilename); - } - else if (IsJoin()) { - Out.set("a"); - Out.appendSuffix(OutputSuffix); - } - else { - Out.set(In.getBasename()); - Out.appendSuffix(OutputSuffix); - } - } - else { - if (IsJoin()) - Out = MakeTempFile(TempDir, "tmp", OutputSuffix); - else - Out = MakeTempFile(TempDir, In.getBasename(), OutputSuffix); - } - return Out; -} Removed: llvm/trunk/tools/llvmc/driver/llvmc.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/llvmc.cpp?rev=65820&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/driver/llvmc.cpp (original) +++ llvm/trunk/tools/llvmc/driver/llvmc.cpp (removed) @@ -1,127 +0,0 @@ -//===--- llvmc.cpp - The LLVM Compiler Driver -------------------*- C++ -*-===// -// -// The LLVM Compiler Infrastructure -// -// This file is distributed under the University of Illinois Open -// Source License. See LICENSE.TXT for details. -// -//===----------------------------------------------------------------------===// -// -// This tool provides a single point of access to the LLVM -// compilation tools. It has many options. To discover the options -// supported please refer to the tools' manual page or run the tool -// with the --help option. -// -//===----------------------------------------------------------------------===// - -#include "Error.h" - -#include "llvm/CompilerDriver/CompilationGraph.h" -#include "llvm/CompilerDriver/Plugin.h" - -#include "llvm/System/Path.h" -#include "llvm/Support/CommandLine.h" -#include "llvm/Support/PluginLoader.h" - -#include -#include -#include - -namespace cl = llvm::cl; -namespace sys = llvm::sys; -using namespace llvmc; - -// Built-in command-line options. -// External linkage here is intentional. - -cl::list InputFilenames(cl::Positional, cl::desc(""), - cl::ZeroOrMore); -cl::opt OutputFilename("o", cl::desc("Output file name"), - cl::value_desc("file"), cl::Prefix); -cl::list Languages("x", - cl::desc("Specify the language of the following input files"), - cl::ZeroOrMore); -cl::opt DryRun("dry-run", - cl::desc("Only pretend to run commands")); -cl::opt VerboseMode("v", - cl::desc("Enable verbose mode")); - -cl::opt CheckGraph("check-graph", - cl::desc("Check the compilation graph for errors"), - cl::Hidden); -cl::opt WriteGraph("write-graph", - cl::desc("Write compilation-graph.dot file"), - cl::Hidden); -cl::opt ViewGraph("view-graph", - cl::desc("Show compilation graph in GhostView"), - cl::Hidden); -cl::opt SaveTemps("save-temps", - cl::desc("Keep temporary files"), - cl::Hidden); - -namespace { - /// BuildTargets - A small wrapper for CompilationGraph::Build. - int BuildTargets(CompilationGraph& graph, const LanguageMap& langMap) { - int ret; - const sys::Path& tempDir = SaveTemps - ? sys::Path("") - : sys::Path(sys::Path::GetTemporaryDirectory()); - - try { - ret = graph.Build(tempDir, langMap); - } - catch(...) { - tempDir.eraseFromDisk(true); - throw; - } - - if (!SaveTemps) - tempDir.eraseFromDisk(true); - return ret; - } -} - -int main(int argc, char** argv) { - try { - LanguageMap langMap; - CompilationGraph graph; - - cl::ParseCommandLineOptions - (argc, argv, "LLVM Compiler Driver (Work In Progress)", true); - - PluginLoader Plugins; - Plugins.PopulateLanguageMap(langMap); - Plugins.PopulateCompilationGraph(graph); - - if (CheckGraph) { - return graph.Check(); - } - - if (ViewGraph) { - graph.viewGraph(); - if (!WriteGraph) - return 0; - } - - if (WriteGraph) { - graph.writeGraph(); - return 0; - } - - if (InputFilenames.empty()) { - throw std::runtime_error("no input files"); - } - - return BuildTargets(graph, langMap); - } - catch(llvmc::error_code& ec) { - return ec.code(); - } - catch(const std::exception& ex) { - std::cerr << argv[0] << ": " << ex.what() << '\n'; - } - catch(...) { - std::cerr << argv[0] << ": unknown error!\n"; - } - return 1; -} Modified: llvm/trunk/tools/llvmc/plugins/Base/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Base/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Base/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Base/Makefile Mon Mar 2 03:01:14 2009 @@ -7,7 +7,9 @@ # ##===----------------------------------------------------------------------===## +LEVEL = ../.. + LLVMC_PLUGIN = Base BUILT_SOURCES = AutoGenerated.inc -include ../Makefile +include $(LEVEL)/Makefile.llvmc Modified: llvm/trunk/tools/llvmc/plugins/Clang/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Clang/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Clang/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Clang/Makefile Mon Mar 2 03:01:14 2009 @@ -7,7 +7,9 @@ # ##===----------------------------------------------------------------------===## +LEVEL = ../.. + LLVMC_PLUGIN = Clang BUILT_SOURCES = AutoGenerated.inc -include ../Makefile +include $(LEVEL)/Makefile.llvmc Modified: llvm/trunk/tools/llvmc/plugins/Hello/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Hello/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Hello/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Hello/Makefile Mon Mar 2 03:01:14 2009 @@ -7,6 +7,8 @@ # ##===----------------------------------------------------------------------===## +LEVEL = ../.. + LLVMC_PLUGIN = Hello -include ../Makefile +include $(LEVEL)/Makefile.llvmc Modified: llvm/trunk/tools/llvmc/plugins/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Makefile Mon Mar 2 03:01:14 2009 @@ -1,4 +1,4 @@ -##===- tools/llvmc/plugins/Makefile.plugins ----------------*- Makefile -*-===## +##===- tools/llvmc/plugins/Makefile ------------------------*- Makefile -*-===## # # The LLVM Compiler Infrastructure # @@ -7,49 +7,12 @@ # ##===----------------------------------------------------------------------===## -ifndef LLVMC_PLUGIN - LEVEL = ../../.. -DIRS = $(BUILTIN_PLUGINS) - -# TOFIX: Should we also build DSO versions of plugins? -export BUILTIN_LLVMC_PLUGIN=1 - -include $(LEVEL)/Makefile.common -else # LLVMC_PLUGIN - -LEVEL = ../../../.. - -LIBRARYNAME := $(patsubst %,plugin_llvmc_%,$(LLVMC_PLUGIN)) -REQUIRES_EH = 1 - -ifndef BUILTIN_LLVMC_PLUGIN -LOADABLE_MODULE = 1 +ifneq ($(LLVMC_BUILTIN_PLUGINS),) +DIRS = $(LLVMC_BUILTIN_PLUGINS) endif -ifneq ($(BUILT_SOURCES),) -BUILD_AUTOGENERATED_INC=1 -endif +export LLVMC_BUILTIN_PLUGIN=1 include $(LEVEL)/Makefile.common - -# TOFIX: This probably should go into Makefile.rules - -ifdef BUILD_AUTOGENERATED_INC - -TOOLS_SOURCE := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) - -TD_COMMON :=$(strip $(wildcard \ - $(LLVM_SRC_ROOT)/include/llvm/CompilerDriver/*.td)) - -$(ObjDir)/AutoGenerated.inc.tmp: $(TOOLS_SOURCE) $(ObjDir)/.dir \ - $(TBLGEN) $(TD_COMMON) - $(Echo) "Building LLVMC configuration library with tblgen" - $(Verb) $(TableGen) -gen-llvmc -o $(call SYSPATH, $@) $< - -AutoGenerated.inc : $(ObjDir)/AutoGenerated.inc.tmp - $(Verb) $(CMP) -s $@ $< || $(CP) $< $@ -endif # BUILD_AUTOGENERATED_INC - -endif # LLVMC_PLUGIN Modified: llvm/trunk/tools/llvmc/plugins/Simple/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Simple/Makefile?rev=65821&r1=65820&r2=65821&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Simple/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Simple/Makefile Mon Mar 2 03:01:14 2009 @@ -7,7 +7,9 @@ # ##===----------------------------------------------------------------------===## +LEVEL = ../.. + LLVMC_PLUGIN = Simple BUILT_SOURCES = AutoGenerated.inc -include ../Makefile +include $(LEVEL)/Makefile.llvmc From foldr at codedgers.com Mon Mar 2 03:01:39 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:01:39 -0000 Subject: [llvm-commits] [llvm] r65822 - /llvm/trunk/include/llvm/CompilerDriver/Error.h Message-ID: <200903020901.n2291dBt003202@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:01:39 2009 New Revision: 65822 URL: http://llvm.org/viewvc/llvm-project?rev=65822&view=rev Log: Add a comment. Modified: llvm/trunk/include/llvm/CompilerDriver/Error.h Modified: llvm/trunk/include/llvm/CompilerDriver/Error.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Error.h?rev=65822&r1=65821&r2=65822&view=diff ============================================================================== --- llvm/trunk/include/llvm/CompilerDriver/Error.h (original) +++ llvm/trunk/include/llvm/CompilerDriver/Error.h Mon Mar 2 03:01:39 2009 @@ -7,7 +7,7 @@ // //===----------------------------------------------------------------------===// // -// Exception classes for LLVMC. +// Exception classes for llvmc. // //===----------------------------------------------------------------------===// @@ -18,6 +18,8 @@ namespace llvmc { + /// error_code - This gets thrown during the compilation process if a tool + /// invocation returns a non-zero exit code. class error_code: public std::runtime_error { int Code_; public: From foldr at codedgers.com Mon Mar 2 03:02:01 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:02:01 -0000 Subject: [llvm-commits] [llvm] r65823 - /llvm/trunk/include/llvm/CompilerDriver/Plugin.h Message-ID: <200903020902.n22921cK003280@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:02:01 2009 New Revision: 65823 URL: http://llvm.org/viewvc/llvm-project?rev=65823&view=rev Log: Plugin::Priority() doesn't need to be pure virtual. Modified: llvm/trunk/include/llvm/CompilerDriver/Plugin.h Modified: llvm/trunk/include/llvm/CompilerDriver/Plugin.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Plugin.h?rev=65823&r1=65822&r2=65823&view=diff ============================================================================== --- llvm/trunk/include/llvm/CompilerDriver/Plugin.h (original) +++ llvm/trunk/include/llvm/CompilerDriver/Plugin.h Mon Mar 2 03:02:01 2009 @@ -27,7 +27,7 @@ /// Priority - Plugin priority, useful for handling dependencies /// between plugins. Plugins with lower priorities are loaded /// first. - virtual int Priority() const = 0; + virtual int Priority() const { return 0; } /// PopulateLanguageMap - The auto-generated function that fills in /// the language map (map from file extensions to language names). From foldr at codedgers.com Mon Mar 2 03:02:29 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:02:29 -0000 Subject: [llvm-commits] [llvm] r65824 - in /llvm/trunk/include/llvm/CompilerDriver: Action.h CompilationGraph.h Error.h Plugin.h Tool.h Message-ID: <200903020902.n2292TYD003371@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:02:28 2009 New Revision: 65824 URL: http://llvm.org/viewvc/llvm-project?rev=65824&view=rev Log: Cosmetic fixes: include guards. Modified: llvm/trunk/include/llvm/CompilerDriver/Action.h llvm/trunk/include/llvm/CompilerDriver/CompilationGraph.h llvm/trunk/include/llvm/CompilerDriver/Error.h llvm/trunk/include/llvm/CompilerDriver/Plugin.h llvm/trunk/include/llvm/CompilerDriver/Tool.h Modified: llvm/trunk/include/llvm/CompilerDriver/Action.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Action.h?rev=65824&r1=65823&r2=65824&view=diff ============================================================================== --- llvm/trunk/include/llvm/CompilerDriver/Action.h (original) +++ llvm/trunk/include/llvm/CompilerDriver/Action.h Mon Mar 2 03:02:28 2009 @@ -11,8 +11,8 @@ // //===----------------------------------------------------------------------===// -#ifndef LLVM_TOOLS_LLVMC2_ACTION_H -#define LLVM_TOOLS_LLVMC2_ACTION_H +#ifndef LLVM_INCLUDE_COMPILER_DRIVER_ACTION_H +#define LLVM_INCLUDE_COMPILER_DRIVER_ACTION_H #include #include @@ -47,4 +47,4 @@ } -#endif // LLVM_TOOLS_LLVMC2_ACTION_H +#endif // LLVM_INCLUDE_COMPILER_DRIVER_ACTION_H Modified: llvm/trunk/include/llvm/CompilerDriver/CompilationGraph.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/CompilationGraph.h?rev=65824&r1=65823&r2=65824&view=diff ============================================================================== --- llvm/trunk/include/llvm/CompilerDriver/CompilationGraph.h (original) +++ llvm/trunk/include/llvm/CompilerDriver/CompilationGraph.h Mon Mar 2 03:02:28 2009 @@ -11,8 +11,8 @@ // //===----------------------------------------------------------------------===// -#ifndef LLVM_TOOLS_LLVMC2_COMPILATION_GRAPH_H -#define LLVM_TOOLS_LLVMC2_COMPILATION_GRAPH_H +#ifndef LLVM_INCLUDE_COMPILER_DRIVER_COMPILATION_GRAPH_H +#define LLVM_INCLUDE_COMPILER_DRIVER_COMPILATION_GRAPH_H #include "llvm/CompilerDriver/Tool.h" @@ -319,4 +319,4 @@ } -#endif // LLVM_TOOLS_LLVMC2_COMPILATION_GRAPH_H +#endif // LLVM_INCLUDE_COMPILER_DRIVER_COMPILATION_GRAPH_H Modified: llvm/trunk/include/llvm/CompilerDriver/Error.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Error.h?rev=65824&r1=65823&r2=65824&view=diff ============================================================================== --- llvm/trunk/include/llvm/CompilerDriver/Error.h (original) +++ llvm/trunk/include/llvm/CompilerDriver/Error.h Mon Mar 2 03:02:28 2009 @@ -11,8 +11,8 @@ // //===----------------------------------------------------------------------===// -#ifndef LLVM_TOOLS_LLVMC2_ERROR_H -#define LLVM_TOOLS_LLVMC2_ERROR_H +#ifndef LLVM_INCLUDE_COMPILER_DRIVER_ERROR_H +#define LLVM_INCLUDE_COMPILER_DRIVER_ERROR_H #include @@ -32,4 +32,4 @@ } -#endif //LLVM_TOOLS_LLVMC2_ERROR_H +#endif // LLVM_INCLUDE_COMPILER_DRIVER_ERROR_H Modified: llvm/trunk/include/llvm/CompilerDriver/Plugin.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Plugin.h?rev=65824&r1=65823&r2=65824&view=diff ============================================================================== --- llvm/trunk/include/llvm/CompilerDriver/Plugin.h (original) +++ llvm/trunk/include/llvm/CompilerDriver/Plugin.h Mon Mar 2 03:02:28 2009 @@ -7,12 +7,12 @@ // //===----------------------------------------------------------------------===// // -// Plugin support for llvmc2. +// Plugin support for llvmc. // //===----------------------------------------------------------------------===// -#ifndef LLVM_TOOLS_LLVMC2_PLUGIN_H -#define LLVM_TOOLS_LLVMC2_PLUGIN_H +#ifndef LLVM_INCLUDE_COMPILER_DRIVER_PLUGIN_H +#define LLVM_INCLUDE_COMPILER_DRIVER_PLUGIN_H #include "llvm/Support/Registry.h" @@ -76,4 +76,4 @@ } -#endif // LLVM_TOOLS_LLVMC2_PLUGIN_H +#endif // LLVM_INCLUDE_COMPILER_DRIVER_PLUGIN_H Modified: llvm/trunk/include/llvm/CompilerDriver/Tool.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Tool.h?rev=65824&r1=65823&r2=65824&view=diff ============================================================================== --- llvm/trunk/include/llvm/CompilerDriver/Tool.h (original) +++ llvm/trunk/include/llvm/CompilerDriver/Tool.h Mon Mar 2 03:02:28 2009 @@ -11,8 +11,8 @@ // //===----------------------------------------------------------------------===// -#ifndef LLVM_TOOLS_LLVMC2_TOOL_H -#define LLVM_TOOLS_LLVMC2_TOOL_H +#ifndef LLVM_INCLUDE_COMPILER_DRIVER_TOOL_H +#define LLVM_INCLUDE_COMPILER_DRIVER_TOOL_H #include "llvm/CompilerDriver/Action.h" @@ -82,4 +82,4 @@ } -#endif //LLVM_TOOLS_LLVMC2_TOOL_H +#endif // LLVM_INCLUDE_COMPILER_DRIVER_TOOL_H From foldr at codedgers.com Mon Mar 2 03:03:02 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:03:02 -0000 Subject: [llvm-commits] [llvm] r65825 - in /llvm/trunk: include/llvm/CompilerDriver/Main.inc tools/llvmc/driver/Main.cpp Message-ID: <200903020903.n22932sE003491@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:03:02 2009 New Revision: 65825 URL: http://llvm.org/viewvc/llvm-project?rev=65825&view=rev Log: Move code from Main.cpp to the include dir. User drivers based on llvmc must all share the initialization code. Putting main() into libCompilerDriver is not a very good idea IMO (and ld gave me some strange EH-related error anyway). Added: llvm/trunk/include/llvm/CompilerDriver/Main.inc - copied, changed from r65824, llvm/trunk/tools/llvmc/driver/Main.cpp Modified: llvm/trunk/tools/llvmc/driver/Main.cpp Copied: llvm/trunk/include/llvm/CompilerDriver/Main.inc (from r65824, llvm/trunk/tools/llvmc/driver/Main.cpp) URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CompilerDriver/Main.inc?p2=llvm/trunk/include/llvm/CompilerDriver/Main.inc&p1=llvm/trunk/tools/llvmc/driver/Main.cpp&r1=65824&r2=65825&rev=65825&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/driver/Main.cpp (original) +++ llvm/trunk/include/llvm/CompilerDriver/Main.inc Mon Mar 2 03:03:02 2009 @@ -1,4 +1,4 @@ -//===--- Main.cpp - The LLVM Compiler Driver -------------------*- C++ -*-===// +//===--- Main.inc - The LLVM Compiler Driver --------------------*- C++ -*-===// // // The LLVM Compiler Infrastructure // @@ -12,8 +12,13 @@ // supported please refer to the tools' manual page or run the tool // with the --help option. // +// This +// //===----------------------------------------------------------------------===// +#ifndef LLVM_INCLUDE_COMPILER_DRIVER_MAIN_INC +#define LLVM_INCLUDE_COMPILER_DRIVER_MAIN_INC + #include "llvm/CompilerDriver/CompilationGraph.h" #include "llvm/CompilerDriver/Error.h" #include "llvm/CompilerDriver/Plugin.h" @@ -124,3 +129,5 @@ } return 1; } + +#endif // LLVM_INCLUDE_COMPILER_DRIVER_MAIN_INC Modified: llvm/trunk/tools/llvmc/driver/Main.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/driver/Main.cpp?rev=65825&r1=65824&r2=65825&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/driver/Main.cpp (original) +++ llvm/trunk/tools/llvmc/driver/Main.cpp Mon Mar 2 03:03:02 2009 @@ -7,120 +7,8 @@ // //===----------------------------------------------------------------------===// // -// This tool provides a single point of access to the LLVM -// compilation tools. It has many options. To discover the options -// supported please refer to the tools' manual page or run the tool -// with the --help option. +// Just include CompilerDriver/Main.inc. // //===----------------------------------------------------------------------===// -#include "llvm/CompilerDriver/CompilationGraph.h" -#include "llvm/CompilerDriver/Error.h" -#include "llvm/CompilerDriver/Plugin.h" - -#include "llvm/System/Path.h" -#include "llvm/Support/CommandLine.h" -#include "llvm/Support/PluginLoader.h" - -#include -#include -#include - -namespace cl = llvm::cl; -namespace sys = llvm::sys; -using namespace llvmc; - -// Built-in command-line options. -// External linkage here is intentional. - -cl::list InputFilenames(cl::Positional, cl::desc(""), - cl::ZeroOrMore); -cl::opt OutputFilename("o", cl::desc("Output file name"), - cl::value_desc("file"), cl::Prefix); -cl::list Languages("x", - cl::desc("Specify the language of the following input files"), - cl::ZeroOrMore); -cl::opt DryRun("dry-run", - cl::desc("Only pretend to run commands")); -cl::opt VerboseMode("v", - cl::desc("Enable verbose mode")); - -cl::opt CheckGraph("check-graph", - cl::desc("Check the compilation graph for errors"), - cl::Hidden); -cl::opt WriteGraph("write-graph", - cl::desc("Write compilation-graph.dot file"), - cl::Hidden); -cl::opt ViewGraph("view-graph", - cl::desc("Show compilation graph in GhostView"), - cl::Hidden); -cl::opt SaveTemps("save-temps", - cl::desc("Keep temporary files"), - cl::Hidden); - -namespace { - /// BuildTargets - A small wrapper for CompilationGraph::Build. - int BuildTargets(CompilationGraph& graph, const LanguageMap& langMap) { - int ret; - const sys::Path& tempDir = SaveTemps - ? sys::Path("") - : sys::Path(sys::Path::GetTemporaryDirectory()); - - try { - ret = graph.Build(tempDir, langMap); - } - catch(...) { - tempDir.eraseFromDisk(true); - throw; - } - - if (!SaveTemps) - tempDir.eraseFromDisk(true); - return ret; - } -} - -int main(int argc, char** argv) { - try { - LanguageMap langMap; - CompilationGraph graph; - - cl::ParseCommandLineOptions - (argc, argv, "LLVM Compiler Driver (Work In Progress)", true); - - PluginLoader Plugins; - Plugins.PopulateLanguageMap(langMap); - Plugins.PopulateCompilationGraph(graph); - - if (CheckGraph) { - return graph.Check(); - } - - if (ViewGraph) { - graph.viewGraph(); - if (!WriteGraph) - return 0; - } - - if (WriteGraph) { - graph.writeGraph(); - return 0; - } - - if (InputFilenames.empty()) { - throw std::runtime_error("no input files"); - } - - return BuildTargets(graph, langMap); - } - catch(llvmc::error_code& ec) { - return ec.code(); - } - catch(const std::exception& ex) { - std::cerr << argv[0] << ": " << ex.what() << '\n'; - } - catch(...) { - std::cerr << argv[0] << ": unknown error!\n"; - } - return 1; -} +#include "llvm/CompilerDriver/Main.inc" From foldr at codedgers.com Mon Mar 2 03:03:37 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:03:37 -0000 Subject: [llvm-commits] [llvm] r65826 - in /llvm/trunk/tools/llvmc: Makefile Makefile.llvmc plugins/Base/Makefile plugins/Clang/Makefile plugins/Hello/Makefile plugins/Simple/Makefile Message-ID: <200903020903.n2293bxC003622@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:03:36 2009 New Revision: 65826 URL: http://llvm.org/viewvc/llvm-project?rev=65826&view=rev Log: Fix build with objdir != srcdir. Removed: llvm/trunk/tools/llvmc/Makefile.llvmc Modified: llvm/trunk/tools/llvmc/Makefile llvm/trunk/tools/llvmc/plugins/Base/Makefile llvm/trunk/tools/llvmc/plugins/Clang/Makefile llvm/trunk/tools/llvmc/plugins/Hello/Makefile llvm/trunk/tools/llvmc/plugins/Simple/Makefile Modified: llvm/trunk/tools/llvmc/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/Makefile?rev=65826&r1=65825&r2=65826&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/Makefile (original) +++ llvm/trunk/tools/llvmc/Makefile Mon Mar 2 03:03:36 2009 @@ -9,6 +9,8 @@ LEVEL = ../.. +#ifndef LLVMC_PLUGIN + # The current plan is to make the user copy the skeleton project and change only # this file (and plugins/UserPlugin, of course). @@ -18,3 +20,43 @@ DIRS = plugins driver include $(LEVEL)/Makefile.common + +else # LLVMC_PLUGIN + +# We are included from plugins/PluginName/Makefile... +# TODO: This part must be merged into Makefile.rules. + +LEVEL = ../../../.. + +LIBRARYNAME := $(patsubst %,plugin_llvmc_%,$(LLVMC_PLUGIN)) +REQUIRES_EH := 1 + +# Build a dynamic library if the user runs `make` from plugins/PluginName +ifndef LLVMC_BUILTIN_PLUGIN +LOADABLE_MODULE = 1 +endif + +# TableGen stuff... +ifneq ($(BUILT_SOURCES),) +BUILD_AUTOGENERATED_INC=1 +endif + +include $(LEVEL)/Makefile.common + +ifdef BUILD_AUTOGENERATED_INC + +TOOLS_SOURCE := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) + +TD_COMMON :=$(strip $(wildcard \ + $(LLVM_SRC_ROOT)/include/llvm/CompilerDriver/*.td)) + +$(ObjDir)/AutoGenerated.inc.tmp: $(TOOLS_SOURCE) $(ObjDir)/.dir \ + $(TBLGEN) $(TD_COMMON) + $(Echo) "Building LLVMC configuration library with tblgen" + $(Verb) $(TableGen) -gen-llvmc -o $(call SYSPATH, $@) $< + +AutoGenerated.inc : $(ObjDir)/AutoGenerated.inc.tmp + $(Verb) $(CMP) -s $@ $< || $(CP) $< $@ +endif # BUILD_AUTOGENERATED_INC + +endif # LLVMC_PLUGIN Removed: llvm/trunk/tools/llvmc/Makefile.llvmc URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/Makefile.llvmc?rev=65825&view=auto ============================================================================== --- llvm/trunk/tools/llvmc/Makefile.llvmc (original) +++ llvm/trunk/tools/llvmc/Makefile.llvmc (removed) @@ -1,49 +0,0 @@ -##===- tools/llvmc/Makefile.llvmc --------------------------*- Makefile -*-===## -# -# The LLVM Compiler Infrastructure -# -# This file is distributed under the University of Illinois Open -# Source License. See LICENSE.TXT for details. -# -##===----------------------------------------------------------------------===## - -# TODO: This must be eventually merged into Makefile.rules. - -ifdef LLVMC_PLUGIN - -# We are included from plugins/PluginName/Makefile... - -LEVEL = ../../../.. - -LIBRARYNAME := $(patsubst %,plugin_llvmc_%,$(LLVMC_PLUGIN)) -REQUIRES_EH := 1 - -# Build a dynamic library if the user runs `make` from plugins/PluginName -ifndef LLVMC_BUILTIN_PLUGIN -LOADABLE_MODULE = 1 -endif - -# TableGen stuff... -ifneq ($(BUILT_SOURCES),) -BUILD_AUTOGENERATED_INC=1 -endif - -include $(LEVEL)/Makefile.common - -ifdef BUILD_AUTOGENERATED_INC - -TOOLS_SOURCE := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) - -TD_COMMON :=$(strip $(wildcard \ - $(LLVM_SRC_ROOT)/include/llvm/CompilerDriver/*.td)) - -$(ObjDir)/AutoGenerated.inc.tmp: $(TOOLS_SOURCE) $(ObjDir)/.dir \ - $(TBLGEN) $(TD_COMMON) - $(Echo) "Building LLVMC configuration library with tblgen" - $(Verb) $(TableGen) -gen-llvmc -o $(call SYSPATH, $@) $< - -AutoGenerated.inc : $(ObjDir)/AutoGenerated.inc.tmp - $(Verb) $(CMP) -s $@ $< || $(CP) $< $@ -endif # BUILD_AUTOGENERATED_INC - -endif # LLVMC_PLUGIN Modified: llvm/trunk/tools/llvmc/plugins/Base/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Base/Makefile?rev=65826&r1=65825&r2=65826&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Base/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Base/Makefile Mon Mar 2 03:03:36 2009 @@ -12,4 +12,4 @@ LLVMC_PLUGIN = Base BUILT_SOURCES = AutoGenerated.inc -include $(LEVEL)/Makefile.llvmc +include $(LEVEL)/Makefile Modified: llvm/trunk/tools/llvmc/plugins/Clang/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Clang/Makefile?rev=65826&r1=65825&r2=65826&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Clang/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Clang/Makefile Mon Mar 2 03:03:36 2009 @@ -12,4 +12,4 @@ LLVMC_PLUGIN = Clang BUILT_SOURCES = AutoGenerated.inc -include $(LEVEL)/Makefile.llvmc +include $(LEVEL)/Makefile Modified: llvm/trunk/tools/llvmc/plugins/Hello/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Hello/Makefile?rev=65826&r1=65825&r2=65826&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Hello/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Hello/Makefile Mon Mar 2 03:03:36 2009 @@ -11,4 +11,4 @@ LLVMC_PLUGIN = Hello -include $(LEVEL)/Makefile.llvmc +include $(LEVEL)/Makefile Modified: llvm/trunk/tools/llvmc/plugins/Simple/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Simple/Makefile?rev=65826&r1=65825&r2=65826&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Simple/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Simple/Makefile Mon Mar 2 03:03:36 2009 @@ -12,4 +12,4 @@ LLVMC_PLUGIN = Simple BUILT_SOURCES = AutoGenerated.inc -include $(LEVEL)/Makefile.llvmc +include $(LEVEL)/Makefile From foldr at codedgers.com Mon Mar 2 03:04:14 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:04:14 -0000 Subject: [llvm-commits] [llvm] r65827 - in /llvm/trunk: Makefile.rules tools/llvmc/Makefile tools/llvmc/plugins/Base/Makefile tools/llvmc/plugins/Clang/Makefile tools/llvmc/plugins/Hello/Makefile tools/llvmc/plugins/Simple/Makefile Message-ID: <200903020904.n2294EYI003775@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:04:13 2009 New Revision: 65827 URL: http://llvm.org/viewvc/llvm-project?rev=65827&view=rev Log: Move the rules for building plugins to Makefile.rules. Modified: llvm/trunk/Makefile.rules llvm/trunk/tools/llvmc/Makefile llvm/trunk/tools/llvmc/plugins/Base/Makefile llvm/trunk/tools/llvmc/plugins/Clang/Makefile llvm/trunk/tools/llvmc/plugins/Hello/Makefile llvm/trunk/tools/llvmc/plugins/Simple/Makefile Modified: llvm/trunk/Makefile.rules URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.rules?rev=65827&r1=65826&r2=65827&view=diff ============================================================================== --- llvm/trunk/Makefile.rules (original) +++ llvm/trunk/Makefile.rules Mon Mar 2 03:04:13 2009 @@ -192,6 +192,28 @@ install-bytecode:: install-bytecode-local ############################################################################### +# LLVMC: Provide rules for compiling llvmc plugins +############################################################################### + +ifdef LLVMC_PLUGIN + +LIBRARYNAME := $(patsubst %,plugin_llvmc_%,$(LLVMC_PLUGIN)) +REQUIRES_EH := 1 + +# Build a dynamic library if the user runs `make` directly from the plugin +# directory. +ifndef LLVMC_BUILTIN_PLUGIN +LOADABLE_MODULE = 1 +endif + +# TableGen stuff... +ifneq ($(BUILT_SOURCES),) +BUILD_AUTOGENERATED_INC=1 +endif + +endif # LLVMC_PLUGIN + +############################################################################### # VARIABLES: Set up various variables based on configuration data ############################################################################### @@ -1282,6 +1304,37 @@ $(Verb) $(LLVMAS) $< -f -o $@ ############################################################################### +# LLVMC: Provide rules for compiling llvmc plugins, pt. 2 +############################################################################### + +ifdef BUILD_AUTOGENERATED_INC + +# This needs to be in a separate section, otherwise we get an infinite loop:) + +# This stuff is mostly copied from the TABLEGEN section below +# TODO: merge + +LLVMCPluginSrc := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) +TDFiles := $(LLVMCPluginSrc) \ + $(strip $(wildcard $(LLVM_SRC_ROOT)/include/llvm/CompilerDriver/*.td)) +INCFiles := $(filter %.inc,$(BUILT_SOURCES)) +INCTMPFiles := $(INCFiles:%=$(ObjDir)/%.tmp) +.PRECIOUS: $(INCTMPFiles) $(INCFiles) + +# All of these files depend on tblgen and the .td files. +$(INCTMPFiles) : $(TBLGEN) $(TDFiles) + +$(INCFiles) : %.inc : $(ObjDir)/%.inc.tmp + $(Verb) $(CMP) -s $@ $< || $(CP) $< $@ + +$(ObjDir)/AutoGenerated.inc.tmp: $(LLVMCPluginSrc) $(ObjDir)/.dir \ + $(TBLGEN) $(TD_COMMON) + $(Echo) "Building LLVMC configuration library with tblgen" + $(Verb) $(TableGen) -gen-llvmc -o $(call SYSPATH, $@) $< + +endif # BUILD_AUTOGENERATED_INC + +############################################################################### # TABLEGEN: Provide rules for running tblgen to produce *.inc files ############################################################################### @@ -1784,5 +1837,5 @@ # General debugging rule, use 'make print-XXX' to print the # definition, value and origin of XXX. -print-%: +print-%: $(error PRINT: $(value $*) = "$($*)" (from $(origin $*))) Modified: llvm/trunk/tools/llvmc/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/Makefile?rev=65827&r1=65826&r2=65827&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/Makefile (original) +++ llvm/trunk/tools/llvmc/Makefile Mon Mar 2 03:04:13 2009 @@ -9,8 +9,6 @@ LEVEL = ../.. -#ifndef LLVMC_PLUGIN - # The current plan is to make the user copy the skeleton project and change only # this file (and plugins/UserPlugin, of course). @@ -20,43 +18,3 @@ DIRS = plugins driver include $(LEVEL)/Makefile.common - -else # LLVMC_PLUGIN - -# We are included from plugins/PluginName/Makefile... -# TODO: This part must be merged into Makefile.rules. - -LEVEL = ../../../.. - -LIBRARYNAME := $(patsubst %,plugin_llvmc_%,$(LLVMC_PLUGIN)) -REQUIRES_EH := 1 - -# Build a dynamic library if the user runs `make` from plugins/PluginName -ifndef LLVMC_BUILTIN_PLUGIN -LOADABLE_MODULE = 1 -endif - -# TableGen stuff... -ifneq ($(BUILT_SOURCES),) -BUILD_AUTOGENERATED_INC=1 -endif - -include $(LEVEL)/Makefile.common - -ifdef BUILD_AUTOGENERATED_INC - -TOOLS_SOURCE := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) - -TD_COMMON :=$(strip $(wildcard \ - $(LLVM_SRC_ROOT)/include/llvm/CompilerDriver/*.td)) - -$(ObjDir)/AutoGenerated.inc.tmp: $(TOOLS_SOURCE) $(ObjDir)/.dir \ - $(TBLGEN) $(TD_COMMON) - $(Echo) "Building LLVMC configuration library with tblgen" - $(Verb) $(TableGen) -gen-llvmc -o $(call SYSPATH, $@) $< - -AutoGenerated.inc : $(ObjDir)/AutoGenerated.inc.tmp - $(Verb) $(CMP) -s $@ $< || $(CP) $< $@ -endif # BUILD_AUTOGENERATED_INC - -endif # LLVMC_PLUGIN Modified: llvm/trunk/tools/llvmc/plugins/Base/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Base/Makefile?rev=65827&r1=65826&r2=65827&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Base/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Base/Makefile Mon Mar 2 03:04:13 2009 @@ -7,9 +7,9 @@ # ##===----------------------------------------------------------------------===## -LEVEL = ../.. +LEVEL = ../../../.. LLVMC_PLUGIN = Base BUILT_SOURCES = AutoGenerated.inc -include $(LEVEL)/Makefile +include $(LEVEL)/Makefile.common Modified: llvm/trunk/tools/llvmc/plugins/Clang/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Clang/Makefile?rev=65827&r1=65826&r2=65827&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Clang/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Clang/Makefile Mon Mar 2 03:04:13 2009 @@ -7,9 +7,9 @@ # ##===----------------------------------------------------------------------===## -LEVEL = ../.. +LEVEL = ../../../.. LLVMC_PLUGIN = Clang BUILT_SOURCES = AutoGenerated.inc -include $(LEVEL)/Makefile +include $(LEVEL)/Makefile.common Modified: llvm/trunk/tools/llvmc/plugins/Hello/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Hello/Makefile?rev=65827&r1=65826&r2=65827&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Hello/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Hello/Makefile Mon Mar 2 03:04:13 2009 @@ -7,8 +7,8 @@ # ##===----------------------------------------------------------------------===## -LEVEL = ../.. +LEVEL = ../../../.. LLVMC_PLUGIN = Hello -include $(LEVEL)/Makefile +include $(LEVEL)/Makefile.common Modified: llvm/trunk/tools/llvmc/plugins/Simple/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc/plugins/Simple/Makefile?rev=65827&r1=65826&r2=65827&view=diff ============================================================================== --- llvm/trunk/tools/llvmc/plugins/Simple/Makefile (original) +++ llvm/trunk/tools/llvmc/plugins/Simple/Makefile Mon Mar 2 03:04:13 2009 @@ -7,9 +7,9 @@ # ##===----------------------------------------------------------------------===## -LEVEL = ../.. +LEVEL = ../../../.. LLVMC_PLUGIN = Simple BUILT_SOURCES = AutoGenerated.inc -include $(LEVEL)/Makefile +include $(LEVEL)/Makefile.common From baldrick at free.fr Mon Mar 2 03:18:21 2009 From: baldrick at free.fr (Duncan Sands) Date: Mon, 02 Mar 2009 09:18:21 -0000 Subject: [llvm-commits] [llvm] r65832 - in /llvm/trunk: lib/Transforms/Scalar/InstructionCombining.cpp test/Transforms/InstCombine/2009-03-02-VarLengthArrayGEP.ll Message-ID: <200903020918.n229ILEZ007125@zion.cs.uiuc.edu> Author: baldrick Date: Mon Mar 2 03:18:21 2009 New Revision: 65832 URL: http://llvm.org/viewvc/llvm-project?rev=65832&view=rev Log: Fix PR3694: add an instcombine micro-optimization that helps clean up when using variable length arrays in llvm-gcc. Added: llvm/trunk/test/Transforms/InstCombine/2009-03-02-VarLengthArrayGEP.ll Modified: llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Modified: llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp?rev=65832&r1=65831&r2=65832&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp (original) +++ llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Mon Mar 2 03:18:21 2009 @@ -10766,15 +10766,25 @@ // transform: GEP (bitcast [10 x i8]* X to [0 x i8]*), i32 0, ... // into : GEP [10 x i8]* X, i32 0, ... // + // Likewise, transform: GEP (bitcast i8* X to [0 x i8]*), i32 0, ... + // into : GEP i8* X, ... + // // This occurs when the program declares an array extern like "int X[];" - // const PointerType *CPTy = cast(PtrOp->getType()); const PointerType *XTy = cast(X->getType()); - if (const ArrayType *XATy = - dyn_cast(XTy->getElementType())) - if (const ArrayType *CATy = - dyn_cast(CPTy->getElementType())) + if (const ArrayType *CATy = + dyn_cast(CPTy->getElementType())) { + // GEP (bitcast i8* X to [0 x i8]*), i32 0, ... ? + if (CATy->getElementType() == XTy->getElementType()) { + // -> GEP i8* X, ... + SmallVector Indices(GEP.idx_begin()+1, GEP.idx_end()); + return GetElementPtrInst::Create(X, Indices.begin(), Indices.end(), + GEP.getName()); + } else if (const ArrayType *XATy = + dyn_cast(XTy->getElementType())) { + // GEP (bitcast [10 x i8]* X to [0 x i8]*), i32 0, ... ? if (CATy->getElementType() == XATy->getElementType()) { + // -> GEP [10 x i8]* X, i32 0, ... // At this point, we know that the cast source type is a pointer // to an array of the same type as the destination pointer // array. Because the array type is never stepped over (there @@ -10782,6 +10792,8 @@ GEP.setOperand(0, X); return &GEP; } + } + } } else if (GEP.getNumOperands() == 2) { // Transform things like: // %t = getelementptr i32* bitcast ([2 x i32]* %str to i32*), i32 %V Added: llvm/trunk/test/Transforms/InstCombine/2009-03-02-VarLengthArrayGEP.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/2009-03-02-VarLengthArrayGEP.ll?rev=65832&view=auto ============================================================================== --- llvm/trunk/test/Transforms/InstCombine/2009-03-02-VarLengthArrayGEP.ll (added) +++ llvm/trunk/test/Transforms/InstCombine/2009-03-02-VarLengthArrayGEP.ll Mon Mar 2 03:18:21 2009 @@ -0,0 +1,14 @@ +; RUN: llvm-as < %s | opt -instcombine | llvm-dis | grep {getelementptr i32} +; PR3694 + +define i32 @e(i32 %m, i32 %n) nounwind { +entry: + %0 = alloca i32, i32 %n, align 4 ; [#uses=2] + %1 = bitcast i32* %0 to [0 x i32]* ; <[0 x i32]*> [#uses=1] + call void @f(i32* %0) nounwind + %2 = getelementptr [0 x i32]* %1, i32 0, i32 %m ; [#uses=1] + %3 = load i32* %2, align 4 ; [#uses=1] + ret i32 %3 +} + +declare void @f(i32*) From nicolas.geoffray at lip6.fr Mon Mar 2 03:25:39 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 02 Mar 2009 09:25:39 -0000 Subject: [llvm-commits] [llvm] r65833 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903020925.n229Pdi5007350@zion.cs.uiuc.edu> Author: geoffray Date: Mon Mar 2 03:25:38 2009 New Revision: 65833 URL: http://llvm.org/viewvc/llvm-project?rev=65833&view=rev Log: Add more notes for VMKit. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65833&r1=65832&r2=65833&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 03:25:38 2009 @@ -171,7 +171,7 @@ a JVM and a CLI Virtual Machines (Microsoft .NET is an implementation of the CLI) using the Just-In-Time compiler of LLVM.

    -

    Following LLVM 2.5, VMKit has its first release that you can find on its +

    Following LLVM 2.5, VMKit has its second release that you can find on its webpage. The release includes bug fixes, cleanup and new features. The major changes are:

    @@ -189,7 +189,13 @@ gain for exception-intensive applications. For example the jack benchmark in Spec JVM98 is 6x faster (performance gain of 83%). -
  • New support for OSX/X64, Linux/X64 (with the Boehm GC), Linux/ppc32.
  • +
  • User-level management of thread stacks, so that thread local data access +at runtime is fast and portable.
  • + +
  • Implementation of biased locking for faster object synchronizations at +runtime.
  • + +
  • New support for OSX/X64, Linux/X64 (with the Boehm GC) and Linux/ppc32.
  • From foldr at codedgers.com Mon Mar 2 03:42:59 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 02 Mar 2009 09:42:59 -0000 Subject: [llvm-commits] [llvm] r65834 - /llvm/trunk/Makefile.rules Message-ID: <200903020942.n229gxuH008013@zion.cs.uiuc.edu> Author: foldr Date: Mon Mar 2 03:42:59 2009 New Revision: 65834 URL: http://llvm.org/viewvc/llvm-project?rev=65834&view=rev Log: Remove duplication in Makefile.rules. Merge common bits from the LLVMC and TABLEGEN sections. Modified: llvm/trunk/Makefile.rules Modified: llvm/trunk/Makefile.rules URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.rules?rev=65834&r1=65833&r2=65834&view=diff ============================================================================== --- llvm/trunk/Makefile.rules (original) +++ llvm/trunk/Makefile.rules Mon Mar 2 03:42:59 2009 @@ -208,7 +208,7 @@ # TableGen stuff... ifneq ($(BUILT_SOURCES),) -BUILD_AUTOGENERATED_INC=1 +LLVMC_BUILD_AUTOGENERATED_INC=1 endif endif # LLVMC_PLUGIN @@ -1304,19 +1304,19 @@ $(Verb) $(LLVMAS) $< -f -o $@ ############################################################################### -# LLVMC: Provide rules for compiling llvmc plugins, pt. 2 +# TABLEGEN: Provide rules for running tblgen to produce *.inc files ############################################################################### -ifdef BUILD_AUTOGENERATED_INC +ifdef TARGET +TABLEGEN_INC_FILES_COMMON = 1 +endif -# This needs to be in a separate section, otherwise we get an infinite loop:) +ifdef LLVMC_BUILD_AUTOGENERATED_INC +TABLEGEN_INC_FILES_COMMON = 1 +endif -# This stuff is mostly copied from the TABLEGEN section below -# TODO: merge +ifdef TABLEGEN_INC_FILES_COMMON -LLVMCPluginSrc := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) -TDFiles := $(LLVMCPluginSrc) \ - $(strip $(wildcard $(LLVM_SRC_ROOT)/include/llvm/CompilerDriver/*.td)) INCFiles := $(filter %.inc,$(BUILT_SOURCES)) INCTMPFiles := $(INCFiles:%=$(ObjDir)/%.tmp) .PRECIOUS: $(INCTMPFiles) $(INCFiles) @@ -1324,19 +1324,16 @@ # All of these files depend on tblgen and the .td files. $(INCTMPFiles) : $(TBLGEN) $(TDFiles) +# INCFiles rule: All of the tblgen generated files are emitted to +# $(ObjDir)/%.inc.tmp, instead of emitting them directly to %.inc. This allows +# us to only "touch" the real file if the contents of it change. IOW, if +# tblgen is modified, all of the .inc.tmp files are regenerated, but no +# dependencies of the .inc files are, unless the contents of the .inc file +# changes. $(INCFiles) : %.inc : $(ObjDir)/%.inc.tmp $(Verb) $(CMP) -s $@ $< || $(CP) $< $@ -$(ObjDir)/AutoGenerated.inc.tmp: $(LLVMCPluginSrc) $(ObjDir)/.dir \ - $(TBLGEN) $(TD_COMMON) - $(Echo) "Building LLVMC configuration library with tblgen" - $(Verb) $(TableGen) -gen-llvmc -o $(call SYSPATH, $@) $< - -endif # BUILD_AUTOGENERATED_INC - -############################################################################### -# TABLEGEN: Provide rules for running tblgen to produce *.inc files -############################################################################### +endif # TABLEGEN_INC_FILES_COMMON ifdef TARGET @@ -1347,21 +1344,6 @@ $(LLVM_SRC_ROOT)/include/llvm/Target/TargetSelectionDAG.td \ $(LLVM_SRC_ROOT)/include/llvm/CodeGen/ValueTypes.td) \ $(wildcard $(LLVM_SRC_ROOT)/include/llvm/Intrinsics*.td) -INCFiles := $(filter %.inc,$(BUILT_SOURCES)) -INCTMPFiles := $(INCFiles:%=$(ObjDir)/%.tmp) -.PRECIOUS: $(INCTMPFiles) $(INCFiles) - -# All of these files depend on tblgen and the .td files. -$(INCTMPFiles) : $(TBLGEN) $(TDFiles) - -# INCFiles rule: All of the tblgen generated files are emitted to -# $(ObjDir)/%.inc.tmp, instead of emitting them directly to %.inc. This allows -# us to only "touch" the real file if the contents of it change. IOW, if -# tblgen is modified, all of the .inc.tmp files are regenerated, but no -# dependencies of the .inc files are, unless the contents of the .inc file -# changes. -$(INCFiles) : %.inc : $(ObjDir)/%.inc.tmp - $(Verb) $(CMP) -s $@ $< || $(CP) $< $@ $(TARGET:%=$(ObjDir)/%GenRegisterNames.inc.tmp): \ $(ObjDir)/%GenRegisterNames.inc.tmp : %.td $(ObjDir)/.dir @@ -1431,7 +1413,22 @@ clean-local:: -$(Verb) $(RM) -f $(INCFiles) -endif +endif # TARGET + +ifdef LLVMC_BUILD_AUTOGENERATED_INC + +LLVMCPluginSrc := $(strip $(wildcard $(PROJ_SRC_DIR)/*.td)) + +TDFiles := $(LLVMCPluginSrc) \ + $(strip $(wildcard $(LLVM_SRC_ROOT)/include/llvm/CompilerDriver/*.td)) + +$(ObjDir)/AutoGenerated.inc.tmp: $(LLVMCPluginSrc) $(ObjDir)/.dir \ + $(TBLGEN) $(TD_COMMON) + $(Echo) "Building LLVMC configuration library with tblgen" + $(Verb) $(TableGen) -gen-llvmc -o $(call SYSPATH, $@) $< + +endif # LLVMC_BUILD_AUTOGENERATED_INC + ############################################################################### # OTHER RULES: Other rules needed From isanbard at gmail.com Mon Mar 2 03:46:35 2009 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 02 Mar 2009 09:46:35 -0000 Subject: [llvm-commits] [llvm] r65835 - in /llvm/branches/Apple/Dib: include/llvm/Bitcode/LLVMBitCodes.h lib/Bitcode/Reader/BitcodeReader.cpp lib/Bitcode/Writer/BitcodeWriter.cpp lib/VMCore/Constants.cpp test/Transforms/InstCombine/shufflevec-constant.ll Message-ID: <200903020946.n229kZ4k008149@zion.cs.uiuc.edu> Author: void Date: Mon Mar 2 03:46:35 2009 New Revision: 65835 URL: http://llvm.org/viewvc/llvm-project?rev=65835&view=rev Log: Merge r64401 into Dib: Add suppport for ConstantExprs of shufflevectors whose result type is not equal to the type of the vectors being shuffled. Added: llvm/branches/Apple/Dib/test/Transforms/InstCombine/shufflevec-constant.ll - copied unchanged from r64401, llvm/trunk/test/Transforms/InstCombine/shufflevec-constant.ll Modified: llvm/branches/Apple/Dib/include/llvm/Bitcode/LLVMBitCodes.h llvm/branches/Apple/Dib/lib/Bitcode/Reader/BitcodeReader.cpp llvm/branches/Apple/Dib/lib/Bitcode/Writer/BitcodeWriter.cpp llvm/branches/Apple/Dib/lib/VMCore/Constants.cpp Modified: llvm/branches/Apple/Dib/include/llvm/Bitcode/LLVMBitCodes.h URL: http://llvm.org/viewvc/llvm-project/llvm/branches/Apple/Dib/include/llvm/Bitcode/LLVMBitCodes.h?rev=65835&r1=65834&r2=65835&view=diff ============================================================================== --- llvm/branches/Apple/Dib/include/llvm/Bitcode/LLVMBitCodes.h (original) +++ llvm/branches/Apple/Dib/include/llvm/Bitcode/LLVMBitCodes.h Mon Mar 2 03:46:35 2009 @@ -125,7 +125,8 @@ CST_CODE_CE_INSERTELT = 15, // CE_INSERTELT: [opval, opval, opval] CST_CODE_CE_SHUFFLEVEC = 16, // CE_SHUFFLEVEC: [opval, opval, opval] CST_CODE_CE_CMP = 17, // CE_CMP: [opty, opval, opval, pred] - CST_CODE_INLINEASM = 18 // INLINEASM: [sideeffect,asmstr,conststr] + CST_CODE_INLINEASM = 18, // INLINEASM: [sideeffect,asmstr,conststr] + CST_CODE_CE_SHUFVEC_EX = 19 // SHUFVEC_EX: [opty, opval, opval, opval] }; /// CastOpcodes - These are values used in the bitcode files to encode which Modified: llvm/branches/Apple/Dib/lib/Bitcode/Reader/BitcodeReader.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/branches/Apple/Dib/lib/Bitcode/Reader/BitcodeReader.cpp?rev=65835&r1=65834&r2=65835&view=diff ============================================================================== --- llvm/branches/Apple/Dib/lib/Bitcode/Reader/BitcodeReader.cpp (original) +++ llvm/branches/Apple/Dib/lib/Bitcode/Reader/BitcodeReader.cpp Mon Mar 2 03:46:35 2009 @@ -933,7 +933,7 @@ case bitc::CST_CODE_CE_SHUFFLEVEC: { // CE_SHUFFLEVEC: [opval, opval, opval] const VectorType *OpTy = dyn_cast(CurTy); if (Record.size() < 3 || OpTy == 0) - return Error("Invalid CE_INSERTELT record"); + return Error("Invalid CE_SHUFFLEVEC record"); Constant *Op0 = ValueList.getConstantFwdRef(Record[0], OpTy); Constant *Op1 = ValueList.getConstantFwdRef(Record[1], OpTy); const Type *ShufTy=VectorType::get(Type::Int32Ty, OpTy->getNumElements()); @@ -941,6 +941,18 @@ V = ConstantExpr::getShuffleVector(Op0, Op1, Op2); break; } + case bitc::CST_CODE_CE_SHUFVEC_EX: { // [opty, opval, opval, opval] + const VectorType *RTy = dyn_cast(CurTy); + const VectorType *OpTy = dyn_cast(getTypeByID(Record[0])); + if (Record.size() < 4 || RTy == 0 || OpTy == 0) + return Error("Invalid CE_SHUFVEC_EX record"); + Constant *Op0 = ValueList.getConstantFwdRef(Record[1], OpTy); + Constant *Op1 = ValueList.getConstantFwdRef(Record[2], OpTy); + const Type *ShufTy=VectorType::get(Type::Int32Ty, RTy->getNumElements()); + Constant *Op2 = ValueList.getConstantFwdRef(Record[3], ShufTy); + V = ConstantExpr::getShuffleVector(Op0, Op1, Op2); + break; + } case bitc::CST_CODE_CE_CMP: { // CE_CMP: [opty, opval, opval, pred] if (Record.size() < 4) return Error("Invalid CE_CMP record"); const Type *OpTy = getTypeByID(Record[0]); Modified: llvm/branches/Apple/Dib/lib/Bitcode/Writer/BitcodeWriter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/branches/Apple/Dib/lib/Bitcode/Writer/BitcodeWriter.cpp?rev=65835&r1=65834&r2=65835&view=diff ============================================================================== --- llvm/branches/Apple/Dib/lib/Bitcode/Writer/BitcodeWriter.cpp (original) +++ llvm/branches/Apple/Dib/lib/Bitcode/Writer/BitcodeWriter.cpp Mon Mar 2 03:46:35 2009 @@ -643,7 +643,16 @@ Record.push_back(VE.getValueID(C->getOperand(2))); break; case Instruction::ShuffleVector: - Code = bitc::CST_CODE_CE_SHUFFLEVEC; + // If the return type and argument types are the same, this is a + // standard shufflevector instruction. If the types are different, + // then the shuffle is widening or truncating the input vectors, and + // the argument type must also be encoded. + if (C->getType() == C->getOperand(0)->getType()) { + Code = bitc::CST_CODE_CE_SHUFFLEVEC; + } else { + Code = bitc::CST_CODE_CE_SHUFVEC_EX; + Record.push_back(VE.getTypeID(C->getOperand(0)->getType())); + } Record.push_back(VE.getValueID(C->getOperand(0))); Record.push_back(VE.getValueID(C->getOperand(1))); Record.push_back(VE.getValueID(C->getOperand(2))); Modified: llvm/branches/Apple/Dib/lib/VMCore/Constants.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/branches/Apple/Dib/lib/VMCore/Constants.cpp?rev=65835&r1=65834&r2=65835&view=diff ============================================================================== --- llvm/branches/Apple/Dib/lib/VMCore/Constants.cpp (original) +++ llvm/branches/Apple/Dib/lib/VMCore/Constants.cpp Mon Mar 2 03:46:35 2009 @@ -554,7 +554,10 @@ return User::operator new(s, 3); } ShuffleVectorConstantExpr(Constant *C1, Constant *C2, Constant *C3) - : ConstantExpr(C1->getType(), Instruction::ShuffleVector, + : ConstantExpr(VectorType::get( + cast(C1->getType())->getElementType(), + cast(C3->getType())->getNumElements()), + Instruction::ShuffleVector, &Op<0>(), 3) { Op<0>() = C1; Op<1>() = C2; @@ -2349,7 +2352,11 @@ Constant *Mask) { assert(ShuffleVectorInst::isValidOperands(V1, V2, Mask) && "Invalid shuffle vector constant expr operands!"); - return getShuffleVectorTy(V1->getType(), V1, V2, Mask); + + unsigned NElts = cast(Mask->getType())->getNumElements(); + const Type *EltTy = cast(V1->getType())->getElementType(); + const Type *ShufTy = VectorType::get(EltTy, NElts); + return getShuffleVectorTy(ShufTy, V1, V2, Mask); } Constant *ConstantExpr::getInsertValueTy(const Type *ReqTy, Constant *Agg, From nicolas.geoffray at lip6.fr Mon Mar 2 03:55:36 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 02 Mar 2009 10:55:36 +0100 Subject: [llvm-commits] [llvm] r65802 - /llvm/trunk/docs/GarbageCollection.html In-Reply-To: <200903020347.n223lKKr018441@zion.cs.uiuc.edu> References: <200903020347.n223lKKr018441@zion.cs.uiuc.edu> Message-ID: <49ABAD18.2050901@lip6.fr> Hi Gordon, Nice improvements on the docs! A few comments: Gordon Henriksen wrote: > If your target collector uses tags, use a null pointer for > metadata.

    > Could you define what "tags" means before that sentence? I guess it's a header in the object? And what makes you say that a Java object has type-tags? Because it always references its class? > > The compiler plugin is responsible for generating code which > +conforms to the binary interface defined by library, most essentially the > +stack map.

    > > Broken link. Nicolas From ggreif at gmail.com Mon Mar 2 05:34:56 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 11:34:56 -0000 Subject: [llvm-commits] [llvm] r65837 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021134.n22BYw3p012468@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 05:34:51 2009 New Revision: 65837 URL: http://llvm.org/viewvc/llvm-project?rev=65837&view=rev Log: minor tweaks Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65837&r1=65836&r2=65837&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 05:34:51 2009 @@ -178,7 +178,7 @@
    • Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this -functionality to native compile the standard classes (eg java.lang.String). +functionality to native compile the standard classes (e.g. java.lang.String). Users can compile AOT .class files into dynamic libraries and run them with the help of VMKit.
    • @@ -489,7 +489,7 @@
    • The X86 backend now supports using address space #256 in LLVM IR as a way of performing memory references off the GS segment register. This allows a front-end to take advantage of very low-level programming techniques when -targetting X86 CPUs. See test/CodeGen/X86/movgs.ll for a simple +targeting X86 CPUs. See test/CodeGen/X86/movgs.ll for a simple example.
    • The X86 backend now supports a -disable-mmx command line option to @@ -526,7 +526,7 @@ types.
    • Function calls involving basic types work now.
    • Support for integer arrays.
    • -
    • Compiler can now emit libcalls for operations not support by m/c +
    • Compiler can now emit libcalls for operations not supported by m/c instructions.
    • Support for both data and ROM address spaces.
    From ggreif at gmail.com Mon Mar 2 06:03:04 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 12:03:04 -0000 Subject: [llvm-commits] [llvm] r65838 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021203.n22C359i013320@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 06:02:51 2009 New Revision: 65838 URL: http://llvm.org/viewvc/llvm-project?rev=65838&view=rev Log: minor tweaks Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65838&r1=65837&r2=65838&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 06:02:51 2009 @@ -58,8 +58,8 @@ target-specific intrinsics gold lto plugin pre-alloc splitter, strong phi elim - llc -enable-value-prop, propagation of value info (sign/zero ext info) from - one MBB to another + llc -enable-value-prop, propagation of value info + (sign/zero ext info) from one MBB to another debug info for optimized code interpreter + libffi postalloc scheduler: anti dependence breaking, hazard recognizer? @@ -179,7 +179,7 @@
  • Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this functionality to native compile the standard classes (e.g. java.lang.String). -Users can compile AOT .class files into dynamic libraries and run them with the +Users can compile AoT .class files into dynamic libraries and run them with the help of VMKit.
  • New exception model: the dwarf exception model is very slow for @@ -818,7 +818,7 @@ inline assembly code.
  • The C backend violates the ABI of common C++ programs, preventing intermixing between C++ compiled by the CBE and - C++ code compiled with llc or native compilers.
  • + C++ code compiled with llc or native compilers.
  • The C backend does not support all exception handling constructs.
  • The C backend does not support arbitrary precision integers.
  • From ggreif at gmail.com Mon Mar 2 06:10:59 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 12:10:59 -0000 Subject: [llvm-commits] [llvm] r65839 - /llvm/trunk/include/llvm/PassSupport.h Message-ID: <200903021211.n22CB0ps013616@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 06:10:56 2009 New Revision: 65839 URL: http://llvm.org/viewvc/llvm-project?rev=65839&view=rev Log: fix typo Modified: llvm/trunk/include/llvm/PassSupport.h Modified: llvm/trunk/include/llvm/PassSupport.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/PassSupport.h?rev=65839&r1=65838&r2=65839&view=diff ============================================================================== --- llvm/trunk/include/llvm/PassSupport.h (original) +++ llvm/trunk/include/llvm/PassSupport.h Mon Mar 2 06:10:56 2009 @@ -127,7 +127,7 @@ return ItfImpl; } - /// getPassInfo - Deprecated API compaatibility function. This function + /// getPassInfo - Deprecated API compatibility function. This function /// just returns 'this'. /// const PassInfo *getPassInfo() const { From ggreif at gmail.com Mon Mar 2 06:24:06 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 12:24:06 -0000 Subject: [llvm-commits] [llvm] r65841 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021224.n22CO7Xo014124@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 06:23:55 2009 New Revision: 65841 URL: http://llvm.org/viewvc/llvm-project?rev=65841&view=rev Log: note the removal of deprecated interfaces Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65841&r1=65840&r2=65841&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 06:23:55 2009 @@ -613,7 +613,8 @@ API changes are:

      -
    • ?
    • +
    • Some deprecated interfaces to create Instruction subclasses, that + were spelled with lower case "create", have been removed.
    From ggreif at gmail.com Mon Mar 2 06:42:12 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 12:42:12 -0000 Subject: [llvm-commits] [llvm] r65842 - /llvm/trunk/include/llvm/PassSupport.h Message-ID: <200903021242.n22CgDAh014693@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 06:42:07 2009 New Revision: 65842 URL: http://llvm.org/viewvc/llvm-project?rev=65842&view=rev Log: remove a deprecated interface that was pretty useless Modified: llvm/trunk/include/llvm/PassSupport.h Modified: llvm/trunk/include/llvm/PassSupport.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/PassSupport.h?rev=65842&r1=65841&r2=65842&view=diff ============================================================================== --- llvm/trunk/include/llvm/PassSupport.h (original) +++ llvm/trunk/include/llvm/PassSupport.h Mon Mar 2 06:42:07 2009 @@ -127,13 +127,6 @@ return ItfImpl; } - /// getPassInfo - Deprecated API compatibility function. This function - /// just returns 'this'. - /// - const PassInfo *getPassInfo() const { - return this; - } - protected: void registerPass(); void unregisterPass(); From ggreif at gmail.com Mon Mar 2 08:47:57 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 14:47:57 -0000 Subject: [llvm-commits] [llvm] r65843 - in /llvm/trunk/include/llvm: BasicBlock.h Function.h Message-ID: <200903021447.n22ElxCC018908@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 08:47:45 2009 New Revision: 65843 URL: http://llvm.org/viewvc/llvm-project?rev=65843&view=rev Log: Declare Sentinel fragments as mutable to get rid of some pointless casting. This fragment logically does not belong to ilist anyway, but to "ghostly" NodeType. Modified: llvm/trunk/include/llvm/BasicBlock.h llvm/trunk/include/llvm/Function.h Modified: llvm/trunk/include/llvm/BasicBlock.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/BasicBlock.h?rev=65843&r1=65842&r2=65843&view=diff ============================================================================== --- llvm/trunk/include/llvm/BasicBlock.h (original) +++ llvm/trunk/include/llvm/BasicBlock.h Mon Mar 2 08:47:45 2009 @@ -38,14 +38,14 @@ // NodeTy, which becomes the sentinel. Dereferencing the sentinel is // forbidden (save the ilist_node) so no one will ever notice // the superposition. - return const_cast(static_cast(&Sentinel)); + return static_cast(&Sentinel); } static void destroySentinel(Instruction*) {} static iplist &getList(BasicBlock *BB); static ValueSymbolTable *getSymTab(BasicBlock *ItemParent); static int getListOffset(); private: - ilist_node Sentinel; + mutable ilist_node Sentinel; }; /// This represents a single basic block in LLVM. A basic block is simply a Modified: llvm/trunk/include/llvm/Function.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Function.h?rev=65843&r1=65842&r2=65843&view=diff ============================================================================== --- llvm/trunk/include/llvm/Function.h (original) +++ llvm/trunk/include/llvm/Function.h Mon Mar 2 08:47:45 2009 @@ -35,28 +35,28 @@ // createSentinel is used to get hold of the node that marks the end of the // list... (same trick used here as in ilist_traits) BasicBlock *createSentinel() const { - return const_cast(static_cast(&Sentinel)); + return static_cast(&Sentinel); } static void destroySentinel(BasicBlock*) {} static iplist &getList(Function *F); static ValueSymbolTable *getSymTab(Function *ItemParent); static int getListOffset(); private: - ilist_node Sentinel; + mutable ilist_node Sentinel; }; template<> struct ilist_traits : public SymbolTableListTraits { Argument *createSentinel() const { - return const_cast(static_cast(&Sentinel)); + return static_cast(&Sentinel); } static void destroySentinel(Argument*) {} static iplist &getList(Function *F); static ValueSymbolTable *getSymTab(Function *ItemParent); static int getListOffset(); private: - ilist_node Sentinel; + mutable ilist_node Sentinel; }; class Function : public GlobalValue, public Annotable, From criswell at uiuc.edu Mon Mar 2 09:28:20 2009 From: criswell at uiuc.edu (John Criswell) Date: Mon, 02 Mar 2009 15:28:20 -0000 Subject: [llvm-commits] [llvm] r65844 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021528.n22FSK5U020289@zion.cs.uiuc.edu> Author: criswell Date: Mon Mar 2 09:28:15 2009 New Revision: 65844 URL: http://llvm.org/viewvc/llvm-project?rev=65844&view=rev Log: Grammar and punctuation fixes. No content changes. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65844&r1=65843&r2=65844&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 09:28:15 2009 @@ -152,7 +152,7 @@ better job of reasoning about inequality relationships (e.g., x > 2) between variables and constants. -

    The set of checks performed by the static analyzer continue to expand, and +

    The set of checks performed by the static analyzer continues to expand, and future plans for the tool include full source-level inter-procedural analysis and deeper checks such as buffer overrun detection. There are many opportunities to extend and enhance the static analyzer, and anyone interested in working on @@ -241,7 +241,8 @@

    LDC is an implementation of the D Programming Language using the LLVM optimizer and code generator. -LDC project works great with the LLVM 2.5 release. General improvements in this +The LDC project works great with the LLVM 2.5 release. General improvements in +this cycle have included new inline asm constraint handling, better debug info support, general bugfixes, and better x86-64 support. This has allowed some major improvements in LDC, getting us much closer to being as @@ -304,7 +305,7 @@ only supported by the interpreter. Note that the C backend still does not support these. -

  • LLVM 2.5 no longer uses 'bison', so it is easier to build on Windows.
  • +
  • LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.
  • @@ -377,13 +378,13 @@
  • The parser for ".ll" files in lib/AsmParser is now completely rewritten as a recursive descent parser. This parser produces better error messages (including -caret diagnostics) is less fragile (less likely to crash on strange things) does -not leak memory, is more efficient, and eliminates LLVM's last use of the +caret diagnostics), is less fragile (less likely to crash on strange things), +does not leak memory, is more efficient, and eliminates LLVM's last use of the 'bison' tool.
  • Debug information representation and manipulation internals have been consolidated to use a new set of classes in - llvm/Analysis/DebugInfo.h classes. These routines are more + llvm/Analysis/DebugInfo.h. These routines are more efficient, robust, and extensible and replace the older mechanisms. llvm-gcc, clang, and the code generator now use them to create and process debug information.
  • @@ -399,7 +400,7 @@
    -

    In addition to a huge array of bug fixes and minor performance tweaks, this +

    In addition to a large array of bug fixes and minor performance tweaks, this release includes a few major enhancements and additions to the optimizers:

      @@ -408,7 +409,7 @@ several ways, including adding shadow induction variables to avoid "integer <-> floating point" conversions in loops when safe. -
    • The "-mem2reg" pass is now much faster on code with huge basic blocks.
    • +
    • The "-mem2reg" pass is now much faster on code with large basic blocks.
    • The "-jump-threading" pass is more powerful: it is iterative and handles threading based on values with fully and partially redundant @@ -442,7 +443,7 @@
    • The SelectionDAG type legalization logic has been completely rewritten, is now more powerful (it supports arbitrary precision integer types for example), -and more correct in several corner cases. The type legalizer converts +and is more correct in several corner cases. The type legalizer converts operations on types that are not natively supported by the target machine into equivalent code sequences that only use natively supported types. The old type legalizer is still available (for now) and will be used if @@ -456,7 +457,7 @@
    • The assembly printers for each target are now split out into their own libraries that are separate from the main code generation logic. This reduces -code size of JIT compilers by not requiring them to be linked in.
    • +the code size of JIT compilers by not requiring them to be linked in.
    • The 'fast' instruction selection path (used at -O0 and for fast JIT compilers) now supports accelerating codegen for code that uses exception @@ -499,8 +500,8 @@
    • The X86 JIT now detects the new Intel Core i7 and Atom chips; - auto-configuring itself appropriately for the features of these chips.
    • + href="http://en.wikipedia.org/wiki/Intel_Atom">Atom chips and + auto-configures itself appropriately for the features of these chips.
    • The JIT now supports exception handling constructs on Linux/X86-64 and Darwin/x86-64.
    • @@ -526,7 +527,7 @@ types.
    • Function calls involving basic types work now.
    • Support for integer arrays.
    • -
    • Compiler can now emit libcalls for operations not supported by m/c +
    • The compiler can now emit libcalls for operations not supported by m/c instructions.
    • Support for both data and ROM address spaces.
    @@ -614,7 +615,7 @@
    • Some deprecated interfaces to create Instruction subclasses, that - were spelled with lower case "create", have been removed.
    • + were spelled with lower case "create," have been removed.
    @@ -703,11 +704,12 @@
  • The X86 backend generates inefficient floating point code when configured to generate code for systems that don't have SSE2.
  • Win64 code generation wasn't widely tested. Everything should work, but we - expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime - currently due + expect small issues to happen. Also, llvm-gcc cannot build the mingw64 + runtime currently due to several - bugs due to lack of support for the - 'u' inline assembly constraint and X87 floating point inline assembly.
  • + bugs and due to lack of support for + the + 'u' inline assembly constraint and for X87 floating point inline assembly.
  • The X86-64 backend does not yet support the LLVM IR instruction va_arg. Currently, the llvm-gcc and front-ends support variadic argument constructs on X86-64 by lowering them manually.
  • @@ -740,7 +742,7 @@
  • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 processors, thumb programs can crash or produce wrong results (PR1388).
  • -
  • Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested. +
  • Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
  • There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly execute @@ -757,7 +759,7 @@
      -
    • The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not +
    • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not support the 64-bit SPARC ABI (-m64).
    @@ -800,7 +802,7 @@
      -
    • The Itanium backend is highly experimental, and has a number of known +
    • The Itanium backend is highly experimental and has a number of known issues. We are looking for a maintainer for the Itanium backend. If you are interested, please contact the LLVMdev mailing list.
    @@ -888,12 +890,12 @@
    -The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature -technology and problems should be expected. +The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature +technology, and problems should be expected.
    • The Ada front-end currently only builds on X86-32. This is mainly due -to lack of trampoline support (pointers to nested functions) on other platforms, -however it also fails to build on X86-64 +to lack of trampoline support (pointers to nested functions) on other platforms. +However, it also fails to build on X86-64 which does support trampolines.
    • The Ada front-end fails to bootstrap. This is due to lack of LLVM support for setjmp/longjmp style From baldrick at free.fr Mon Mar 2 10:36:00 2009 From: baldrick at free.fr (Duncan Sands) Date: Mon, 02 Mar 2009 16:36:00 -0000 Subject: [llvm-commits] [llvm] r65845 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021636.n22Ga2Ya022717@zion.cs.uiuc.edu> Author: baldrick Date: Mon Mar 2 10:35:57 2009 New Revision: 65845 URL: http://llvm.org/viewvc/llvm-project?rev=65845&view=rev Log: Use GCC not gcc, like everywhere else in this document. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65845&r1=65844&r2=65845&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 10:35:57 2009 @@ -906,7 +906,7 @@ (c380004 also fails with gcc-4.2 mainline). If the compiler is built with checks disabled then c393010 causes the compiler to go into an infinite loop, using up all system memory.
    • -
    • Some gcc specific Ada tests continue to crash the compiler.
    • +
    • Some GCC specific Ada tests continue to crash the compiler.
    • The -E binder option (exception backtraces) does not work and will result in programs crashing if an exception is raised. Workaround: do not use -E.
    • From baldrick at free.fr Mon Mar 2 10:58:03 2009 From: baldrick at free.fr (Duncan Sands) Date: Mon, 02 Mar 2009 16:58:03 -0000 Subject: [llvm-commits] [llvm] r65846 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021658.n22Gw3Qe023616@zion.cs.uiuc.edu> Author: baldrick Date: Mon Mar 2 10:58:00 2009 New Revision: 65846 URL: http://llvm.org/viewvc/llvm-project?rev=65846&view=rev Log: Try to make the meaning of 'nocapture' a bit clearer. I commented out the line about simplifylibcalls because I think this doesn't work in the release (it was fixed in svn after the release branched). Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65846&r1=65845&r2=65846&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 10:58:00 2009 @@ -368,13 +368,16 @@
    • LLVM IR supports two new attributes for better alias analysis. The noalias attribute can now be used on the return value of a function to indicate that it returns new memory (e.g. -'malloc', 'calloc', etc).
    • - -
    • The new nocapture attribute can be -used on pointer arguments to functions that access through but do not return the -pointer in a data structure that out lives the call (e.g. 'strlen', 'memcpy', -and many others). The simplifylibcalls pass applies these attributes to -standard libc functions.
    • +'malloc', 'calloc', etc). +The new nocapture attribute can be used +on pointer arguments to indicate that the function does not return the pointer, +store it in an object that outlives the call, or let the value of the pointer +escape from the function in any other way. +Note that it is the pointer itself that must not escape, not the value it +points to: loading a value out of the pointer is perfectly fine. +Many standard library functions (e.g. 'strlen', 'memcpy') have this property. + +
    • The parser for ".ll" files in lib/AsmParser is now completely rewritten as a recursive descent parser. This parser produces better error messages (including From criswell at uiuc.edu Mon Mar 2 11:34:13 2009 From: criswell at uiuc.edu (John Criswell) Date: Mon, 02 Mar 2009 17:34:13 -0000 Subject: [llvm-commits] [poolalloc] r65848 - in /poolalloc/trunk/lib/DSA: DataStructure.cpp Printer.cpp Message-ID: <200903021734.n22HYDnb024946@zion.cs.uiuc.edu> Author: criswell Date: Mon Mar 2 11:34:09 2009 New Revision: 65848 URL: http://llvm.org/viewvc/llvm-project?rev=65848&view=rev Log: Updated to the new API for WriteTypeSymbolic() (which uses LLVM streams instead of the ones from the std namespace). Modified: poolalloc/trunk/lib/DSA/DataStructure.cpp poolalloc/trunk/lib/DSA/Printer.cpp Modified: poolalloc/trunk/lib/DSA/DataStructure.cpp URL: http://llvm.org/viewvc/llvm-project/poolalloc/trunk/lib/DSA/DataStructure.cpp?rev=65848&r1=65847&r2=65848&view=diff ============================================================================== --- poolalloc/trunk/lib/DSA/DataStructure.cpp (original) +++ poolalloc/trunk/lib/DSA/DataStructure.cpp Mon Mar 2 11:34:09 2009 @@ -29,6 +29,7 @@ #include "llvm/ADT/SCCIterator.h" #include "llvm/ADT/Statistic.h" #include "llvm/Support/Timer.h" +#include "llvm/Support/raw_ostream.h" #include "llvm/ADT/hash_map.h" #include @@ -768,12 +769,13 @@ M = getParentGraph()->retnodes_begin()->first->getParent(); DOUT << "MergeTypeInfo Folding OrigTy: "; - DEBUG(WriteTypeSymbolic(*cerr.stream(), Ty, M); - *cerr.stream() << "\n due to:"; - WriteTypeSymbolic(*cerr.stream(), NewTy, M); - *cerr.stream() << " @ " << Offset << "!\n" << "SubType: "; - WriteTypeSymbolic(*cerr.stream(), SubType, M); - *cerr.stream() << "\n\n"); + raw_stderr_ostream stream; + DEBUG(WriteTypeSymbolic(stream, Ty, M); + stream << "\n due to:"; + WriteTypeSymbolic(stream, NewTy, M); + stream << " @ " << Offset << "!\n" << "SubType: "; + WriteTypeSymbolic(stream, SubType, M); + stream << "\n\n"); if (FoldIfIncompatible) foldNodeCompletely(); return true; Modified: poolalloc/trunk/lib/DSA/Printer.cpp URL: http://llvm.org/viewvc/llvm-project/poolalloc/trunk/lib/DSA/Printer.cpp?rev=65848&r1=65847&r2=65848&view=diff ============================================================================== --- poolalloc/trunk/lib/DSA/Printer.cpp (original) +++ poolalloc/trunk/lib/DSA/Printer.cpp Mon Mar 2 11:34:09 2009 @@ -24,6 +24,7 @@ #include "llvm/Support/Streams.h" #include "llvm/ADT/Statistic.h" #include "llvm/Config/config.h" +#include "llvm/Support/raw_ostream.h" #include #include #include @@ -43,7 +44,8 @@ void DSNode::dump() const { print(cerr, 0); } static std::string getCaption(const DSNode *N, const DSGraph *G) { - std::stringstream OS; + std::string empty; + raw_string_ostream OS(empty); const Module *M = 0; if (!G) G = N->getParentGraph(); From criswell at uiuc.edu Mon Mar 2 12:20:12 2009 From: criswell at uiuc.edu (John Criswell) Date: Mon, 02 Mar 2009 18:20:12 -0000 Subject: [llvm-commits] [poolalloc] r65851 - /poolalloc/trunk/lib/PoolAllocate/Makefile Message-ID: <200903021820.n22IKCi2026360@zion.cs.uiuc.edu> Author: criswell Date: Mon Mar 2 12:20:11 2009 New Revision: 65851 URL: http://llvm.org/viewvc/llvm-project?rev=65851&view=rev Log: Recent changes to the LLVM build system prevent the relinked and dynamic versions from being built at the same time under Mac OS X; for now, just build the relinked version. Modified: poolalloc/trunk/lib/PoolAllocate/Makefile Modified: poolalloc/trunk/lib/PoolAllocate/Makefile URL: http://llvm.org/viewvc/llvm-project/poolalloc/trunk/lib/PoolAllocate/Makefile?rev=65851&r1=65850&r2=65851&view=diff ============================================================================== --- poolalloc/trunk/lib/PoolAllocate/Makefile (original) +++ poolalloc/trunk/lib/PoolAllocate/Makefile Mon Mar 2 12:20:11 2009 @@ -7,7 +7,6 @@ # Give the name of a library. This will build a dynamic version. # BUILD_RELINKED=1 -SHARED_LIBRARY=1 LIBRARYNAME=poolalloc # From sabre at nondot.org Mon Mar 2 13:07:24 2009 From: sabre at nondot.org (Chris Lattner) Date: Mon, 02 Mar 2009 19:07:24 -0000 Subject: [llvm-commits] [llvm] r65856 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021907.n22J7Pvg028592@zion.cs.uiuc.edu> Author: lattner Date: Mon Mar 2 13:07:24 2009 New Revision: 65856 URL: http://llvm.org/viewvc/llvm-project?rev=65856&view=rev Log: update blurb per Shannon Weyrick. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65856&r1=65855&r2=65856&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 13:07:24 2009 @@ -257,9 +257,9 @@

      Roadsend PHP (rphp) is an open -source compiler for the PHP programming language that uses LLVM for its -optimizer, JIT, and static compiler. This is a reimplementation of an earlier -project that is now based on the LLVM.

      +source implementation of the PHP programming +language that uses LLVM for its optimizer, JIT, and static compiler. This is a +reimplementation of an earlier project that is now based on LLVM.

      From ggreif at gmail.com Mon Mar 2 13:08:05 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 19:08:05 -0000 Subject: [llvm-commits] [llvm] r65857 - /llvm/trunk/docs/FAQ.html Message-ID: <200903021908.n22J8553028627@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 13:08:05 2009 New Revision: 65857 URL: http://llvm.org/viewvc/llvm-project?rev=65857&view=rev Log: add a Q/A on broken GCCs Modified: llvm/trunk/docs/FAQ.html Modified: llvm/trunk/docs/FAQ.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/FAQ.html?rev=65857&r1=65856&r2=65857&view=diff ============================================================================== --- llvm/trunk/docs/FAQ.html (original) +++ llvm/trunk/docs/FAQ.html Mon Mar 2 13:08:05 2009 @@ -48,6 +48,7 @@
    • I've built LLVM and am testing it, but the tests freeze.
    • Why do test results differ when I perform different types of builds?
    • Compiling LLVM with GCC 3.3.2 fails, what should I do?
    • +
    • Compiling LLVM with GCC succeeds, but the resulting tools do not work, what can be wrong?
    • When I use the test suite, all of the C Backend tests fail. What is wrong?
    • After Subversion update, rebuilding gives the error "No rule to make @@ -356,6 +357,17 @@
    +

    Compiling LLVM with GCC succeeds, but the resulting tools do not work, what can be wrong?

    +
    + +
    +

    Several versions of GCC have shown a weakness in miscompiling the LLVM codebase. Please +consult your compiler version (gcc --version) to find out whether it is +broken. If so, your only option is to upgrade +GCC to a known good version.

    +
    + +

    After Subversion update, rebuilding gives the error "No rule to make target".

    From ggreif at gmail.com Mon Mar 2 13:11:55 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 19:11:55 -0000 Subject: [llvm-commits] [llvm] r65858 - /llvm/trunk/docs/FAQ.html Message-ID: <200903021911.n22JBuqs028815@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 13:11:53 2009 New Revision: 65858 URL: http://llvm.org/viewvc/llvm-project?rev=65858&view=rev Log: fix broken GCC bugzilla link Modified: llvm/trunk/docs/FAQ.html Modified: llvm/trunk/docs/FAQ.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/FAQ.html?rev=65858&r1=65857&r2=65858&view=diff ============================================================================== --- llvm/trunk/docs/FAQ.html (original) +++ llvm/trunk/docs/FAQ.html Mon Mar 2 13:11:53 2009 @@ -352,7 +352,7 @@
    -

    This is a bug in GCC, and +

    This is a bug in GCC, and affects projects other than LLVM. Try upgrading or downgrading your GCC.

    From edwintorok at gmail.com Mon Mar 2 13:38:03 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Mon, 02 Mar 2009 21:38:03 +0200 Subject: [llvm-commits] upgrade autoconf to 2.63? Message-ID: <49AC359B.3030902@gmail.com> Hi, I've tried to upgrade llvm's autoconf script to 2.63, and fixed some new warnings, see attached patches: patch1 is: AutoRegen.sh | 12 ++++++------ configure.ac | 21 ++++++++++----------- m4/path_tclsh.m4 | 4 ++-- 3 files changed, 18 insertions(+), 19 deletions(-) patch is: autoconf/AutoRegen.sh | 12 autoconf/configure.ac | 21 autoconf/m4/argz.m4 | 79 autoconf/m4/libtool.m4 | 8474 ++++++++++++++++++++++------------------ autoconf/m4/ltdl.m4 | 842 ++- autoconf/m4/ltoptions.m4 | 368 + autoconf/m4/ltsugar.m4 | 123 autoconf/m4/ltversion.m4 | 23 autoconf/m4/lt~obsolete.m4 | 92 autoconf/m4/path_tclsh.m4 | 4 include/llvm/Config/config.h.in | 100 11 files changed, 6101 insertions(+), 4037 deletions(-) Neither patch includes configure because: svn: File 'configure' has inconsistent newlines svn: Inconsistent line ending style That comes from this portion of configure (that seems to come from autoconf itself): ac_cr='^M' ac_cs_awk_cr=`$AWK 'BEGIN { print "a\rb" }' /dev/null` if test "$ac_cs_awk_cr" = "a${ac_cr}b"; then ac_cs_awk_cr='\\r' else ac_cs_awk_cr=$ac_cr fi So maybe configure should be set to preserve line-endings? Thoughts? Best regards, --Edwin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch Url: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20090302/9b39d26f/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch1 Url: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20090302/9b39d26f/attachment-0001.pl From tonic at nondot.org Mon Mar 2 13:39:11 2009 From: tonic at nondot.org (Tanya Lattner) Date: Mon, 02 Mar 2009 19:39:11 -0000 Subject: [llvm-commits] [llvm] r65859 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903021939.n22JdDhi031120@zion.cs.uiuc.edu> Author: tbrethou Date: Mon Mar 2 13:38:59 2009 New Revision: 65859 URL: http://llvm.org/viewvc/llvm-project?rev=65859&view=rev Log: Remove incorrect information about fortran on Darwin. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65859&r1=65858&r2=65859&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 13:38:59 2009 @@ -881,9 +881,6 @@
    • Fortran support generally works, but there are still several unresolved bugs in Bugzilla. Please see the tools/gfortran component for details.
    • - -
    • The Fortran front-end currently does not build on Darwin (without tweaks) - due to unresolved dependencies on the C front-end.
    From ggreif at gmail.com Mon Mar 2 13:49:39 2009 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 02 Mar 2009 19:49:39 -0000 Subject: [llvm-commits] [llvm] r65864 - /llvm/trunk/include/llvm/ADT/ilist.h Message-ID: <200903021949.n22Jnenj031520@zion.cs.uiuc.edu> Author: ggreif Date: Mon Mar 2 13:49:29 2009 New Revision: 65864 URL: http://llvm.org/viewvc/llvm-project?rev=65864&view=rev Log: drop support for GCC 2.x as it is hopelessly broken anyway Modified: llvm/trunk/include/llvm/ADT/ilist.h Modified: llvm/trunk/include/llvm/ADT/ilist.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ilist.h?rev=65864&r1=65863&r2=65864&view=diff ============================================================================== --- llvm/trunk/include/llvm/ADT/ilist.h (original) +++ llvm/trunk/include/llvm/ADT/ilist.h Mon Mar 2 13:49:29 2009 @@ -491,14 +491,7 @@ size_type size() const { if (Head == 0) return 0; // Don't require construction of sentinel if empty. -#if __GNUC__ == 2 - // GCC 2.95 has a broken std::distance - size_type Result = 0; - std::distance(begin(), end(), Result); - return Result; -#else return std::distance(begin(), end()); -#endif } iterator erase(iterator first, iterator last) { @@ -616,14 +609,10 @@ insert(this->begin(), first, last); } - - // Forwarding functions: A workaround for GCC 2.95 which does not correctly - // support 'using' declarations to bring a hidden member into scope. - // - iterator insert(iterator a, NodeTy *b){ return iplist::insert(a, b); } - void push_front(NodeTy *a) { iplist::push_front(a); } - void push_back(NodeTy *a) { iplist::push_back(a); } - + // bring hidden functions into scope + using iplist::insert; + using iplist::push_front; + using iplist::push_back; // Main implementation here - Insert for a node passed by value... iterator insert(iterator where, const NodeTy &val) { From daniel at zuster.org Mon Mar 2 14:08:17 2009 From: daniel at zuster.org (Daniel Dunbar) Date: Mon, 02 Mar 2009 20:08:17 -0000 Subject: [llvm-commits] [llvm] r65868 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <200903022008.n22K8IfQ032318@zion.cs.uiuc.edu> Author: ddunbar Date: Mon Mar 2 14:08:12 2009 New Revision: 65868 URL: http://llvm.org/viewvc/llvm-project?rev=65868&view=rev Log: Add some more clang related release notes. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65868&r1=65867&r2=65868&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 14:08:12 2009 @@ -104,14 +104,11 @@ continuing to make major strides forward in all areas. Its C and Objective-C parsing and code generation support is now very solid. For example, it is capable of successfully building many real-world applications for X86-32 -andX86-64, -including the FreeBSD -kernel. C++ is also +and X86-64, +including the FreeBSD +kernel and gcc 4.2. C++ is also making incredible progress, -and work on templates has recently started.

    - -

    While Clang is not yet production quality, it is progressing very nicely and -is quite usable for building many C and Objective-C applications. If you are +and work on templates has recently started. If you are interested in fast compiles and good diagnostics, we encourage you to try it out by building from mainline and reporting any issues you hit to the

  • Clang now has a new driver, which is focused on providing a GCC-compatible interface.
  • -
  • The X86-64 ABI is now supported.
  • +
  • The X86-64 ABI is now supported, including support for the Apple + 64-bit Objective-C runtime and zero cost exception handling.
  • Precompiled header support is now implemented.
  • Objective-C support is significantly improved beyond LLVM 2.4, supporting many features, such as Objective-C Garbage Collection.
  • +
  • Variable length arrays are now fully supported.
  • +
  • C99 designated initializers are now fully supported.
  • +
  • Clang now includes all major compiler headers, including a + redesigned tgmath.h and several more intrinsic headers.
  • Many many bugs are fixed and many features have been added.
  • From aaronngray.lists at googlemail.com Mon Mar 2 15:14:45 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Mon, 2 Mar 2009 21:14:45 +0000 Subject: [llvm-commits] SVN broken on Cygwin platform Message-ID: <9719867c0903021314k2304f7c0mb669e0f9322153d@mail.gmail.com> It looks like its accessing home directories and not liking paths containing spaces :- ~~~ $ make tools-only /bin/sh: line 0: cd: /home/Aaron: No such file or directory /bin/sh: line 0: cd: /home/Aaron: No such file or directory /bin/sh: line 0: cd: /usr/src/llvm//home/Aaron: No such file or directory /usr/src/llvm/Makefile.rules:146: warning: overriding commands for target `/home /Aaron' /usr/src/llvm/Makefile.rules:133: warning: ignoring old commands for target `/ho me/Aaron' /usr/src/llvm/Makefile.rules:1183: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:146: warning: ignoring old commands for target `/ho me/Aaron' /usr/src/llvm/Makefile.rules:1188: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1183: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1193: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1188: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1202: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1193: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1211: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1202: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1220: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1211: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1279: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1220: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1283: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1279: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1287: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1283: warning: ignoring old commands for target `/h ome/Aaron' /usr/src/llvm/Makefile.rules:1309: warning: overriding commands for target `/hom e/Aaron' /usr/src/llvm/Makefile.rules:1287: warning: ignoring old commands for target `/h ome/Aaron' Makefile:146: *** multiple target patterns. Stop. ~~~ Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20090302/c5c95e0d/attachment.html From clattner at apple.com Mon Mar 2 15:18:49 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 2 Mar 2009 13:18:49 -0800 Subject: [llvm-commits] SVN broken on Cygwin platform In-Reply-To: <9719867c0903021314k2304f7c0mb669e0f9322153d@mail.gmail.com> References: <9719867c0903021314k2304f7c0mb669e0f9322153d@mail.gmail.com> Message-ID: On Mar 2, 2009, at 1:14 PM, Aaron Gray wrote: > It looks like its accessing home directories and not liking paths > containing spaces :- > We've never supported this. Please make a \llvm directory or something like that. -Chris From gohman at apple.com Mon Mar 2 15:23:44 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 21:23:44 -0000 Subject: [llvm-commits] [test-suite] r65871 - /test-suite/trunk/External/SPEC/CFP2000/188.ammp/Makefile Message-ID: <200903022123.n22LNihF002667@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 15:23:44 2009 New Revision: 65871 URL: http://llvm.org/viewvc/llvm-project?rev=65871&view=rev Log: This code for setting RUN_TYPE is redundant with that in Makefile.spec2000. Modified: test-suite/trunk/External/SPEC/CFP2000/188.ammp/Makefile Modified: test-suite/trunk/External/SPEC/CFP2000/188.ammp/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CFP2000/188.ammp/Makefile?rev=65871&r1=65870&r2=65871&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CFP2000/188.ammp/Makefile (original) +++ test-suite/trunk/External/SPEC/CFP2000/188.ammp/Makefile Mon Mar 2 15:23:44 2009 @@ -8,17 +8,4 @@ FP_ABSTOLERANCE=0.0001 FP_TOLERANCE=0.003 -# override RUN_TYPE (this is a long running test): -ifndef RUN_TYPE -ifdef SMALL_PROBLEM_SIZE -RUN_TYPE=test -else -ifdef LARGE_PROBLEM_SIZE -RUN_TYPE := ref -else -RUN_TYPE := train -endif -endif -endif - include ../../Makefile.spec2000 From gohman at apple.com Mon Mar 2 15:30:41 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 21:30:41 -0000 Subject: [llvm-commits] [test-suite] r65872 - /test-suite/trunk/External/SPEC/Makefile.spec Message-ID: <200903022130.n22LUflZ002976@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 15:30:41 2009 New Revision: 65872 URL: http://llvm.org/viewvc/llvm-project?rev=65872&view=rev Log: Use '$(if ...)' instead of 'ifdef' because the former allows variables expanded in the condition to be "recursively expanded variables" rather than just "immediately expanded variables". See the make manual and the comments in the commit for details. Modified: test-suite/trunk/External/SPEC/Makefile.spec Modified: test-suite/trunk/External/SPEC/Makefile.spec URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/Makefile.spec?rev=65872&r1=65871&r2=65872&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/Makefile.spec (original) +++ test-suite/trunk/External/SPEC/Makefile.spec Mon Mar 2 15:30:41 2009 @@ -94,13 +94,15 @@ # output with the program's output. BUGPOINT_OPTIONS += -append-exit-code -# If a tolerance is set, pass it off to bugpoint -ifdef FP_TOLERANCE -BUGPOINT_OPTIONS += -rel-tolerance $(FP_TOLERANCE) -endif -ifdef FP_ABSTOLERANCE -BUGPOINT_OPTIONS += -abs-tolerance $(FP_ABSTOLERANCE) -endif +# If a tolerance is set, pass it off to bugpoint. +# +# Note: this uses '$(if ...)' instead of ifeq so that FP_TOLERANCE and +# FP_ABSTOLERANCE can be "recursively expanded". The purpose of this is +# to allow the indivdiaul benchmark Makefiles to set FP_TOLERANCE +# after including this file, which they may need to do if they wish to +# have it depend on the value of RUN_TYPE. +BUGPOINT_OPTIONS += $(if $(FP_TOLERANCE),-rel-tolerance $(FP_TOLERANCE),) +BUGPOINT_OPTIONS += $(if $(FP_ABSTOLERANCE),-abs-tolerance $(FP_ABSTOLERANCE),) # Give bugpoint information about LDFLAGS to pass down to the actual link stage From gohman at apple.com Mon Mar 2 15:32:30 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 21:32:30 -0000 Subject: [llvm-commits] [test-suite] r65873 - /test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile Message-ID: <200903022132.n22LWU9J003052@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 15:32:30 2009 New Revision: 65873 URL: http://llvm.org/viewvc/llvm-project?rev=65873&view=rev Log: Tests like 'ifeq ($(RUN_TYPE),test' must be done after including Makefile.spec2006, which sets RUN_TYPE. Modified: test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile Modified: test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile?rev=65873&r1=65872&r2=65873&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile (original) +++ test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile Mon Mar 2 15:32:30 2009 @@ -10,17 +10,15 @@ CPPFLAGS += -DNDEBUG +LDFLAGS = -lstdc++ -lm +LIBS = -lstdc++ -lm + +include ../../Makefile.spec2006 + ifeq ($(RUN_TYPE),test) FP_TOLERANCE = 0.0001 RUN_OPTIONS = -s1 -e -m10000 test.mps - STDOUT_FILENAME := test.out else FP_TOLERANCE = 20 RUN_OPTIONS = -s1 -e -m1200 train.mps - STDOUT_FILENAME := train.out endif - -LDFLAGS = -lstdc++ -lm -LIBS = -lstdc++ -lm - -include ../../Makefile.spec2006 From gohman at apple.com Mon Mar 2 15:33:25 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 21:33:25 -0000 Subject: [llvm-commits] [test-suite] r65874 - /test-suite/trunk/External/SPEC/CFP2006/453.povray/Makefile Message-ID: <200903022133.n22LXPir003089@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 15:33:25 2009 New Revision: 65874 URL: http://llvm.org/viewvc/llvm-project?rev=65874&view=rev Log: Tests like 'ifeq ($(RUN_TYPE),test' must be done after including Makefile.spec2006, which sets RUN_TYPE. Modified: test-suite/trunk/External/SPEC/CFP2006/453.povray/Makefile Modified: test-suite/trunk/External/SPEC/CFP2006/453.povray/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CFP2006/453.povray/Makefile?rev=65874&r1=65873&r2=65874&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CFP2006/453.povray/Makefile (original) +++ test-suite/trunk/External/SPEC/CFP2006/453.povray/Makefile Mon Mar 2 15:33:25 2009 @@ -8,14 +8,6 @@ FP_ABSTOLERANCE = 0 -ifeq ($(RUN_TYPE),test) - FP_TOLERANCE = 0.0002 - RUN_OPTIONS = SPEC-benchmark-test -else - FP_TOLERANCE = 0.00005 - RUN_OPTIONS = SPEC-benchmark-train -endif - STDOUT_FILENAME := SPEC-benchmark.log LDFLAGS = -lstdc++ -lm @@ -23,3 +15,10 @@ include ../../Makefile.spec2006 +ifeq ($(RUN_TYPE),test) + FP_TOLERANCE = 0.0002 + RUN_OPTIONS = SPEC-benchmark-test +else + FP_TOLERANCE = 0.00005 + RUN_OPTIONS = SPEC-benchmark-train +endif From gohman at apple.com Mon Mar 2 15:33:58 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 21:33:58 -0000 Subject: [llvm-commits] [test-suite] r65875 - /test-suite/trunk/External/SPEC/CFP2006/447.dealII/Makefile Message-ID: <200903022133.n22LXwMD003134@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 15:33:58 2009 New Revision: 65875 URL: http://llvm.org/viewvc/llvm-project?rev=65875&view=rev Log: Tests like 'ifeq ($(RUN_TYPE),test' must be done after including Makefile.spec2006, which sets RUN_TYPE. Also, don't duplicate Makefile.spec2006's setting of RUN_TYPE. Modified: test-suite/trunk/External/SPEC/CFP2006/447.dealII/Makefile Modified: test-suite/trunk/External/SPEC/CFP2006/447.dealII/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CFP2006/447.dealII/Makefile?rev=65875&r1=65874&r2=65875&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CFP2006/447.dealII/Makefile (original) +++ test-suite/trunk/External/SPEC/CFP2006/447.dealII/Makefile Mon Mar 2 15:33:58 2009 @@ -13,27 +13,15 @@ -DBOOST_DISABLE_THREADS \ -I$(SPEC_BENCH_DIR)/src/include -ifndef RUN_TYPE -ifdef SMALL_PROBLEM_SIZE -RUN_TYPE=test -else -ifdef LARGE_PROBLEM_SIZE -RUN_TYPE=ref -else -RUN_TYPE=train -endif -endif -endif - -ifeq ($(RUN_TYPE),test) - RUN_OPTIONS := 8 -else - RUN_OPTIONS := 10 -endif - STDOUT_FILENAME := log LDFLAGS = -lstdc++ -lm LIBS = -lm include ../../Makefile.spec2006 + +ifeq ($(RUN_TYPE),test) + RUN_OPTIONS = 8 +else + RUN_OPTIONS = 10 +endif From aaronngray.lists at googlemail.com Mon Mar 2 16:00:11 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Mon, 2 Mar 2009 22:00:11 -0000 Subject: [llvm-commits] SVN broken on Cygwin platform References: <9719867c0903021314k2304f7c0mb669e0f9322153d@mail.gmail.com> Message-ID: <3BDAB896D2274EACBEC1577C246D735A@HPLAPTOP> > On Mar 2, 2009, at 1:14 PM, Aaron Gray wrote: > >> It looks like its accessing home directories and not liking paths >> containing spaces :- >> > > We've never supported this. Please make a \llvm directory or > something like that. Looks like its my Cygwin instillation. SVN works fine on my laptop. Sorry for the noise, Aaron From sabre at nondot.org Mon Mar 2 16:17:16 2009 From: sabre at nondot.org (Chris Lattner) Date: Mon, 02 Mar 2009 22:17:16 -0000 Subject: [llvm-commits] [llvm] r65882 - /llvm/trunk/lib/System/Unix/Path.inc Message-ID: <200903022217.n22MHG1F005253@zion.cs.uiuc.edu> Author: lattner Date: Mon Mar 2 16:17:15 2009 New Revision: 65882 URL: http://llvm.org/viewvc/llvm-project?rev=65882&view=rev Log: Fix main executable path name resolution on FreeBSD, patch by Ed Schouten! Modified: llvm/trunk/lib/System/Unix/Path.inc Modified: llvm/trunk/lib/System/Unix/Path.inc URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/System/Unix/Path.inc?rev=65882&r1=65881&r2=65882&view=diff ============================================================================== --- llvm/trunk/lib/System/Unix/Path.inc (original) +++ llvm/trunk/lib/System/Unix/Path.inc Mon Mar 2 16:17:15 2009 @@ -266,10 +266,69 @@ return Path(pathname); } +#ifdef __FreeBSD__ +static int +test_dir(char buf[PATH_MAX], char ret[PATH_MAX], + const char *dir, const char *bin) +{ + struct stat sb; + + snprintf(buf, PATH_MAX, "%s//%s", dir, bin); + if (realpath(buf, ret) == NULL) + return (1); + if (stat(buf, &sb) != 0) + return (1); + + return (0); +} + +static char * +getprogpath(char ret[PATH_MAX], const char *bin) +{ + char *pv, *s, *t, buf[PATH_MAX]; + + /* First approach: absolute path. */ + if (bin[0] == '/') { + if (test_dir(buf, ret, "/", bin) == 0) + return (ret); + return (NULL); + } + + /* Second approach: relative path. */ + if (strchr(bin, '/') != NULL) { + if (getcwd(buf, PATH_MAX) == NULL) + return (NULL); + if (test_dir(buf, ret, buf, bin) == 0) + return (ret); + return (NULL); + } + + /* Third approach: $PATH */ + if ((pv = getenv("PATH")) == NULL) + return (NULL); + s = pv = strdup(pv); + if (pv == NULL) + return (NULL); + while ((t = strsep(&s, ":")) != NULL) { + if (test_dir(buf, ret, t, bin) == 0) { + free(pv); + return (ret); + } + } + free(pv); + return (NULL); +} +#endif + /// GetMainExecutable - Return the path to the main executable, given the /// value of argv[0] from program startup. Path Path::GetMainExecutable(const char *argv0, void *MainAddr) { -#if defined(__linux__) || defined(__CYGWIN__) +#if defined(__FreeBSD__) + char exe_path[PATH_MAX]; + + if (getprogpath(exe_path, argv0) != NULL) + return Path(std::string(exe_path)); +#elif defined(__linux__) || defined(__CYGWIN__) char exe_path[MAXPATHLEN]; ssize_t len = readlink("/proc/self/exe", exe_path, sizeof(exe_path)); if (len > 0 && len < MAXPATHLEN - 1) { From gohman at apple.com Mon Mar 2 16:17:26 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 22:17:26 -0000 Subject: [llvm-commits] [test-suite] r65883 - /test-suite/trunk/External/SPEC/CINT2006/Makefile Message-ID: <200903022217.n22MHQ84005277@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 16:17:26 2009 New Revision: 65883 URL: http://llvm.org/viewvc/llvm-project?rev=65883&view=rev Log: Enable 483.xalancbmk. Modified: test-suite/trunk/External/SPEC/CINT2006/Makefile Modified: test-suite/trunk/External/SPEC/CINT2006/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CINT2006/Makefile?rev=65883&r1=65882&r2=65883&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CINT2006/Makefile (original) +++ test-suite/trunk/External/SPEC/CINT2006/Makefile Mon Mar 2 16:17:26 2009 @@ -16,9 +16,8 @@ 462.libquantum \ 464.h264ref \ 471.omnetpp \ - 473.astar - -# 483.xalancbmk -- Needs C++ Exceptions + 473.astar \ + 483.xalancbmk # Get the $(ARCH) setting include $(LEVEL)/Makefile.config From gohman at apple.com Mon Mar 2 16:46:18 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 22:46:18 -0000 Subject: [llvm-commits] [test-suite] r65887 - /test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile Message-ID: <200903022246.n22MkIMs006409@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 16:46:18 2009 New Revision: 65887 URL: http://llvm.org/viewvc/llvm-project?rev=65887&view=rev Log: Fix STDOUT_FILENAME for 450.soplex, and add "ref" parameters. Modified: test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile Modified: test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile?rev=65887&r1=65886&r2=65887&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile (original) +++ test-suite/trunk/External/SPEC/CFP2006/450.soplex/Makefile Mon Mar 2 16:46:18 2009 @@ -18,7 +18,15 @@ ifeq ($(RUN_TYPE),test) FP_TOLERANCE = 0.0001 RUN_OPTIONS = -s1 -e -m10000 test.mps + STDOUT_FILENAME := test.out else +ifeq ($(RUN_TYPE),train) FP_TOLERANCE = 20 RUN_OPTIONS = -s1 -e -m1200 train.mps + STDOUT_FILENAME := train.out +else + FP_TOLERANCE = 0.02 + RUN_OPTIONS = -s1 -e -m3500 ref.mps + STDOUT_FILENAME := ref.out +endif endif From gohman at apple.com Mon Mar 2 16:46:33 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Mar 2009 22:46:33 -0000 Subject: [llvm-commits] [test-suite] r65888 - /test-suite/trunk/External/SPEC/CFP2006/Makefile Message-ID: <200903022246.n22MkXH3006432@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 16:46:33 2009 New Revision: 65888 URL: http://llvm.org/viewvc/llvm-project?rev=65888&view=rev Log: Enable 450.soplex. Modified: test-suite/trunk/External/SPEC/CFP2006/Makefile Modified: test-suite/trunk/External/SPEC/CFP2006/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CFP2006/Makefile?rev=65888&r1=65887&r2=65888&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CFP2006/Makefile (original) +++ test-suite/trunk/External/SPEC/CFP2006/Makefile Mon Mar 2 16:46:33 2009 @@ -11,7 +11,8 @@ 433.milc \ 444.namd \ 447.dealII \ - 470.lbm + 470.lbm \ + 450.soplex ifdef USE_F95 PARALLEL_DIRS += \ @@ -40,7 +41,6 @@ endif # End USE_F95 # These compile but need other things to run: -# 450.soplex - enter.cc:535, works at -O0, not at -O2 # 453.povray - c++ exceptions # 465.tonto - infinite loop, works at -O0, not at -O2 # 482.sphinx3 - generates control file at run time From dpatel at apple.com Mon Mar 2 16:50:58 2009 From: dpatel at apple.com (Devang Patel) Date: Mon, 02 Mar 2009 22:50:58 -0000 Subject: [llvm-commits] [llvm] r65889 - /llvm/trunk/lib/Transforms/IPO/StripSymbols.cpp Message-ID: <200903022250.n22Mowwm006664@zion.cs.uiuc.edu> Author: dpatel Date: Mon Mar 2 16:50:58 2009 New Revision: 65889 URL: http://llvm.org/viewvc/llvm-project?rev=65889&view=rev Log: Remove all dbg symobls, including those with circular references. This is ugly, but I can't figure out a quick way out of this. Modified: llvm/trunk/lib/Transforms/IPO/StripSymbols.cpp Modified: llvm/trunk/lib/Transforms/IPO/StripSymbols.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/IPO/StripSymbols.cpp?rev=65889&r1=65888&r2=65889&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/IPO/StripSymbols.cpp (original) +++ llvm/trunk/lib/Transforms/IPO/StripSymbols.cpp Mon Mar 2 16:50:58 2009 @@ -185,6 +185,21 @@ // llvm.dbg.region.end calls, and any globals they point to if now dead. bool StripDebugInfo(Module &M) { + SmallPtrSet llvmUsedValues; + findUsedValues(M, llvmUsedValues); + + // Delete all dbg variables. + for (Module::global_iterator I = M.global_begin(), E = M.global_end(); + I != E; ++I) { + GlobalVariable *GV = dyn_cast(I); + if (!GV) continue; + if (!GV->use_empty() && llvmUsedValues.count(I) == 0) { + if (strncmp(GV->getNameStart(), "llvm.dbg", 8) == 0) { + GV->replaceAllUsesWith(UndefValue::get(GV->getType())); + } + } + } + Function *FuncStart = M.getFunction("llvm.dbg.func.start"); Function *StopPoint = M.getFunction("llvm.dbg.stoppoint"); Function *RegionStart = M.getFunction("llvm.dbg.region.start"); @@ -263,9 +278,6 @@ Declare->eraseFromParent(); } - SmallPtrSet llvmUsedValues; - findUsedValues(M, llvmUsedValues); - // llvm.dbg.compile_units and llvm.dbg.subprograms are marked as linkonce // but since we are removing all debug information, make them internal now. // FIXME: Use private linkage maybe? From dpatel at apple.com Mon Mar 2 17:01:36 2009 From: dpatel at apple.com (Devang Patel) Date: Mon, 02 Mar 2009 23:01:36 -0000 Subject: [llvm-commits] [test-suite] r65890 - /test-suite/trunk/TEST.dbgopt.Makefile Message-ID: <200903022301.n22N1aTb007133@zion.cs.uiuc.edu> Author: dpatel Date: Mon Mar 2 17:01:35 2009 New Revision: 65890 URL: http://llvm.org/viewvc/llvm-project?rev=65890&view=rev Log: Use separate invocation of 'opt' so that pass manager can not play tricks here. Modified: test-suite/trunk/TEST.dbgopt.Makefile Modified: test-suite/trunk/TEST.dbgopt.Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/TEST.dbgopt.Makefile?rev=65890&r1=65889&r2=65890&view=diff ============================================================================== --- test-suite/trunk/TEST.dbgopt.Makefile (original) +++ test-suite/trunk/TEST.dbgopt.Makefile Mon Mar 2 17:01:35 2009 @@ -19,9 +19,9 @@ Output/%.diff: %.cpp Output/.dir $(LLVMGXX) $(LOPT) $(LDIS) $(LLVMGXX) $*.cpp -g --emit-llvm -c -o Output/$*.bc - $(LOPT) Output/$*.bc -strip-nondebug -strip-debug -std-compile-opts -strip -f -o Output/$*.t.bc + $(LOPT) Output/$*.bc -strip-nondebug -strip-debug | $(LOPT) -std-compile-opts | $(LOPT) -strip -f -o Output/$*.t.bc $(LDIS) Output/$*.t.bc -f -o Output/$*.first.ll - $(LOPT) Output/$*.bc -strip-nondebug -std-compile-opts -strip-debug -strip -f -o Output/$*.t.bc + $(LOPT) Output/$*.bc -strip-nondebug | $(LOPT) -std-compile-opts | $(LOPT) -strip-debug -strip -f -o Output/$*.t.bc $(LDIS) Output/$*.t.bc -f -o Output/$*.second.ll @-if diff Output/$*.first.ll Output/$*.second.ll > Output/$*.diff; then \ echo "--------- TEST-PASS: $*"; \ @@ -32,9 +32,9 @@ Output/%.diff: %.c Output/.dir $(LLVMGCC) $(LOPT) $(LDIS) $(LLVMGCC) $*.c -g --emit-llvm -c -o Output/$*.bc - $(LOPT) Output/$*.bc -strip-nondebug -strip-debug -std-compile-opts -strip -f -o Output/$*.t.bc + $(LOPT) Output/$*.bc -strip-nondebug -strip-debug | $(LOPT) -std-compile-opts | $(LOPT) -strip -f -o Output/$*.t.bc $(LDIS) Output/$*.t.bc -f -o Output/$*.first.ll - $(LOPT) Output/$*.bc -strip-nondebug -std-compile-opts -strip-debug -strip -f -o Output/$*.t.bc + $(LOPT) Output/$*.bc -strip-nondebug | $(LOPT) -std-compile-opts | $(LOPT) -strip-debug -strip -f -o Output/$*.t.bc $(LDIS) Output/$*.t.bc -f -o Output/$*.second.ll @-if diff Output/$*.first.ll Output/$*.second.ll > Output/$*.diff; then \ echo "--------- TEST-PASS: $*"; \ From kremenek at apple.com Mon Mar 2 17:06:46 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 02 Mar 2009 23:06:46 -0000 Subject: [llvm-commits] [llvm] r65893 - /llvm/tags/checker/checker-0.167/ Message-ID: <200903022306.n22N6l1f007477@zion.cs.uiuc.edu> Author: kremenek Date: Mon Mar 2 17:06:46 2009 New Revision: 65893 URL: http://llvm.org/viewvc/llvm-project?rev=65893&view=rev Log: Tagging checker-0.167. Added: llvm/tags/checker/checker-0.167/ - copied from r65892, llvm/trunk/ From natebegeman at mac.com Mon Mar 2 17:10:14 2009 From: natebegeman at mac.com (Nate Begeman) Date: Mon, 02 Mar 2009 23:10:14 -0000 Subject: [llvm-commits] [llvm] r65895 - /llvm/trunk/lib/ExecutionEngine/JIT/JITEmitter.cpp Message-ID: <200903022310.n22NAEFv007636@zion.cs.uiuc.edu> Author: sampo Date: Mon Mar 2 17:10:14 2009 New Revision: 65895 URL: http://llvm.org/viewvc/llvm-project?rev=65895&view=rev Log: Fix the calculation for how big the allocated stub needs to be. Modified: llvm/trunk/lib/ExecutionEngine/JIT/JITEmitter.cpp Modified: llvm/trunk/lib/ExecutionEngine/JIT/JITEmitter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/JIT/JITEmitter.cpp?rev=65895&r1=65894&r2=65895&view=diff ============================================================================== --- llvm/trunk/lib/ExecutionEngine/JIT/JITEmitter.cpp (original) +++ llvm/trunk/lib/ExecutionEngine/JIT/JITEmitter.cpp Mon Mar 2 17:10:14 2009 @@ -1329,7 +1329,7 @@ return; // Calculate the size of the stub info - unsigned offset = 4 + 4 * GVs.size(); + unsigned offset = 4 + 4 * GVs.size() + sizeof(intptr_t) * GVs.size(); SmallVector Offsets; for (unsigned i = 0; i != GVs.size(); ++i) { From isanbard at gmail.com Mon Mar 2 17:13:18 2009 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 02 Mar 2009 23:13:18 -0000 Subject: [llvm-commits] [llvm] r65896 - in /llvm/trunk/tools/bugpoint: ExecutionDriver.cpp ToolRunner.cpp ToolRunner.h Message-ID: <200903022313.n22NDIRm007819@zion.cs.uiuc.edu> Author: void Date: Mon Mar 2 17:13:18 2009 New Revision: 65896 URL: http://llvm.org/viewvc/llvm-project?rev=65896&view=rev Log: Add a "-gcc-tool-args" option. This option acts like the "-tool-args" option, but passes the arguments to the "gcc" invocation instead of to the "llc" invocation. Modified: llvm/trunk/tools/bugpoint/ExecutionDriver.cpp llvm/trunk/tools/bugpoint/ToolRunner.cpp llvm/trunk/tools/bugpoint/ToolRunner.h Modified: llvm/trunk/tools/bugpoint/ExecutionDriver.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/bugpoint/ExecutionDriver.cpp?rev=65896&r1=65895&r2=65896&view=diff ============================================================================== --- llvm/trunk/tools/bugpoint/ExecutionDriver.cpp (original) +++ llvm/trunk/tools/bugpoint/ExecutionDriver.cpp Mon Mar 2 17:13:18 2009 @@ -111,6 +111,11 @@ SafeToolArgv("safe-tool-args", cl::Positional, cl::desc("..."), cl::ZeroOrMore, cl::PositionalEatsArgs); + + cl::list + GCCToolArgv("gcc-tool-args", cl::Positional, + cl::desc("..."), + cl::ZeroOrMore, cl::PositionalEatsArgs); } //===----------------------------------------------------------------------===// @@ -132,7 +137,8 @@ case AutoPick: InterpreterSel = RunCBE; Interpreter = - AbstractInterpreter::createCBE(getToolName(), Message, &ToolArgv); + AbstractInterpreter::createCBE(getToolName(), Message, &ToolArgv, + &GCCToolArgv); if (!Interpreter) { InterpreterSel = RunJIT; Interpreter = AbstractInterpreter::createJIT(getToolName(), Message, @@ -141,7 +147,7 @@ if (!Interpreter) { InterpreterSel = RunLLC; Interpreter = AbstractInterpreter::createLLC(getToolName(), Message, - &ToolArgv); + &ToolArgv, &GCCToolArgv); } if (!Interpreter) { InterpreterSel = RunLLI; @@ -160,7 +166,7 @@ case RunLLC: case LLC_Safe: Interpreter = AbstractInterpreter::createLLC(getToolName(), Message, - &ToolArgv); + &ToolArgv, &GCCToolArgv); break; case RunJIT: Interpreter = AbstractInterpreter::createJIT(getToolName(), Message, @@ -169,7 +175,7 @@ case RunCBE: case CBE_bug: Interpreter = AbstractInterpreter::createCBE(getToolName(), Message, - &ToolArgv); + &ToolArgv, &GCCToolArgv); break; case Custom: Interpreter = AbstractInterpreter::createCustom(getToolName(), Message, @@ -196,7 +202,8 @@ SafeInterpreterSel = RunLLC; SafeToolArgs.push_back("--relocation-model=pic"); SafeInterpreter = AbstractInterpreter::createLLC(Path, Message, - &SafeToolArgs); + &SafeToolArgs, + &GCCToolArgv); } // In "llc-safe" mode, default to using LLC as the "safe" backend. @@ -205,7 +212,8 @@ SafeInterpreterSel = RunLLC; SafeToolArgs.push_back("--relocation-model=pic"); SafeInterpreter = AbstractInterpreter::createLLC(Path, Message, - &SafeToolArgs); + &SafeToolArgs, + &GCCToolArgv); } // Pick a backend that's different from the test backend. The JIT and @@ -215,7 +223,8 @@ InterpreterSel != RunCBE) { SafeInterpreterSel = RunCBE; SafeInterpreter = AbstractInterpreter::createCBE(Path, Message, - &SafeToolArgs); + &SafeToolArgs, + &GCCToolArgv); } if (!SafeInterpreter && InterpreterSel != RunLLC && @@ -223,7 +232,8 @@ SafeInterpreterSel = RunLLC; SafeToolArgs.push_back("--relocation-model=pic"); SafeInterpreter = AbstractInterpreter::createLLC(Path, Message, - &SafeToolArgs); + &SafeToolArgs, + &GCCToolArgv); } if (!SafeInterpreter) { SafeInterpreterSel = AutoPick; @@ -233,11 +243,13 @@ case RunLLC: SafeToolArgs.push_back("--relocation-model=pic"); SafeInterpreter = AbstractInterpreter::createLLC(Path, Message, - &SafeToolArgs); + &SafeToolArgs, + &GCCToolArgv); break; case RunCBE: SafeInterpreter = AbstractInterpreter::createCBE(Path, Message, - &SafeToolArgs); + &SafeToolArgs, + &GCCToolArgv); break; case Custom: SafeInterpreter = AbstractInterpreter::createCustom(Path, Message, @@ -250,7 +262,7 @@ } if (!SafeInterpreter) { std::cout << Message << "\nExiting.\n"; exit(1); } - gcc = GCC::create(getToolName(), Message); + gcc = GCC::create(getToolName(), Message, &GCCToolArgv); if (!gcc) { std::cout << Message << "\nExiting.\n"; exit(1); } // If there was an error creating the selected interpreter, quit with error. @@ -406,7 +418,7 @@ } try { ReferenceOutputFile = executeProgramSafely(Filename); - std::cout << "Reference output is: " << ReferenceOutputFile << "\n\n"; + std::cout << "\nReference output is: " << ReferenceOutputFile << "\n\n"; } catch (ToolExecutionError &TEE) { std::cerr << TEE.what(); if (Interpreter != SafeInterpreter) { Modified: llvm/trunk/tools/bugpoint/ToolRunner.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/bugpoint/ToolRunner.cpp?rev=65896&r1=65895&r2=65896&view=diff ============================================================================== --- llvm/trunk/tools/bugpoint/ToolRunner.cpp (original) +++ llvm/trunk/tools/bugpoint/ToolRunner.cpp Mon Mar 2 17:13:18 2009 @@ -344,7 +344,8 @@ FileRemover OutFileRemover(OutputAsmFile); std::vector GCCArgs(ArgsForGCC); - GCCArgs.insert(GCCArgs.end(),SharedLibs.begin(),SharedLibs.end()); + GCCArgs.insert(GCCArgs.end(), SharedLibs.begin(), SharedLibs.end()); + GCCArgs.insert(GCCArgs.end(), gccArgs.begin(), gccArgs.end()); // Assuming LLC worked, compile the result with GCC and run it. return gcc->ExecuteProgram(OutputAsmFile.toString(), Args, GCC::AsmFile, @@ -356,7 +357,8 @@ /// LLC *AbstractInterpreter::createLLC(const std::string &ProgramPath, std::string &Message, - const std::vector *Args) { + const std::vector *Args, + const std::vector *GCCArgs) { std::string LLCPath = FindExecutable("llc", ProgramPath).toString(); if (LLCPath.empty()) { Message = "Cannot find `llc' in executable directory or PATH!\n"; @@ -364,12 +366,12 @@ } Message = "Found llc: " + LLCPath + "\n"; - GCC *gcc = GCC::create(ProgramPath, Message); + GCC *gcc = GCC::create(ProgramPath, Message, GCCArgs); if (!gcc) { std::cerr << Message << "\n"; exit(1); } - return new LLC(LLCPath, gcc, Args); + return new LLC(LLCPath, gcc, Args, GCCArgs); } //===---------------------------------------------------------------------===// @@ -509,7 +511,8 @@ FileRemover CFileRemove(OutputCFile); std::vector GCCArgs(ArgsForGCC); - GCCArgs.insert(GCCArgs.end(),SharedLibs.begin(),SharedLibs.end()); + GCCArgs.insert(GCCArgs.end(), SharedLibs.begin(), SharedLibs.end()); + return gcc->ExecuteProgram(OutputCFile.toString(), Args, GCC::CFile, InputFile, OutputFile, GCCArgs, Timeout, MemoryLimit); @@ -519,7 +522,8 @@ /// CBE *AbstractInterpreter::createCBE(const std::string &ProgramPath, std::string &Message, - const std::vector *Args) { + const std::vector *Args, + const std::vector *GCCArgs) { sys::Path LLCPath = FindExecutable("llc", ProgramPath); if (LLCPath.isEmpty()) { Message = @@ -528,7 +532,7 @@ } Message = "Found llc: " + LLCPath.toString() + "\n"; - GCC *gcc = GCC::create(ProgramPath, Message); + GCC *gcc = GCC::create(ProgramPath, Message, GCCArgs); if (!gcc) { std::cerr << Message << "\n"; exit(1); @@ -551,6 +555,10 @@ GCCArgs.push_back(GCCPath.c_str()); + for (std::vector::const_iterator + I = gccArgs.begin(), E = gccArgs.end(); I != E; ++I) + GCCArgs.push_back(I->c_str()); + // Specify -x explicitly in case the extension is wonky GCCArgs.push_back("-x"); if (fileType == CFile) { @@ -725,7 +733,8 @@ /// create - Try to find the `gcc' executable /// -GCC *GCC::create(const std::string &ProgramPath, std::string &Message) { +GCC *GCC::create(const std::string &ProgramPath, std::string &Message, + const std::vector *Args) { sys::Path GCCPath = FindExecutable("gcc", ProgramPath); if (GCCPath.isEmpty()) { Message = "Cannot find `gcc' in executable directory or PATH!\n"; @@ -737,5 +746,5 @@ RemoteClientPath = FindExecutable(RemoteClient.c_str(), ProgramPath); Message = "Found gcc: " + GCCPath.toString() + "\n"; - return new GCC(GCCPath, RemoteClientPath); + return new GCC(GCCPath, RemoteClientPath, Args); } Modified: llvm/trunk/tools/bugpoint/ToolRunner.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/bugpoint/ToolRunner.h?rev=65896&r1=65895&r2=65896&view=diff ============================================================================== --- llvm/trunk/tools/bugpoint/ToolRunner.h (original) +++ llvm/trunk/tools/bugpoint/ToolRunner.h Mon Mar 2 17:13:18 2009 @@ -43,14 +43,19 @@ // GCC abstraction // class GCC { - sys::Path GCCPath; // The path to the gcc executable - sys::Path RemoteClientPath; // The path to the rsh / ssh executable - GCC(const sys::Path &gccPath, const sys::Path &RemotePath) - : GCCPath(gccPath), RemoteClientPath(RemotePath) { } + sys::Path GCCPath; // The path to the gcc executable. + sys::Path RemoteClientPath; // The path to the rsh / ssh executable. + std::vector gccArgs; // GCC-specific arguments. + GCC(const sys::Path &gccPath, const sys::Path &RemotePath, + const std::vector *GCCArgs) + : GCCPath(gccPath), RemoteClientPath(RemotePath) { + if (GCCArgs) gccArgs = *GCCArgs; + } public: enum FileType { AsmFile, CFile }; - static GCC *create(const std::string &ProgramPath, std::string &Message); + static GCC *create(const std::string &ProgramPath, std::string &Message, + const std::vector *Args); /// ExecuteProgram - Execute the program specified by "ProgramFile" (which is /// either a .s file, or a .c file, specified by FileType), with the specified @@ -86,9 +91,11 @@ class AbstractInterpreter { public: static CBE *createCBE(const std::string &ProgramPath, std::string &Message, - const std::vector *Args = 0); + const std::vector *Args = 0, + const std::vector *GCCArgs = 0); static LLC *createLLC(const std::string &ProgramPath, std::string &Message, - const std::vector *Args = 0); + const std::vector *Args = 0, + const std::vector *GCCArgs = 0); static AbstractInterpreter* createLLI(const std::string &ProgramPath, std::string &Message, @@ -139,14 +146,15 @@ // CBE Implementation of AbstractIntepreter interface // class CBE : public AbstractInterpreter { - sys::Path LLCPath; // The path to the `llc' executable - std::vector ToolArgs; // Extra args to pass to LLC + sys::Path LLCPath; // The path to the `llc' executable. + std::vector ToolArgs; // Extra args to pass to LLC. GCC *gcc; public: CBE(const sys::Path &llcPath, GCC *Gcc, - const std::vector *Args) : LLCPath(llcPath), gcc(Gcc) { + const std::vector *Args) + : LLCPath(llcPath), gcc(Gcc) { ToolArgs.clear (); - if (Args) { ToolArgs = *Args; } + if (Args) ToolArgs = *Args; } ~CBE() { delete gcc; } @@ -180,14 +188,18 @@ // LLC Implementation of AbstractIntepreter interface // class LLC : public AbstractInterpreter { - std::string LLCPath; // The path to the LLC executable - std::vector ToolArgs; // Extra args to pass to LLC + std::string LLCPath; // The path to the LLC executable. + std::vector ToolArgs; // Extra args to pass to LLC. + std::vector gccArgs; // Extra args to pass to GCC. GCC *gcc; public: LLC(const std::string &llcPath, GCC *Gcc, - const std::vector *Args) : LLCPath(llcPath), gcc(Gcc) { - ToolArgs.clear (); - if (Args) { ToolArgs = *Args; } + const std::vector *Args, + const std::vector *GCCArgs) + : LLCPath(llcPath), gcc(Gcc) { + ToolArgs.clear(); + if (Args) ToolArgs = *Args; + if (GCCArgs) gccArgs = *GCCArgs; } ~LLC() { delete gcc; } From isanbard at gmail.com Mon Mar 2 17:15:59 2009 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 02 Mar 2009 23:15:59 -0000 Subject: [llvm-commits] [llvm] r65897 - /llvm/trunk/docs/CommandGuide/bugpoint.pod Message-ID: <200903022316.n22NG03W007964@zion.cs.uiuc.edu> Author: void Date: Mon Mar 2 17:15:59 2009 New Revision: 65897 URL: http://llvm.org/viewvc/llvm-project?rev=65897&view=rev Log: Document the -gcc-tool-args bugpoint option. Modified: llvm/trunk/docs/CommandGuide/bugpoint.pod Modified: llvm/trunk/docs/CommandGuide/bugpoint.pod URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CommandGuide/bugpoint.pod?rev=65897&r1=65896&r2=65897&view=diff ============================================================================== --- llvm/trunk/docs/CommandGuide/bugpoint.pod (original) +++ llvm/trunk/docs/CommandGuide/bugpoint.pod Mon Mar 2 17:15:59 2009 @@ -59,9 +59,14 @@ =item B<--safe-tool-args> I -Pass all arguments specified after --safe-tool-args to the "safe" execution +Pass all arguments specified after B<--safe-tool-args> to the "safe" execution tool. +=item B<--gcc-tool-args> I + +Pass all arguments specified after B<--gcc-tool-args> to the invocation of +B. + =item B<--disable-{dce,simplifycfg}> Do not run the specified passes to clean up and reduce the size of the test From isanbard at gmail.com Mon Mar 2 17:22:16 2009 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 02 Mar 2009 23:22:16 -0000 Subject: [llvm-commits] [llvm] r65898 - /llvm/branches/Apple/Dib/lib/ExecutionEngine/JIT/JITEmitter.cpp Message-ID: <200903022322.n22NMGYL008332@zion.cs.uiuc.edu> Author: void Date: Mon Mar 2 17:22:16 2009 New Revision: 65898 URL: http://llvm.org/viewvc/llvm-project?rev=65898&view=rev Log: --- Merging (from foreign repository) r65895 into '.': U lib/ExecutionEngine/JIT/JITEmitter.cpp Fix the calculation for how big the allocated stub needs to be. Modified: llvm/branches/Apple/Dib/lib/ExecutionEngine/JIT/JITEmitter.cpp Modified: llvm/branches/Apple/Dib/lib/ExecutionEngine/JIT/JITEmitter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/branches/Apple/Dib/lib/ExecutionEngine/JIT/JITEmitter.cpp?rev=65898&r1=65897&r2=65898&view=diff ============================================================================== --- llvm/branches/Apple/Dib/lib/ExecutionEngine/JIT/JITEmitter.cpp (original) +++ llvm/branches/Apple/Dib/lib/ExecutionEngine/JIT/JITEmitter.cpp Mon Mar 2 17:22:16 2009 @@ -1329,7 +1329,7 @@ return; // Calculate the size of the stub info - unsigned offset = 4 + 4 * GVs.size(); + unsigned offset = 4 + 4 * GVs.size() + sizeof(intptr_t) * GVs.size(); SmallVector Offsets; for (unsigned i = 0; i != GVs.size(); ++i) { From bob.wilson at apple.com Mon Mar 2 17:24:17 2009 From: bob.wilson at apple.com (Bob Wilson) Date: Mon, 02 Mar 2009 23:24:17 -0000 Subject: [llvm-commits] [llvm] r65899 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAGNodes.h lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/Target/PowerPC/PPCISelLowering.cpp Message-ID: <200903022324.n22NOHaW008454@zion.cs.uiuc.edu> Author: bwilson Date: Mon Mar 2 17:24:16 2009 New Revision: 65899 URL: http://llvm.org/viewvc/llvm-project?rev=65899&view=rev Log: Generalize BuildVectorSDNode::isConstantSplat to use APInts and handle arbitrary vector sizes. Add an optional MinSplatBits parameter to specify a minimum for the splat element size. Update the PPC target to use the revised interface. Modified: llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp Modified: llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h?rev=65899&r1=65898&r2=65899&view=diff ============================================================================== --- llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h (original) +++ llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h Mon Mar 2 17:24:16 2009 @@ -1933,13 +1933,18 @@ /// BUILD_VECTORs. class BuildVectorSDNode : public SDNode { public: - /// isConstantSplat - check if this is a constant splat, and if so, return - /// the splat element value in SplatBits. Any undefined bits in that value - /// are set to zero, and the corresponding bits in the SplatUndef mask are - /// set. The SplatSize value is set to the splat element size in bytes. - /// HasAnyUndefs is set to true if any bits in the vector are undefined. - bool isConstantSplat(unsigned &SplatBits, unsigned &SplatUndef, - unsigned &SplatSize, bool &HasAnyUndefs); + /// isConstantSplat - Check if this is a constant splat, and if so, find the + /// smallest element size that splats the vector. If MinSplatBits is + /// nonzero, the element size must be at least that large. Note that the + /// splat element may be the entire vector (i.e., a one element vector). + /// Returns the splat element value in SplatValue. Any undefined bits in + /// that value are zero, and the corresponding bits in the SplatUndef mask + /// are set. The SplatBitSize value is set to the splat element size in + /// bits. HasAnyUndefs is set to true if any bits in the vector are + /// undefined. + bool isConstantSplat(APInt &SplatValue, APInt &SplatUndef, + unsigned &SplatBitSize, bool &HasAnyUndefs, + unsigned MinSplatBits = 0); static inline bool classof(const BuildVectorSDNode *) { return true; } static inline bool classof(const SDNode *N) { Modified: llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp?rev=65899&r1=65898&r2=65899&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp (original) +++ llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp Mon Mar 2 17:24:16 2009 @@ -5555,93 +5555,64 @@ return Val.ConstVal->getType(); } -// If this is a splat (repetition) of a value across the whole vector, return -// the smallest size that splats it. For example, "0x01010101010101..." is a -// splat of 0x01, 0x0101, and 0x01010101. We return SplatBits = 0x01 and -// SplatSize = 1 byte. -bool BuildVectorSDNode::isConstantSplat(unsigned &SplatBits, - unsigned &SplatUndef, - unsigned &SplatSize, - bool &HasAnyUndefs) { - uint64_t Bits128[2]; - uint64_t Undef128[2]; - - // If this is a vector of constants or undefs, get the bits. A bit in - // UndefBits is set if the corresponding element of the vector is an - // ISD::UNDEF value. For undefs, the corresponding VectorBits values are - // zero. - - // Start with zero'd results. - Bits128[0] = Bits128[1] = Undef128[0] = Undef128[1] = 0; - - unsigned EltBitSize = getOperand(0).getValueType().getSizeInBits(); - for (unsigned i = 0, e = getNumOperands(); i != e; ++i) { +bool BuildVectorSDNode::isConstantSplat(APInt &SplatValue, + APInt &SplatUndef, + unsigned &SplatBitSize, + bool &HasAnyUndefs, + unsigned MinSplatBits) { + MVT VT = getValueType(0); + assert(VT.isVector() && "Expected a vector type"); + unsigned sz = VT.getSizeInBits(); + if (MinSplatBits > sz) + return false; + + SplatValue = APInt(sz, 0); + SplatUndef = APInt(sz, 0); + + // Get the bits. Bits with undefined values (when the corresponding element + // of the vector is an ISD::UNDEF value) are set in SplatUndef and cleared + // in SplatValue. If any of the values are not constant, give up and return + // false. + unsigned int nOps = getNumOperands(); + assert(nOps > 0 && "isConstantSplat has 0-size build vector"); + unsigned EltBitSize = VT.getVectorElementType().getSizeInBits(); + for (unsigned i = 0; i < nOps; ++i) { SDValue OpVal = getOperand(i); + unsigned BitPos = i * EltBitSize; - unsigned PartNo = i >= e/2; // In the upper 128 bits? - unsigned SlotNo = e/2 - (i & (e/2-1))-1; // Which subpiece of the uint64_t. - - uint64_t EltBits = 0; - if (OpVal.getOpcode() == ISD::UNDEF) { - uint64_t EltUndefBits = ~0U >> (32-EltBitSize); - Undef128[PartNo] |= EltUndefBits << (SlotNo*EltBitSize); - continue; - } else if (ConstantSDNode *CN = dyn_cast(OpVal)) { - EltBits = CN->getZExtValue() & (~0U >> (32-EltBitSize)); - } else if (ConstantFPSDNode *CN = dyn_cast(OpVal)) { - assert(CN->getValueType(0) == MVT::f32 && - "Only one legal FP vector type!"); - EltBits = FloatToBits(CN->getValueAPF().convertToFloat()); - } else { - // Nonconstant element. + if (OpVal.getOpcode() == ISD::UNDEF) + SplatUndef |= APInt::getBitsSet(sz, BitPos, BitPos +EltBitSize); + else if (ConstantSDNode *CN = dyn_cast(OpVal)) + SplatValue |= APInt(CN->getAPIntValue()).zext(sz) << BitPos; + else if (ConstantFPSDNode *CN = dyn_cast(OpVal)) + SplatValue |= CN->getValueAPF().bitcastToAPInt().zext(sz) << BitPos; + else return false; - } - - Bits128[PartNo] |= EltBits << (SlotNo*EltBitSize); } - // Don't let undefs prevent splats from matching. See if the top 64-bits are - // the same as the lower 64-bits, ignoring undefs. - if ((Bits128[0] & ~Undef128[1]) != (Bits128[1] & ~Undef128[0])) - return false; // Can't be a splat if two pieces don't match. - - uint64_t Bits64 = Bits128[0] | Bits128[1]; - uint64_t Undef64 = Undef128[0] & Undef128[1]; - - // Check that the top 32-bits are the same as the lower 32-bits, ignoring - // undefs. - if ((Bits64 & (~Undef64 >> 32)) != ((Bits64 >> 32) & ~Undef64)) - return false; // Can't be a splat if two pieces don't match. - - HasAnyUndefs = (Undef128[0] | Undef128[1]) != 0; - - uint32_t Bits32 = uint32_t(Bits64) | uint32_t(Bits64 >> 32); - uint32_t Undef32 = uint32_t(Undef64) & uint32_t(Undef64 >> 32); - - // If the top 16-bits are different than the lower 16-bits, ignoring - // undefs, we have an i32 splat. - if ((Bits32 & (~Undef32 >> 16)) != ((Bits32 >> 16) & ~Undef32)) { - SplatBits = Bits32; - SplatUndef = Undef32; - SplatSize = 4; - return true; - } + // The build_vector is all constants or undefs. Find the smallest element + // size that splats the vector. - uint16_t Bits16 = uint16_t(Bits32) | uint16_t(Bits32 >> 16); - uint16_t Undef16 = uint16_t(Undef32) & uint16_t(Undef32 >> 16); + HasAnyUndefs = (SplatUndef != 0); + while (sz > 8) { - // If the top 8-bits are different than the lower 8-bits, ignoring - // undefs, we have an i16 splat. - if ((Bits16 & (uint16_t(~Undef16) >> 8)) != ((Bits16 >> 8) & ~Undef16)) { - SplatBits = Bits16; - SplatUndef = Undef16; - SplatSize = 2; - return true; + unsigned HalfSize = sz / 2; + APInt HighValue = APInt(SplatValue).lshr(HalfSize).trunc(HalfSize); + APInt LowValue = APInt(SplatValue).trunc(HalfSize); + APInt HighUndef = APInt(SplatUndef).lshr(HalfSize).trunc(HalfSize); + APInt LowUndef = APInt(SplatUndef).trunc(HalfSize); + + // If the two halves do not match (ignoring undef bits), stop here. + if ((HighValue & ~LowUndef) != (LowValue & ~HighUndef) || + MinSplatBits > HalfSize) + break; + + SplatValue = HighValue | LowValue; + SplatUndef = HighUndef & LowUndef; + + sz = HalfSize; } - // Otherwise, we have an 8-bit splat. - SplatBits = uint8_t(Bits16) | uint8_t(Bits16 >> 8); - SplatUndef = uint8_t(Undef16) & uint8_t(Undef16 >> 8); - SplatSize = 1; + SplatBitSize = sz; return true; } Modified: llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp?rev=65899&r1=65898&r2=65899&view=diff ============================================================================== --- llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp (original) +++ llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp Mon Mar 2 17:24:16 2009 @@ -3167,13 +3167,16 @@ BuildVectorSDNode *BVN = dyn_cast(Op.getNode()); assert(BVN != 0 && "Expected a BuildVectorSDNode in LowerBUILD_VECTOR"); - // If this is a splat (repetition) of a value across the whole vector, return - // the smallest size that splats it. For example, "0x01010101010101..." is a - // splat of 0x01, 0x0101, and 0x01010101. We return SplatBits = 0x01 and - // SplatSize = 1 byte. - unsigned SplatBits, SplatUndef, SplatSize; + // Check if this is a splat of a constant value. + APInt APSplatBits, APSplatUndef; + unsigned SplatBitSize; bool HasAnyUndefs; - if (BVN->isConstantSplat(SplatBits, SplatUndef, SplatSize, HasAnyUndefs)) { + if (BVN->isConstantSplat(APSplatBits, APSplatUndef, SplatBitSize, + HasAnyUndefs) && + SplatBitSize <= 32) { + unsigned SplatBits = APSplatBits.getZExtValue(); + unsigned SplatUndef = APSplatUndef.getZExtValue(); + unsigned SplatSize = SplatBitSize / 8; // First, handle single instruction cases. @@ -3189,7 +3192,8 @@ } // If the sign extended value is in the range [-16,15], use VSPLTI[bhw]. - int32_t SextVal= int32_t(SplatBits << (32-8*SplatSize)) >> (32-8*SplatSize); + int32_t SextVal= (int32_t(SplatBits << (32-SplatBitSize)) >> + (32-SplatBitSize)); if (SextVal >= -16 && SextVal <= 15) return BuildSplatI(SextVal, SplatSize, Op.getValueType(), DAG, dl); @@ -3221,7 +3225,6 @@ } // Check to see if this is a wide variety of vsplti*, binop self cases. - unsigned SplatBitSize = SplatSize*8; static const signed char SplatCsts[] = { -1, 1, -2, 2, -3, 3, -4, 4, -5, 5, -6, 6, -7, 7, -8, 8, -9, 9, -10, 10, -11, 11, -12, 12, -13, 13, 14, -14, 15, -15, -16 From kremenek at apple.com Mon Mar 2 17:36:40 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 02 Mar 2009 23:36:40 -0000 Subject: [llvm-commits] [llvm] r65900 - /llvm/tags/checker/checker-0.167/ Message-ID: <200903022336.n22NaeYK008913@zion.cs.uiuc.edu> Author: kremenek Date: Mon Mar 2 17:36:39 2009 New Revision: 65900 URL: http://llvm.org/viewvc/llvm-project?rev=65900&view=rev Log: Removing checker-0.167. Removed: llvm/tags/checker/checker-0.167/ From kremenek at apple.com Mon Mar 2 17:39:46 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 02 Mar 2009 23:39:46 -0000 Subject: [llvm-commits] [llvm] r65904 - /llvm/tags/checker/checker-0.167/ Message-ID: <200903022339.n22NdkxR009037@zion.cs.uiuc.edu> Author: kremenek Date: Mon Mar 2 17:39:46 2009 New Revision: 65904 URL: http://llvm.org/viewvc/llvm-project?rev=65904&view=rev Log: Tagging checker-0.167. Added: llvm/tags/checker/checker-0.167/ - copied from r65903, llvm/trunk/ From dpatel at apple.com Mon Mar 2 17:39:15 2009 From: dpatel at apple.com (Devang Patel) Date: Mon, 02 Mar 2009 23:39:15 -0000 Subject: [llvm-commits] [llvm] r65902 - in /llvm/trunk: lib/Transforms/Scalar/LoopIndexSplit.cpp test/Transforms/LoopIndexSplit/2009-03-02-UpdateIterationSpace-crash.ll Message-ID: <200903022339.n22NdFau009002@zion.cs.uiuc.edu> Author: dpatel Date: Mon Mar 2 17:39:14 2009 New Revision: 65902 URL: http://llvm.org/viewvc/llvm-project?rev=65902&view=rev Log: If branch conditions' one successor is dominating another non-latch successor then this loop's iteration space can not be restricted. In this example block bb5 is always executed. Added: llvm/trunk/test/Transforms/LoopIndexSplit/2009-03-02-UpdateIterationSpace-crash.ll Modified: llvm/trunk/lib/Transforms/Scalar/LoopIndexSplit.cpp Modified: llvm/trunk/lib/Transforms/Scalar/LoopIndexSplit.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/LoopIndexSplit.cpp?rev=65902&r1=65901&r2=65902&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Scalar/LoopIndexSplit.cpp (original) +++ llvm/trunk/lib/Transforms/Scalar/LoopIndexSplit.cpp Mon Mar 2 17:39:14 2009 @@ -532,6 +532,21 @@ BasicBlock *ExitingBlock = ExitCondition->getParent(); if (!cleanBlock(ExitingBlock)) return false; + // If the merge point for BR is not loop latch then skip this loop. + if (BR->getSuccessor(0) != Latch) { + DominanceFrontier::iterator DF0 = DF->find(BR->getSuccessor(0)); + assert (DF0 != DF->end() && "Unable to find dominance frontier"); + if (!DF0->second.count(Latch)) + return false; + } + + if (BR->getSuccessor(1) != Latch) { + DominanceFrontier::iterator DF1 = DF->find(BR->getSuccessor(1)); + assert (DF1 != DF->end() && "Unable to find dominance frontier"); + if (!DF1->second.count(Latch)) + return false; + } + // Verify that loop exiting block has only two predecessor, where one pred // is split condition block. The other predecessor will become exiting block's // dominator after CFG is updated. TODO : Handle CFG's where exiting block has Added: llvm/trunk/test/Transforms/LoopIndexSplit/2009-03-02-UpdateIterationSpace-crash.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/LoopIndexSplit/2009-03-02-UpdateIterationSpace-crash.ll?rev=65902&view=auto ============================================================================== --- llvm/trunk/test/Transforms/LoopIndexSplit/2009-03-02-UpdateIterationSpace-crash.ll (added) +++ llvm/trunk/test/Transforms/LoopIndexSplit/2009-03-02-UpdateIterationSpace-crash.ll Mon Mar 2 17:39:14 2009 @@ -0,0 +1,64 @@ +; RUN: llvm-as < %s | opt -loop-index-split -disable-output + %struct.CGPoint = type { double, double } + %struct.IBCFMutableDictionary = type { %struct.NSMutableArray, %struct.__CFDictionary*, %struct.NSSortDescriptor*, %struct.NSSortDescriptor* } + %struct.IBInspectorMode = type opaque + %struct.IBInspectorModeView = type { %struct.NSView, %struct.NSArray*, %struct.IBCFMutableDictionary*, %struct.IBInspectorMode*, %struct.IBInspectorMode*, %struct.IBInspectorMode*, %struct.objc_selector*, %struct.NSObject* } + %struct.NSArray = type { %struct.NSObject } + %struct.NSImage = type { %struct.NSObject, %struct.NSArray*, %struct.CGPoint, %struct.__imageFlags, %struct.NSObject*, %struct._NSImageAuxiliary* } + %struct.NSMutableArray = type { %struct.NSArray } + %struct.NSObject = type { %struct.objc_class* } + %struct.NSRect = type { %struct.CGPoint, %struct.CGPoint } + %struct.NSResponder = type { %struct.NSObject, %struct.NSObject* } + %struct.NSSortDescriptor = type { %struct.NSObject, i64, %struct.NSArray*, %struct.objc_selector*, %struct.NSObject* } + %struct.NSURL = type { %struct.NSObject, %struct.NSArray*, %struct.NSURL*, i8*, i8* } + %struct.NSView = type { %struct.NSResponder, %struct.NSRect, %struct.NSRect, %struct.NSObject*, %struct.NSObject*, %struct.NSWindow*, %struct.NSObject*, %struct.NSObject*, %struct.NSObject*, %struct.NSObject*, %struct._NSViewAuxiliary*, %struct._VFlags, %struct.__VFlags2 } + %struct.NSWindow = type { %struct.NSResponder, %struct.NSRect, %struct.NSObject*, %struct.NSObject*, %struct.NSResponder*, %struct.NSView*, %struct.NSView*, %struct.NSObject*, %struct.NSObject*, i32, i64, i32, %struct.NSArray*, %struct.NSObject*, i8, i8, i8, i8, i8*, i8*, %struct.NSImage*, i32, %struct.NSMutableArray*, %struct.NSURL*, %struct.CGPoint*, %struct.NSArray*, %struct.NSArray*, %struct.__wFlags, %struct.NSObject*, %struct.NSView*, %struct.NSWindowAuxiliary* } + %struct.NSWindowAuxiliary = type opaque + %struct._NSImageAuxiliary = type opaque + %struct._NSViewAuxiliary = type opaque + %struct._VFlags = type <{ i8, i8, i8, i8 }> + %struct.__CFDictionary = type opaque + %struct.__VFlags2 = type <{ i32 }> + %struct.__imageFlags = type <{ i8, [3 x i8] }> + %struct.__wFlags = type <{ i8, i8, i8, i8, i8, i8, i8, i8 }> + %struct.objc_class = type opaque + %struct.objc_selector = type opaque + +define %struct.NSArray* @"\01-[IBInspectorModeView calculateModeRects]"(%struct.IBInspectorModeView* %self, %struct.objc_selector* %_cmd) optsize ssp { +entry: + br i1 false, label %bb7, label %bb + +bb: ; preds = %entry + br i1 false, label %bb.nph, label %bb7.loopexit + +bb.nph: ; preds = %bb + br label %bb1 + +bb1: ; preds = %bb6, %bb.nph + %midx.01 = phi i64 [ %3, %bb6 ], [ 0, %bb.nph ] ; [#uses=3] + %0 = icmp sge i64 %midx.01, 0 ; [#uses=1] + %1 = icmp sle i64 %midx.01, 0 ; [#uses=1] + %2 = and i1 %0, %1 ; [#uses=1] + br i1 %2, label %bb4, label %bb5 + +bb4: ; preds = %bb1 + br label %bb5 + +bb5: ; preds = %bb4, %bb1 + %modeWidth.0 = phi double [ 0.000000e+00, %bb1 ], [ 0.000000e+00, %bb4 ] ; [#uses=0] + %3 = add i64 %midx.01, 1 ; [#uses=1] + br label %bb6 + +bb6: ; preds = %bb5 + %4 = icmp slt i64 0, 0 ; [#uses=1] + br i1 %4, label %bb1, label %bb6.bb7.loopexit_crit_edge + +bb6.bb7.loopexit_crit_edge: ; preds = %bb6 + br label %bb7.loopexit + +bb7.loopexit: ; preds = %bb6.bb7.loopexit_crit_edge, %bb + br label %bb7 + +bb7: ; preds = %bb7.loopexit, %entry + ret %struct.NSArray* null +} From dpatel at apple.com Mon Mar 2 18:28:44 2009 From: dpatel at apple.com (Devang Patel) Date: Tue, 03 Mar 2009 00:28:44 -0000 Subject: [llvm-commits] [llvm] r65908 - /llvm/trunk/lib/Transforms/IPO/FunctionAttrs.cpp Message-ID: <200903030028.n230Si46010930@zion.cs.uiuc.edu> Author: dpatel Date: Mon Mar 2 18:28:44 2009 New Revision: 65908 URL: http://llvm.org/viewvc/llvm-project?rev=65908&view=rev Log: Ignore debug info intrinsics. Modified: llvm/trunk/lib/Transforms/IPO/FunctionAttrs.cpp Modified: llvm/trunk/lib/Transforms/IPO/FunctionAttrs.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/IPO/FunctionAttrs.cpp?rev=65908&r1=65907&r2=65908&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/IPO/FunctionAttrs.cpp (original) +++ llvm/trunk/lib/Transforms/IPO/FunctionAttrs.cpp Mon Mar 2 18:28:44 2009 @@ -22,7 +22,7 @@ #include "llvm/Transforms/IPO.h" #include "llvm/CallGraphSCCPass.h" #include "llvm/GlobalVariable.h" -#include "llvm/Instructions.h" +#include "llvm/IntrinsicInst.h" #include "llvm/Analysis/CallGraph.h" #include "llvm/Analysis/CaptureTracking.h" #include "llvm/ADT/SmallSet.h" @@ -137,6 +137,10 @@ continue; } + // Ignore dbg info intrinsics. + if (isa(I)) + continue; + // Any remaining instructions need to be taken seriously! Check if they // read or write memory. if (I->mayWriteToMemory()) From dalej at apple.com Mon Mar 2 19:09:09 2009 From: dalej at apple.com (Dale Johannesen) Date: Tue, 03 Mar 2009 01:09:09 -0000 Subject: [llvm-commits] [llvm] r65910 - in /llvm/trunk: include/llvm/Transforms/Utils/BasicBlockUtils.h lib/Transforms/Scalar/InstructionCombining.cpp lib/Transforms/Utils/BasicBlockUtils.cpp Message-ID: <200903030109.n2319Aka012343@zion.cs.uiuc.edu> Author: johannes Date: Mon Mar 2 19:09:07 2009 New Revision: 65910 URL: http://llvm.org/viewvc/llvm-project?rev=65910&view=rev Log: When sinking an insn in InstCombine bring its debug info with it. Don't count debug info insns against the scan maximum in FindAvailableLoadedValue (lest they affect codegen). Modified: llvm/trunk/include/llvm/Transforms/Utils/BasicBlockUtils.h llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp Modified: llvm/trunk/include/llvm/Transforms/Utils/BasicBlockUtils.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/Utils/BasicBlockUtils.h?rev=65910&r1=65909&r2=65910&view=diff ============================================================================== --- llvm/trunk/include/llvm/Transforms/Utils/BasicBlockUtils.h (original) +++ llvm/trunk/include/llvm/Transforms/Utils/BasicBlockUtils.h Mon Mar 2 19:09:07 2009 @@ -60,6 +60,11 @@ // void ReplaceInstWithInst(Instruction *From, Instruction *To); +/// CopyPrecedingStopPoint - If I is immediately preceded by a StopPoint, +/// make a copy of the stoppoint before InsertPos (presumably before copying +/// or moving I). +void CopyPrecedingStopPoint(Instruction *I, BasicBlock::iterator InsertPos); + /// FindAvailableLoadedValue - Scan the ScanBB block backwards (starting at the /// instruction before ScanFrom) checking to see if we have the value at the /// memory address *Ptr locally available within a small number of instructions. Modified: llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp?rev=65910&r1=65909&r2=65910&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp (original) +++ llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Mon Mar 2 19:09:07 2009 @@ -12374,6 +12374,7 @@ BasicBlock::iterator InsertPos = DestBlock->getFirstNonPHI(); + CopyPrecedingStopPoint(I, InsertPos); I->moveBefore(InsertPos); ++NumSunkInst; return true; Modified: llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp?rev=65910&r1=65909&r2=65910&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp (original) +++ llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp Mon Mar 2 19:09:07 2009 @@ -15,6 +15,7 @@ #include "llvm/Transforms/Utils/BasicBlockUtils.h" #include "llvm/Function.h" #include "llvm/Instructions.h" +#include "llvm/IntrinsicInst.h" #include "llvm/Constant.h" #include "llvm/Type.h" #include "llvm/Analysis/AliasAnalysis.h" @@ -471,11 +472,18 @@ } while (ScanFrom != ScanBB->begin()) { + // We must ignore debug info directives when counting (otherwise they + // would affect codegen). + Instruction *Inst = --ScanFrom; + if (isa(Inst)) + continue; + // Restore ScanFrom to expected value in case next test succeeds + ScanFrom++; + // Don't scan huge blocks. if (MaxInstsToScan-- == 0) return 0; - Instruction *Inst = --ScanFrom; - + --ScanFrom; // If this is a load of Ptr, the loaded value is available. if (LoadInst *LI = dyn_cast(Inst)) if (AreEquivalentAddressValues(LI->getOperand(0), Ptr)) @@ -523,3 +531,18 @@ // block. return 0; } + +/// CopyPrecedingStopPoint - If I is immediately preceded by a StopPoint, +/// make a copy of the stoppoint before InsertPos (presumably before copying +/// or moving I). +void llvm::CopyPrecedingStopPoint(Instruction *I, + BasicBlock::iterator InsertPos) { + if (I != I->getParent()->begin()) { + BasicBlock::iterator BBI = I; --BBI; + if (DbgStopPointInst *DSPI = dyn_cast(BBI)) { + DbgStopPointInst *newDSPI = + reinterpret_cast(DSPI->clone()); + newDSPI->insertBefore(InsertPos); + } + } +} From dalej at apple.com Mon Mar 2 19:10:02 2009 From: dalej at apple.com (Dale Johannesen) Date: Tue, 03 Mar 2009 01:10:02 -0000 Subject: [llvm-commits] [llvm] r65911 - /llvm/trunk/test/DebugInfo/2009-03-02-sink.ll Message-ID: <200903030110.n231A2Qc012382@zion.cs.uiuc.edu> Author: johannes Date: Mon Mar 2 19:10:01 2009 New Revision: 65911 URL: http://llvm.org/viewvc/llvm-project?rev=65911&view=rev Log: Testcase for line number sinking in InstCombine. Added: llvm/trunk/test/DebugInfo/2009-03-02-sink.ll Added: llvm/trunk/test/DebugInfo/2009-03-02-sink.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/2009-03-02-sink.ll?rev=65911&view=auto ============================================================================== --- llvm/trunk/test/DebugInfo/2009-03-02-sink.ll (added) +++ llvm/trunk/test/DebugInfo/2009-03-02-sink.ll Mon Mar 2 19:10:01 2009 @@ -0,0 +1,57 @@ +; RUN: llvm-as < %s | opt -instcombine | llvm-dis | %prcontext sdiv 1 | grep {stoppoint(i32 2} +; RUN: llvm-as < %s | opt -instcombine | llvm-dis | %prcontext add 1 | grep {stoppoint(i32 3} +; ModuleID = 'sink.c' +target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128" +target triple = "i386-apple-darwin9.6" + %llvm.dbg.anchor.type = type { i32, i32 } + %llvm.dbg.basictype.type = type { i32, { }*, i8*, { }*, i32, i64, i64, i64, i32, i32 } + %llvm.dbg.compile_unit.type = type { i32, { }*, i32, i8*, i8*, i8*, i1, i1, i8*, i32 } + %llvm.dbg.composite.type = type { i32, { }*, i8*, { }*, i32, i64, i64, i64, i32, { }*, { }*, i32 } + %llvm.dbg.subprogram.type = type { i32, { }*, { }*, i8*, i8*, i8*, { }*, i32, { }*, i1, i1 } + %llvm.dbg.variable.type = type { i32, { }*, i8*, { }*, i32, { }* } + at llvm.dbg.compile_units = linkonce constant %llvm.dbg.anchor.type { i32 458752, i32 17 }, section "llvm.metadata" ; <%llvm.dbg.anchor.type*> [#uses=1] + at .str = internal constant [7 x i8] c"sink.c\00", section "llvm.metadata" ; <[7 x i8]*> [#uses=1] + at .str1 = internal constant [23 x i8] c"/Volumes/MacOS9/tests/\00", section "llvm.metadata" ; <[23 x i8]*> [#uses=1] + at .str2 = internal constant [52 x i8] c"4.2.1 (Based on Apple Inc. build 5641) (LLVM build)\00", section "llvm.metadata" ; <[52 x i8]*> [#uses=1] + at llvm.dbg.compile_unit = internal constant %llvm.dbg.compile_unit.type { i32 458769, { }* bitcast (%llvm.dbg.anchor.type* @llvm.dbg.compile_units to { }*), i32 1, i8* getelementptr ([7 x i8]* @.str, i32 0, i32 0), i8* getelementptr ([23 x i8]* @.str1, i32 0, i32 0), i8* getelementptr ([52 x i8]* @.str2, i32 0, i32 0), i1 true, i1 false, i8* null, i32 0 }, section "llvm.metadata" ; <%llvm.dbg.compile_unit.type*> [#uses=1] + at .str3 = internal constant [4 x i8] c"int\00", section "llvm.metadata" ; <[4 x i8]*> [#uses=1] + at llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { i32 458788, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i8* getelementptr ([4 x i8]* @.str3, i32 0, i32 0), { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i32 0, i64 32, i64 32, i64 0, i32 0, i32 5 }, section "llvm.metadata" ; <%llvm.dbg.basictype.type*> [#uses=1] + at llvm.dbg.array = internal constant [4 x { }*] [{ }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*), { }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*), { }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*), { }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*)], section "llvm.metadata" ; <[4 x { }*]*> [#uses=1] + at llvm.dbg.composite = internal constant %llvm.dbg.composite.type { i32 458773, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i8* null, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i32 0, i64 0, i64 0, i64 0, i32 0, { }* null, { }* bitcast ([4 x { }*]* @llvm.dbg.array to { }*), i32 0 }, section "llvm.metadata" ; <%llvm.dbg.composite.type*> [#uses=1] + at llvm.dbg.subprograms = linkonce constant %llvm.dbg.anchor.type { i32 458752, i32 46 }, section "llvm.metadata" ; <%llvm.dbg.anchor.type*> [#uses=1] + at .str4 = internal constant [4 x i8] c"foo\00", section "llvm.metadata" ; <[4 x i8]*> [#uses=1] + at llvm.dbg.subprogram = internal constant %llvm.dbg.subprogram.type { i32 458798, { }* bitcast (%llvm.dbg.anchor.type* @llvm.dbg.subprograms to { }*), { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i8* getelementptr ([4 x i8]* @.str4, i32 0, i32 0), i8* getelementptr ([4 x i8]* @.str4, i32 0, i32 0), i8* null, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i32 1, { }* bitcast (%llvm.dbg.composite.type* @llvm.dbg.composite to { }*), i1 false, i1 true }, section "llvm.metadata" ; <%llvm.dbg.subprogram.type*> [#uses=1] + at .str5 = internal constant [2 x i8] c"c\00", section "llvm.metadata" ; <[2 x i8]*> [#uses=1] + at llvm.dbg.variable = internal constant %llvm.dbg.variable.type { i32 459009, { }* bitcast (%llvm.dbg.subprogram.type* @llvm.dbg.subprogram to { }*), i8* getelementptr ([2 x i8]* @.str5, i32 0, i32 0), { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i32 1, { }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*) }, section "llvm.metadata" ; <%llvm.dbg.variable.type*> [#uses=1] + at .str6 = internal constant [2 x i8] c"a\00", section "llvm.metadata" ; <[2 x i8]*> [#uses=1] + at llvm.dbg.variable7 = internal constant %llvm.dbg.variable.type { i32 459009, { }* bitcast (%llvm.dbg.subprogram.type* @llvm.dbg.subprogram to { }*), i8* getelementptr ([2 x i8]* @.str6, i32 0, i32 0), { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i32 1, { }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*) }, section "llvm.metadata" ; <%llvm.dbg.variable.type*> [#uses=1] + at .str8 = internal constant [2 x i8] c"b\00", section "llvm.metadata" ; <[2 x i8]*> [#uses=1] + at llvm.dbg.variable9 = internal constant %llvm.dbg.variable.type { i32 459009, { }* bitcast (%llvm.dbg.subprogram.type* @llvm.dbg.subprogram to { }*), i8* getelementptr ([2 x i8]* @.str8, i32 0, i32 0), { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i32 1, { }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*) }, section "llvm.metadata" ; <%llvm.dbg.variable.type*> [#uses=1] + +define i32 @foo(i32 %c, i32 %a, i32 %b) nounwind { +entry: + call void @llvm.dbg.func.start({ }* bitcast (%llvm.dbg.subprogram.type* @llvm.dbg.subprogram to { }*)) + call void @llvm.dbg.stoppoint(i32 2, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) + %tmp.2 = sdiv i32 %a, %b ; [#uses=1] + call void @llvm.dbg.stoppoint(i32 3, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) + %tmp.9 = add i32 %b, %a ; [#uses=1] + call void @llvm.dbg.stoppoint(i32 4, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) + %tmp.10 = icmp ne i32 %c, 0 ; [#uses=1] + br i1 %tmp.10, label %bb, label %bb1 + +bb: ; preds = %entry + call void @llvm.dbg.stoppoint(i32 5, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) + ret i32 %tmp.9 + +bb1: ; preds = %entry + call void @llvm.dbg.stoppoint(i32 7, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) + ret i32 %tmp.2 +} + +declare void @llvm.dbg.func.start({ }*) nounwind + +declare void @llvm.dbg.declare({ }*, { }*) nounwind + +declare void @llvm.dbg.stoppoint(i32, i32, { }*) nounwind + +declare void @llvm.dbg.region.end({ }*) nounwind From isanbard at gmail.com Mon Mar 2 19:22:11 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 03 Mar 2009 01:22:11 -0000 Subject: [llvm-commits] [llvm-gcc-4.2] r65913 - in /llvm-gcc-4.2/branches/Apple/Dib: ./ gcc/ gcc/config/ gcc/config/arm/ gcc/config/i386/ gcc/cp/ gcc/testsuite/g++.apple/ gcc/testsuite/gcc.apple/ Message-ID: <200903030122.n231MCLQ012823@zion.cs.uiuc.edu> Author: void Date: Mon Mar 2 19:22:11 2009 New Revision: 65913 URL: http://llvm.org/viewvc/llvm-project?rev=65913&view=rev Log: Update Dib to TOT with Apple GCC 5641. Added: llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/block-no-trampoline-1.C llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/weak-2.C llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/gcc.apple/6515001.c Modified: llvm-gcc-4.2/branches/Apple/Dib/configure.in llvm-gcc-4.2/branches/Apple/Dib/driverdriver.c llvm-gcc-4.2/branches/Apple/Dib/gcc/ChangeLog.apple llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.c llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.h llvm-gcc-4.2/branches/Apple/Dib/gcc/c-decl.c llvm-gcc-4.2/branches/Apple/Dib/gcc/c-typeck.c llvm-gcc-4.2/branches/Apple/Dib/gcc/config/arm/arm.h llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.c llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.h llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/darwin.h llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/predicates.md llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/ChangeLog.apple llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/decl.c llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/semantics.c llvm-gcc-4.2/branches/Apple/Dib/gcc/dwarf2out.c llvm-gcc-4.2/branches/Apple/Dib/gcc/gimplify.c llvm-gcc-4.2/branches/Apple/Dib/gcc/ifcvt.c llvm-gcc-4.2/branches/Apple/Dib/gcc/tree.h llvm-gcc-4.2/branches/Apple/Dib/gcc/version.c Modified: llvm-gcc-4.2/branches/Apple/Dib/configure.in URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/configure.in?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/configure.in (original) +++ llvm-gcc-4.2/branches/Apple/Dib/configure.in Mon Mar 2 19:22:11 2009 @@ -989,8 +989,10 @@ i[[3456789]]86-*-darwin*) host_makefile_frag="config/mh-x86-darwin" # gcc can default to x86_64 code generation, avoid that - CC="${CC-gcc} -m32" - CXX="${CXX-g++} -m32" + if test "${build}" = "${host}"; then + CC="${CC-gcc} -m32" + CXX="${CXX-g++} -m32" + fi ;; # APPLE LOCAL end dynamic-no-pic powerpc-*-aix*) Modified: llvm-gcc-4.2/branches/Apple/Dib/driverdriver.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/driverdriver.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/driverdriver.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/driverdriver.c Mon Mar 2 19:22:11 2009 @@ -1,4 +1,5 @@ /* APPLE LOCAL file driver driver */ + /* Darwin driver program that handles -arch commands and invokes appropriate compiler driver. Copyright (C) 2004, 2005 Free Software Foundation, Inc. @@ -76,6 +77,8 @@ int dash_dynamiclib_seen = 0; int verbose_flag = 0; int save_temps_seen = 0; +int dash_m32_seen = 0; +int dash_m64_seen = 0; /* Support at the max 10 arch. at a time. This is historical limit. */ #define MAX_ARCHES 10 @@ -190,27 +193,35 @@ static const char * get_arch_name (const char *name) { - const NXArchInfo * a_info; + NXArchInfo * a_info; const NXArchInfo * all_info; cpu_type_t cputype; struct arch_config_guess_map *map; const char *aname; - if (name) - { - /* Find config name based on arch name. */ - aname = NULL; - map = arch_config_map; - while (map->arch_name) - { - if (!strcmp (map->arch_name, name)) - return name; - else map++; - } - a_info = NXGetArchInfoFromName (name); + if (name) { + /* Find config name based on arch name. */ + aname = NULL; + map = arch_config_map; + while (map->arch_name) { + if (!strcmp (map->arch_name, name)) + return name; + else map++; } - else - a_info = NXGetLocalArchInfo (); + a_info = (NXArchInfo *) NXGetArchInfoFromName (name); + } else { + a_info = (NXArchInfo *) NXGetLocalArchInfo(); + if (a_info) { + if (dash_m32_seen) { + /* If -m32 is seen then do not change cpu type. */ + } else if (dash_m64_seen) { + /* If -m64 is seen then enable CPU_ARCH_ABI64. */ + a_info->cputype |= CPU_ARCH_ABI64; + } else if (sizeof (long) == 8) + /* On x86, by default (name is NULL here) enable 64 bit code. */ + a_info->cputype |= CPU_ARCH_ABI64; + } + } if (!a_info) fatal ("Invalid arch name : %s", name); @@ -639,7 +650,6 @@ for (i = 1; i < new_argc; i++) { - if (ifn && ifn->name && !strcmp (new_argv[i], ifn->name)) { /* This argument is one of the input file. */ @@ -1371,6 +1381,16 @@ new_argv[new_argc++] = argv[i]; dash_capital_m_seen = 1; } + else if (!strcmp (argv[i], "-m32")) + { + new_argv[new_argc++] = argv[i]; + dash_m32_seen = 1; + } + else if (!strcmp (argv[i], "-m64")) + { + new_argv[new_argc++] = argv[i]; + dash_m64_seen = 1; + } else if (!strcmp (argv[i], "-dynamiclib")) { new_argv[new_argc++] = argv[i]; @@ -1505,6 +1525,9 @@ fatal ("no input files"); #endif + if (num_arches == 0) + add_arch(get_arch_name(NULL)); + if (num_arches > 1) { if (preprocessed_output_request @@ -1517,22 +1540,15 @@ Invoke appropriate compiler driver. FAT build is not required in this case. */ - if (num_arches == 0 || num_arches == 1) + if (num_arches == 1) { int arch_specific_argc; const char **arch_specific_argv; - /* If no -arch is specified than use host compiler driver. */ - if (num_arches == 0) - new_argv[0] = get_driver_name (get_arch_name (NULL)); - else if (num_arches == 1) - { - /* Find compiler driver based on -arch and add approriate - -m* argument. */ - new_argv[0] = get_driver_name (get_arch_name (arches[0])); - new_argc = new_argc + add_arch_options (0, new_argv, new_argc); - } - + /* Find compiler driver based on -arch and add approriate + -m* argument. */ + new_argv[0] = get_driver_name (get_arch_name (arches[0])); + new_argc = new_argc + add_arch_options (0, new_argv, new_argc); #ifdef DEBUG printf ("%s: invoking single driver name = %s\n", progname, new_argv[0]); Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/ChangeLog.apple URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/ChangeLog.apple?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/ChangeLog.apple (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/ChangeLog.apple Mon Mar 2 19:22:11 2009 @@ -1,3 +1,25 @@ +2009-02-11 Fariborz Jahanian + + Radar 6573923 + * c-decl.c (synth_block_byref_id_object_copy_func, + synth_block_byref_id_object_dispose_func): Set BLOCK_BYREF_CALLER + flag in call to copy/dispose helper functions. + * c-common.h (BLOCK_BYREF_CALLER): New flag. + +2009-01-29 Josh Conner + + Radar 6186914, 6541440 + * dwarf2out.c (dwarf_stack_op_name): Handle DW_OP_bit_piece. + (size_of_loc_descr, output_loc_operands): Likewise. + (reg_loc_descriptor): Call TARGET_DWARF2_REG_HANDLER if it is defined. + * config/arm/arm.h (TARGET_DWARF2_REG_HANDLER): Define. + +2009-01-22 Stuart Hastings + + Radar 6515001 + * ifcvt.c(noce_try_cmove_arith): Use a more conservative trap + check. + 2009-01-12 Caroline Tice Radar 6476836 Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.c Mon Mar 2 19:22:11 2009 @@ -5169,6 +5169,16 @@ || TREE_CODE (*node) == VAR_DECL) declare_weak (*node); /* APPLE LOCAL begin weak types 5954418 */ + else if (!DECL_P (*node) + /* If the weak flag can be associated with something else, + prefer that. */ + && (flags & (ATTR_FLAG_FUNCTION_NEXT + |ATTR_FLAG_DECL_NEXT + |ATTR_FLAG_ARRAY_NEXT))) + { + *no_add_attrs = true; + return tree_cons (name, args, NULL_TREE); + } else if (! targetm.cxx.class_data_always_comdat () && TREE_CODE (*node) == RECORD_TYPE) { Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.h?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.h (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/c-common.h Mon Mar 2 19:22:11 2009 @@ -1139,7 +1139,8 @@ BLOCK_FIELD_IS_OBJECT = 3, /* id, NSObject, __attribute__((NSObject)), block, ... */ BLOCK_FIELD_IS_BLOCK = 7, /* a block variable */ BLOCK_FIELD_IS_BYREF = 8, /* the on stack structure holding the __block variable */ - BLOCK_FIELD_IS_WEAK = 16 /* declared __weak, only used in byref copy helpers */ + BLOCK_FIELD_IS_WEAK = 16, /* declared __weak, only used in byref copy helpers */ + BLOCK_BYREF_CALLER = 128 /* called from __block (byref) copy/dispose support routines */ }; /* APPLE LOCAL end radar 5847976 */ /* APPLE LOCAL begin radar 5732232 - blocks */ Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/c-decl.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/c-decl.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/c-decl.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/c-decl.c Mon Mar 2 19:22:11 2009 @@ -3650,6 +3650,11 @@ /* APPLE LOCAL begin radar 6180456 */ /* _Block_object_assign (&_dest->object, _src->object, BLOCK_FIELD_IS_OBJECT) or : _Block_object_assign (&_dest->object, _src->object, BLOCK_FIELD_IS_BLOCK) */ + /* APPLE LOCAL begin radar 6573923 */ + /* Also add the new flag when calling _Block_object_dispose + from byref dispose helper. */ + flag |= BLOCK_BYREF_CALLER; + /* APPLE LOCAL end radar 6573923 */ call_exp = build_block_object_assign_call_exp (build_fold_addr_expr (dst_obj), src_obj, flag); add_stmt (call_exp); /* APPLE LOCAL end radar 6180456 */ @@ -3696,6 +3701,11 @@ /* APPLE LOCAL begin radar 6180456 */ /* _Block_object_dispose(_src->object, BLOCK_FIELD_IS_OBJECT) : or _Block_object_dispose(_src->object, BLOCK_FIELD_IS_BLOCK) */ + /* APPLE LOCAL begin radar 6573923 */ + /* Also add the new flag when calling _Block_object_dispose + from byref dispose helper. */ + flag |= BLOCK_BYREF_CALLER; + /* APPLE LOCAL end radar 6573923 */ rel_exp = build_block_object_dispose_call_exp (src_obj, flag); /* APPLE LOCAL end radar 6180456 */ add_stmt (rel_exp); Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/c-typeck.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/c-typeck.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/c-typeck.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/c-typeck.c Mon Mar 2 19:22:11 2009 @@ -2104,7 +2104,6 @@ in an inline function. Hope it doesn't break something else. */ | TREE_THIS_VOLATILE (array)); - return require_complete_type (fold (rval)); } else Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/config/arm/arm.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/config/arm/arm.h?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/config/arm/arm.h (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/config/arm/arm.h Mon Mar 2 19:22:11 2009 @@ -2700,6 +2700,36 @@ ((FIRST_PARM_OFFSET (FNDECL)) \ + (DECL_STRUCT_FUNCTION (FNDECL))->pretend_args_size) /* APPLE LOCAL end ARM 6148015 */ + +/* APPLE LOCAL begin 6186914 */ +/* As per the ARM ABI, for double-width VFP regs: + Dx = DW_OP_regx(256+x) + For single-width VFP regs: + S[2x] = DW_OP_regx(256 + (x >> 1)) DW_OP_bit piece(32, 0) + S[2x+1] = DW_OP_regx(256 + (x >> 1)) DW_OP_bit_piece (32, 32) + It's unfortunate that we have to put this into inline code, but the + interfaces we need from dwarf2out.c aren't exposed. */ +#define TARGET_DWARF2_REG_HANDLER(reg) \ + do { \ + if (IS_VFP_REGNUM (REGNO (reg)) \ + && (GET_MODE (reg) == SFmode || GET_MODE (reg) == DFmode)) \ + { \ + dw_loc_descr_ref loc_result = NULL; \ + dw_loc_descr_ref temp; \ + unsigned int relative_regno = REGNO (reg) - FIRST_VFP_REGNUM; \ + unsigned int base_reg = 256 + (relative_regno >> 1); \ + temp = one_reg_loc_descriptor (base_reg, initialized); \ + add_loc_descr (&loc_result, temp); \ + if (GET_MODE (reg) == SFmode) \ + { \ + int offset = relative_regno & 0x1 ? 32 : 0; \ + temp = new_loc_descr (DW_OP_bit_piece, 32, offset); \ + add_loc_descr (&loc_result, temp); \ + } \ + return loc_result; \ + } \ + } while (0) +/* APPLE LOCAL end 6186914 */ enum arm_builtins { Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.c Mon Mar 2 19:22:11 2009 @@ -299,12 +299,14 @@ name = XSTR (sym_ref, 0); lprefix = (((name[0] == '*' || name[0] == '&') + /* APPLE LOCAL begin fix-and-continue 6227434 */ && (name[1] == 'L' || (name[1] == '"' && name[2] == 'L') /* Don't indirect writable strings. */ || (name[1] == 'l' && name[2] == 'C'))) || (strncmp (name, "_OBJC_", 6) == 0) || objc_anonymous_local_objc_name (name)); + /* APPLE LOCAL end fix-and-continue 6227434 */ return ! lprefix; } Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.h?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.h (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/config/darwin.h Mon Mar 2 19:22:11 2009 @@ -493,10 +493,12 @@ miphoneos-version-min=*: %(darwin_iphoneos_libgcc); \ shared-libgcc|fexceptions|fgnu-runtime: \ %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4) \ - %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5) \ + "/* APPLE LOCAL link optimizations 6499452 */" \ + %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5) \ -lgcc; \ :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \ - %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5) \ + "/* APPLE LOCAL link optimizations 6499452 */" \ + %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5) \ -lgcc}" /* We specify crt0.o as -lcrt0.o so that ld will search the library path. @@ -510,7 +512,8 @@ #undef STARTFILE_SPEC #define STARTFILE_SPEC \ "%{Zdynamiclib: %(darwin_dylib1) } \ - %{!Zdynamiclib:%{Zbundle:%{!static:-lbundle1.o}} \ + "/* APPLE LOCAL link optimizations 6499452 */" \ + %{!Zdynamiclib:%{Zbundle:%{!static: %(darwin_bundle1)}} \ %{!Zbundle:%{pg:%{static:-lgcrt0.o} \ %{!static:%{object:-lgcrt0.o} \ %{!object:%{preload:-lgcrt0.o} \ @@ -534,6 +537,8 @@ #define DARWIN_EXTRA_SPECS \ { "darwin_crt1", DARWIN_CRT1_SPEC }, \ { "darwin_dylib1", DARWIN_DYLIB1_SPEC }, \ + /* APPLE LOCAL link optimizations 6499452 */ \ + { "darwin_bundle1", DARWIN_BUNDLE1_SPEC }, \ { "darwin_minversion", DARWIN_MINVERSION_SPEC }, \ /* APPLE LOCAL end mainline */ \ /* APPLE LOCAL begin ARM 5683689 */ \ @@ -550,6 +555,11 @@ %:version-compare(!> 10.5 mmacosx-version-min= -ldylib1.o) \ %:version-compare(>= 10.5 mmacosx-version-min= -ldylib1.10.5.o)}" +/* APPLE LOCAL begin link optimizations 6499452 */ +#define DARWIN_BUNDLE1_SPEC \ + "-lbundle1.o" +/* APPLE LOCAL end link optimizations 6499452 */ + #define DARWIN_CRT1_SPEC \ /* APPLE LOCAL ARM 5823776 iphoneos should use crt1.o */ \ "%{miphoneos-version-min=*: -lcrt1.o} \ Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/darwin.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/darwin.h?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/darwin.h (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/darwin.h Mon Mar 2 19:22:11 2009 @@ -141,6 +141,23 @@ /* APPLE LOCAL ARM 5681645 */ #define DARWIN_IPHONEOS_LIBGCC_SPEC "-lgcc_s.10.5 -lgcc" +/* APPLE LOCAL begin link optimizations 6499452 */ +#undef DARWIN_CRT1_SPEC +#define DARWIN_CRT1_SPEC \ + "%:version-compare(!> 10.5 mmacosx-version-min= -lcrt1.o) \ + %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lcrt1.10.5.o) \ + %:version-compare(>= 10.6 mmacosx-version-min= -lcrt1.10.6.o)" + +#undef DARWIN_DYLIB1_SPEC +#define DARWIN_DYLIB1_SPEC \ + "%:version-compare(!> 10.5 mmacosx-version-min= -ldylib1.o) \ + %:version-compare(>< 10.5 10.6 mmacosx-version-min= -ldylib1.10.5.o)" + +#undef DARWIN_BUNDLE1_SPEC +#define DARWIN_BUNDLE1_SPEC \ + "%:version-compare(!> 10.6 mmacosx-version-min= -lbundle1.o)" +/* APPLE LOCAL end link optimizations 6499452 */ + #undef SUBTARGET_EXTRA_SPECS #define SUBTARGET_EXTRA_SPECS \ DARWIN_EXTRA_SPECS \ Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/predicates.md URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/predicates.md?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/predicates.md (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/config/i386/predicates.md Mon Mar 2 19:22:11 2009 @@ -470,7 +470,7 @@ /* LLVM LOCAL begin non-Darwin hack. */ #ifdef TARGET_FIX_AND_CONTINUE if (!indirect_data (op) - || machopic_data_defined_p (op)) + || machopic_data_defined_p (op)) #endif /* LLVM LOCAL end non-Darwin hack */ return 1; Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/ChangeLog.apple URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/ChangeLog.apple?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/ChangeLog.apple (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/ChangeLog.apple Mon Mar 2 19:22:11 2009 @@ -1,3 +1,16 @@ +2009-02-11 Fariborz Jahanian + + Radar 6573923 + * decl.c (synth_block_byref_id_object_copy_func, + synth_block_byref_id_object_dispose_func): Set BLOCK_BYREF_CALLER + flag in call to copy/dispose helper functions. + +2009-02-11 Fariborz Jahanian + + Radar 6545782 + * semantics.c (get_final_block_variable): New + (finish_id_expression): Call get_final_block_variable. + 2008-12-05 Fariborz Jahanian Radar 6413140 Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/decl.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/decl.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/decl.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/decl.c Mon Mar 2 19:22:11 2009 @@ -5365,6 +5365,11 @@ /* APPLE LOCAL begin radar 6180456 */ /* _Block_object_assign (&_dest->object, _src->object, BLOCK_FIELD_IS_OBJECT) or: _Block_object_assign (&_dest->object, _src->object, BLOCK_FIELD_IS_BLOCK) */ + /* APPLE LOCAL begin radar 6573923 */ + /* Also add the new flag when calling _Block_object_dispose + from byref dispose helper. */ + flag |= BLOCK_BYREF_CALLER; + /* APPLE LOCAL end radar 6573923 */ call_exp = build_block_object_assign_call_exp (build_fold_addr_expr (dst_obj), src_obj, flag); add_stmt (call_exp); /* APPLE LOCAL end radar 6180456 */ @@ -5413,6 +5418,11 @@ /* APPLE LOCAL begin radar 6180456 */ /* _Block_object_dispose(_src->object, BLOCK_FIELD_IS_OBJECT) or: _Block_object_dispose(_src->object, BLOCK_FIELD_IS_BLOCK) */ + /* APPLE LOCAL begin radar 6573923 */ + /* Also add the new flag when calling _Block_object_dispose + from byref dispose helper. */ + flag |= BLOCK_BYREF_CALLER; + /* APPLE LOCAL end radar 6573923 */ rel_exp = build_block_object_dispose_call_exp (src_obj, flag); /* APPLE LOCAL end radar 6180456 */ add_stmt (rel_exp); Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/semantics.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/semantics.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/semantics.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/cp/semantics.c Mon Mar 2 19:22:11 2009 @@ -2487,6 +2487,50 @@ return false; } + +/* APPLE LOCAL begin radar 6545782 */ +/** This routine does all the work on use of variables in a block. */ +static tree get_final_block_variable (tree name, tree var) { + tree decl = var; + + if (cur_block + && (TREE_CODE (decl) == VAR_DECL + || TREE_CODE (decl) == PARM_DECL) + && !lookup_name_in_block (name, &decl)) + { + bool gdecl; + /* We are referencing a variable inside a block whose + declaration is outside. */ + gcc_assert (decl && + (TREE_CODE (decl) == VAR_DECL + || TREE_CODE (decl) == PARM_DECL)); + gdecl = (TREE_CODE (decl) == VAR_DECL && + (DECL_EXTERNAL (decl) || TREE_STATIC (decl))); + /* Treat all 'global' variables as 'byref' by default. */ + if (gdecl + || (TREE_CODE (decl) == VAR_DECL && COPYABLE_BYREF_LOCAL_VAR (decl))) + { + /* byref globals are directly accessed. */ + if (!gdecl) + /* build a decl for the byref variable. */ + decl = build_block_byref_decl (name, decl, decl); + else + add_block_global_byref_list (decl); + } + else + { + /* 'byref' globals are never copied-in. So, do not add + them to the copied-in list. */ + if (!in_block_global_byref_list (decl)) + /* build a new decl node. set its type to 'const' type + of the old decl. */ + decl = build_block_ref_decl (name, decl); + } + } + return decl; +} +/* APPLE LOCAL end radar 6545782 */ + /* APPLE LOCAL end blocks 6040305 */ /* ID_EXPRESSION is a representation of parsed, but unprocessed, @@ -2943,48 +2987,12 @@ path = currently_open_derived_class (DECL_CONTEXT (decl)); perform_or_defer_access_check (TYPE_BINFO (path), decl, decl); } - + /* APPLE LOCAL radar 6545782 */ + decl = get_final_block_variable (id_expression, decl); decl = convert_from_reference (decl); } } - /* APPLE LOCAL begin blocks 6040305 (ci) */ - if (cur_block - && (TREE_CODE (decl) == VAR_DECL - || TREE_CODE (decl) == PARM_DECL) - && !lookup_name_in_block (id_expression, &decl)) - { - bool gdecl; - /* We are referencing a variable inside a block whose - declaration is outside. */ - gcc_assert (decl && - (TREE_CODE (decl) == VAR_DECL - || TREE_CODE (decl) == PARM_DECL)); - gdecl = (TREE_CODE (decl) == VAR_DECL && - (DECL_EXTERNAL (decl) || TREE_STATIC (decl))); - /* Treat all 'global' variables as 'byref' by default. */ - if (gdecl - || (TREE_CODE (decl) == VAR_DECL && COPYABLE_BYREF_LOCAL_VAR (decl))) - { - /* byref globals are directly accessed. */ - if (!gdecl) - /* build a decl for the byref variable. */ - decl = build_block_byref_decl (id_expression, decl, decl); - else - add_block_global_byref_list (decl); - } - else - { - /* 'byref' globals are never copied-in. So, do not add - them to the copied-in list. */ - if (!in_block_global_byref_list (decl)) - /* build a new decl node. set its type to 'const' type - of the old decl. */ - decl = build_block_ref_decl (id_expression, decl); - } - } - /* APPLE LOCAL end blocks 6040305 (ci) */ - if (TREE_DEPRECATED (decl)) warn_deprecated_use (decl); Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/dwarf2out.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/dwarf2out.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/dwarf2out.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/dwarf2out.c Mon Mar 2 19:22:11 2009 @@ -3096,6 +3096,10 @@ return "DW_OP_bregx"; case DW_OP_piece: return "DW_OP_piece"; + /* APPLE LOCAL begin 6186914 */ + case DW_OP_bit_piece: + return "DW_OP_bit_piece"; + /* APPLE LOCAL end 6186914 */ case DW_OP_deref_size: return "DW_OP_deref_size"; case DW_OP_xderef_size: @@ -3246,6 +3250,12 @@ case DW_OP_piece: size += size_of_uleb128 (loc->dw_loc_oprnd1.v.val_unsigned); break; + /* APPLE LOCAL begin 6186914 */ + case DW_OP_bit_piece: + size += size_of_uleb128 (loc->dw_loc_oprnd1.v.val_unsigned); + size += size_of_uleb128 (loc->dw_loc_oprnd2.v.val_unsigned); + break; + /* APPLE LOCAL end 6186914 */ case DW_OP_deref_size: case DW_OP_xderef_size: size += 1; @@ -3411,6 +3421,12 @@ case DW_OP_piece: dw2_asm_output_data_uleb128 (val1->v.val_unsigned, NULL); break; + /* APPLE LOCAL begin 6186914 */ + case DW_OP_bit_piece: + dw2_asm_output_data_uleb128 (val1->v.val_unsigned, NULL); + dw2_asm_output_data_uleb128 (val2->v.val_unsigned, NULL); + break; + /* APPLE LOCAL end 6186914 */ case DW_OP_deref_size: case DW_OP_xderef_size: dw2_asm_output_data (1, val1->v.val_int, NULL); @@ -9093,6 +9109,16 @@ regs = targetm.dwarf_register_span (rtl); +/* APPLE LOCAL begin 6186914 */ +#ifdef TARGET_DWARF2_REG_HANDLER + /* If this macro is defined, it should provide any target-specific + register debug info handling. The macro should return the + dw_loc_descr_ref if it performs any alternative handling, and + fall through otherwise. */ + TARGET_DWARF2_REG_HANDLER (rtl); +#endif +/* APPLE LOCAL end 6186914 */ + /* APPLE LOCAL begin track initialization status 4964532 */ if (hard_regno_nregs[REGNO (rtl)][GET_MODE (rtl)] > 1 || regs) return multiple_reg_loc_descriptor (rtl, regs, initialized); Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/gimplify.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/gimplify.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/gimplify.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/gimplify.c Mon Mar 2 19:22:11 2009 @@ -3096,6 +3096,7 @@ gimple_add_tmp_var (new); TREE_STATIC (new) = 1; TREE_READONLY (new) = 1; + /* LLVM LOCAL */ DECL_LLVM_PRIVATE (new) = 1; DECL_INITIAL (new) = ctor; if (align > DECL_ALIGN (new)) Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/ifcvt.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/ifcvt.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/ifcvt.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/ifcvt.c Mon Mar 2 19:22:11 2009 @@ -1409,7 +1409,8 @@ /* ??? We could handle this if we knew that a load from A or B could not fault. This is also true if we've already loaded from the address along the path from ENTRY. */ - else if (may_trap_p (a) || may_trap_p (b)) + /* APPLE LOCAL 6515001 */ + else if (may_trap_after_code_motion_p (a) || may_trap_after_code_motion_p (b)) return FALSE; /* if (test) x = a + b; else x = c - d; Added: llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/block-no-trampoline-1.C URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g%2B%2B.apple/block-no-trampoline-1.C?rev=65913&view=auto ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/block-no-trampoline-1.C (added) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/block-no-trampoline-1.C Mon Mar 2 19:22:11 2009 @@ -0,0 +1,61 @@ +/* APPLE LOCAL file radar 6545782 */ +/* Test that no trampoline is generated for this test case. */ +/* { dg-do run { target *-*-darwin[1-2][0-9]* } } */ +/* { dg-options "-mmacosx-version-min=10.6" { target *-*-darwin* } } */ +/* { dg-skip-if "" { powerpc*-*-darwin* } { "-m64" } { "" } } */ + +#include +#include +#include +#include + +extern "C" void __enable_execute_stack () +{ + abort(); +} + +class A { +public: + void foo(); +}; + +void A::foo() {} + +class B { +public: + void createBlockInMethod(A &a); + void callBlockPassedIn(A &a, void(^aBlock)()); +}; + +void B::createBlockInMethod(A &a) { + void (^block) () = ^{ a.foo(); }; + block(); +} + +void B::callBlockPassedIn(A &a, void(^aBlock)()) { + aBlock(); +} + + +int main(int argc __attribute__((unused)), char **argv) { + __block B b; + __block A a; + + __block int x = 0; + + uint64_t cyclesPerBlock1 = dispatch_benchmark(1000000, ^{ + b.createBlockInMethod(a); + }); + + uint64_t cyclesPerBlock2 = dispatch_benchmark(1000000, ^{ + b.callBlockPassedIn(a, ^{ a.foo(); }); + }); + + fprintf(stdout, "%s: %llu cycles/iter vs. %llu cycles/iter: %5.5f slower\n", argv[0], + cyclesPerBlock1, cyclesPerBlock2, + ((double)cyclesPerBlock1) / ((double)cyclesPerBlock2)); + + return 0; +} + + Added: llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/weak-2.C URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g%2B%2B.apple/weak-2.C?rev=65913&view=auto ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/weak-2.C (added) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/g++.apple/weak-2.C Mon Mar 2 19:22:11 2009 @@ -0,0 +1,7 @@ +/* APPLE LOCAL file weak types 6524730 */ +/* { dg-do compile } */ +/* Radar 6524730 */ + +int * __attribute__((weak)) foo(int * x) { + return x; +} Added: llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/gcc.apple/6515001.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/gcc.apple/6515001.c?rev=65913&view=auto ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/gcc.apple/6515001.c (added) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/testsuite/gcc.apple/6515001.c Mon Mar 2 19:22:11 2009 @@ -0,0 +1,20 @@ +/* APPLE LOCAL file 6515001 */ +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */ +/* { scan-assembler-not "cmove" } */ +typedef struct __NSSymbol* NSSymbol; + +static struct { + unsigned pad[2]; + unsigned n_value; + NSSymbol realSymbol; +} sLastLookup; + +void foo(void *); +void* NSAddressOfSymbol(NSSymbol symbol) +{ + if ( (void*)symbol == (void*)(&sLastLookup) ) + symbol = sLastLookup.realSymbol; + + foo(symbol); + return symbol; +} Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/tree.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/tree.h?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/tree.h (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/tree.h Mon Mar 2 19:22:11 2009 @@ -2916,8 +2916,10 @@ /* Used to indicate that this DECL has weak linkage. */ #define DECL_WEAK(NODE) (DECL_WITH_VIS_CHECK (NODE)->decl_with_vis.weak_flag) +/* LLVM LOCAL begin */ #define DECL_LLVM_PRIVATE(NODE) \ (DECL_WITH_VIS_CHECK (NODE)->decl_with_vis.llvm_private_flag) +/* LLVM LOCAL end */ /* Internal to the gimplifier. Indicates that the value is a formal temporary controlled by the gimplifier. */ Modified: llvm-gcc-4.2/branches/Apple/Dib/gcc/version.c URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/Apple/Dib/gcc/version.c?rev=65913&r1=65912&r2=65913&view=diff ============================================================================== --- llvm-gcc-4.2/branches/Apple/Dib/gcc/version.c (original) +++ llvm-gcc-4.2/branches/Apple/Dib/gcc/version.c Mon Mar 2 19:22:11 2009 @@ -11,12 +11,12 @@ /* APPLE LOCAL begin Apple version */ #ifdef ENABLE_LLVM #ifdef LLVM_VERSION_INFO -#define VERSUFFIX " (Based on Apple Inc. build 5636) (LLVM build " LLVM_VERSION_INFO ")" +#define VERSUFFIX " (Based on Apple Inc. build 5641) (LLVM build " LLVM_VERSION_INFO ")" #else -#define VERSUFFIX " (Based on Apple Inc. build 5636) (LLVM build)" +#define VERSUFFIX " (Based on Apple Inc. build 5641) (LLVM build)" #endif #else -#define VERSUFFIX " (Based on Apple Inc. build 5636)" +#define VERSUFFIX " (Based on Apple Inc. build 5641)" #endif /* APPLE LOCAL end Apple version */ From Nathan.Keynes at Sun.COM Mon Mar 2 19:23:59 2009 From: Nathan.Keynes at Sun.COM (Nathan Keynes) Date: Tue, 03 Mar 2009 11:23:59 +1000 Subject: [llvm-commits] [llvm] r65517 - in /llvm/trunk: Makefile.rules bindings/ocaml/Makefile.ocaml docs/MakefileGuide.html unittests/Makefile.unittest In-Reply-To: <200902260744.n1Q7iHAD027878@zion.cs.uiuc.edu> References: <200902260744.n1Q7iHAD027878@zion.cs.uiuc.edu> Message-ID: <5351FD37-A0D8-4A11-95CD-5D84C9541DAC@sun.com> On 26/02/2009, at 5:44 PM, Nick Lewycky wrote: > Author: nicholas > Date: Thu Feb 26 01:44:16 2009 > New Revision: 65517 > > URL: http://llvm.org/viewvc/llvm-project?rev=65517&view=rev > Log: > Remove libtool. > > Modified: > llvm/trunk/Makefile.rules > llvm/trunk/bindings/ocaml/Makefile.ocaml > llvm/trunk/docs/MakefileGuide.html > llvm/trunk/unittests/Makefile.unittest > > Modified: llvm/trunk/Makefile.rules > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.rules?rev=65517&r1=65516&r2=65517&view=diff This patch broke Solaris builds (and is currently still broken on trunk) - gmake[1]: Entering directory `/zcratch/sunlabs/nkeynes/llvm-65517/utils' if [ ! -f TableGen/Makefile ]; then \ /zcratch/sunlabs/nkeynes/llvm-65517/autoconf/mkinstalldirs TableGen; \ /usr/bin/cp /zcratch/sunlabs/nkeynes/llvm-65517/utils/ TableGen/Makefile TableGen/Makefile; \ fi; \ gmake -C TableGen all gmake[2]: Entering directory `/zcratch/sunlabs/nkeynes/llvm-65517/ utils/TableGen' llvm[2]: Linking Debug executable tblgen g++ -I/zcratch/sunlabs/nkeynes/llvm-65517/include -I/zcratch/sunlabs/ nkeynes/llvm-65517/utils/TableGen -D_DEBUG -include llvm/System/ Solaris.h -D_GNU_SOURCE -D__STD C_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fPIC -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused- parameter -g -Wl,-rpath -Wl,/zcratch/sunlabs/nkeynes/llvm-65517/Debug/bin -export-dynamic -L/ zcratch/sunlabs/nkeynes/llvm-65517/Debug/lib -L/zcratch/sunlabs/ nkeynes/llvm-65517/Debug/lib -o /zcratch/sunlabs/nkeynes/llvm-65517/Debug/bin/tblgen /zcratch/ sunlabs/nkeynes/llvm-65517/utils/TableGen/Debug/AsmWriterEmitter.o / zcratch/sunlabs/nkeynes/llvm-b0rke d/utils/TableGen/Debug/CallingConvEmitter.o /zcratch/sunlabs/nkeynes/ llvm-65517/utils/TableGen/Debug/CodeEmitterGen.o /zcratch/sunlabs/ nkeynes/llvm-65517/utils/TableG en/Debug/CodeGenDAGPatterns.o /zcratch/sunlabs/nkeynes/llvm-65517/ utils/TableGen/Debug/CodeGenInstruction.o /zcratch/sunlabs/nkeynes/ llvm-65517/utils/TableGen/Debug/C odeGenTarget.o /zcratch/sunlabs/nkeynes/llvm-65517/utils/TableGen/ Debug/DAGISelEmitter.o /zcratch/sunlabs/nkeynes/llvm-65517/utils/ TableGen/Debug/FastISelEmitter.o /z cratch/sunlabs/nkeynes/llvm-65517/utils/TableGen/Debug/ InstrEnumEmitter.o /zcratch/sunlabs/nkeynes/llvm-65517/utils/TableGen/ Debug/InstrInfoEmitter.o /zcratch/sunlabs /nkeynes/llvm-65517/utils/TableGen/Debug/IntrinsicEmitter.o /zcratch/ sunlabs/nkeynes/llvm-65517/utils/TableGen/Debug/ LLVMCConfigurationEmitter.o /zcratch/sunlabs/nkey nes/llvm-65517/utils/TableGen/Debug/Record.o /zcratch/sunlabs/nkeynes/ llvm-65517/utils/TableGen/Debug/RegisterInfoEmitter.o /zcratch/sunlabs/ nkeynes/llvm-65517/utils /TableGen/Debug/SubtargetEmitter.o /zcratch/sunlabs/nkeynes/llvm-65517/ utils/TableGen/Debug/TGLexer.o /zcratch/sunlabs/nkeynes/llvm-65517/ utils/TableGen/Debug/TGParse r.o /zcratch/sunlabs/nkeynes/llvm-65517/utils/TableGen/Debug/ TGValueTypes.o /zcratch/sunlabs/nkeynes/llvm-65517/utils/TableGen/ Debug/TableGen.o /zcratch/sunlabs/nkeyn es/llvm-65517/utils/TableGen/Debug/TableGenBackend.o -lLLVMSupport - lLLVMSystem \ -lpthread -lmalloc -lm -lelf ld: fatal: option -dn and -P are incompatible ld: fatal: Flags processing errors collect2: ld returned 1 exit status gmake[2]: *** [/zcratch/sunlabs/nkeynes/llvm-65517/Debug/bin/tblgen] Error 1 gmake[2]: Leaving directory /zcratch/sunlabs/nkeynes/llvm-65517/utils/ TableGen' gmake[1]: *** [TableGen/.makeall] Error 2 gmake[1]: Leaving directory /zcratch/sunlabs/nkeynes/llvm-65517/utils' gmake: *** [all] Error 1 Previous version used the following link line: g++ -I/zcratch/sunlabs/nkeynes/llvm/include -I/zcratch/sunlabs/nkeynes/ llvm/utils/TableGen -D_DEBUG -include llvm/System/Solaris.h - D_GNU_SOURCE -D__STDC_LIMIT_MACROS - D__STDC_CONSTANT_MACROS -g -fPIC -Woverloaded-virtual -pedantic -Wall - W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -g -o / zcratch/sunlabs/nkeynes/ll vm/Debug/bin/tblgen /zcratch/sunlabs/nkeynes/llvm/utils/TableGen/Debug/ AsmWriterEmitter.o /zcratch/sunlabs/nkeynes/llvm/utils/TableGen/Debug/ CallingConvEmitter.o /zcrat ch/sunlabs/nkeynes/llvm/utils/TableGen/Debug/CodeEmitterGen.o /zcratch/ sunlabs/nkeynes/llvm/utils/TableGen/Debug/CodeGenDAGPatterns.o / zcratch/sunlabs/nkeynes/llvm/util s/TableGen/Debug/CodeGenInstruction.o /zcratch/sunlabs/nkeynes/llvm/ utils/TableGen/Debug/CodeGenTarget.o /zcratch/sunlabs/nkeynes/llvm/ utils/TableGen/Debug/DAGISelEmitt er.o /zcratch/sunlabs/nkeynes/llvm/utils/TableGen/Debug/ FastISelEmitter.o /zcratch/sunlabs/nkeynes/llvm/utils/TableGen/Debug/ InstrEnumEmitter.o /zcratch/sunlabs/nkeynes /llvm/utils/TableGen/Debug/InstrInfoEmitter.o /zcratch/sunlabs/nkeynes/ llvm/utils/TableGen/Debug/IntrinsicEmitter.o /zcratch/sunlabs/nkeynes/ llvm/utils/TableGen/Debug/L LVMCConfigurationEmitter.o /zcratch/sunlabs/nkeynes/llvm/utils/ TableGen/Debug/Record.o /zcratch/sunlabs/nkeynes/llvm/utils/TableGen/ Debug/RegisterInfoEmitter.o /zcratch /sunlabs/nkeynes/llvm/utils/TableGen/Debug/SubtargetEmitter.o /zcratch/ sunlabs/nkeynes/llvm/utils/TableGen/Debug/TGLexer.o /zcratch/sunlabs/ nkeynes/llvm/utils/TableGen/ Debug/TGParser.o /zcratch/sunlabs/nkeynes/llvm/utils/TableGen/Debug/ TGValueTypes.o /zcratch/sunlabs/nkeynes/llvm/utils/TableGen/Debug/ TableGen.o /zcratch/sunlabs/nkeyne s/llvm/utils/TableGen/Debug/TableGenBackend.o -L/zcratch/sunlabs/ nkeynes/llvm/Debug/lib -lLLVMSupport -lLLVMSystem -lpthread -lmalloc - lm -lelf -Wl,-R -Wl,/zcratch/sun labs/nkeynes/llvm/Debug/bin The problem seems to be in the -Wl,-rpath -Wl, option - the Solaris linker needs -Wl,-R -Wl, instead - mklib was converting this automatically in previous versions. Cheers, Nathan From dalej at apple.com Mon Mar 2 19:43:03 2009 From: dalej at apple.com (Dale Johannesen) Date: Tue, 03 Mar 2009 01:43:03 -0000 Subject: [llvm-commits] [llvm] r65915 - /llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Message-ID: <200903030143.n231h465013517@zion.cs.uiuc.edu> Author: johannes Date: Mon Mar 2 19:43:03 2009 New Revision: 65915 URL: http://llvm.org/viewvc/llvm-project?rev=65915&view=rev Log: Don't count DebugInfo instructions in another limit (lest they affect codegen). Modified: llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Modified: llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp?rev=65915&r1=65914&r2=65915&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp (original) +++ llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Mon Mar 2 19:43:03 2009 @@ -11439,12 +11439,18 @@ SI.getAlignment())) SI.setAlignment(KnownAlign); - // Do really simple DSE, to catch cases where there are several consequtive + // Do really simple DSE, to catch cases where there are several consecutive // stores to the same location, separated by a few arithmetic operations. This // situation often occurs with bitfield accesses. BasicBlock::iterator BBI = &SI; for (unsigned ScanInsts = 6; BBI != SI.getParent()->begin() && ScanInsts; --ScanInsts) { + // Don't count debug info directives, lest they affect codegen. + if (isa(BBI)) { + ScanInsts++; + --BBI; + continue; + } --BBI; if (StoreInst *PrevSI = dyn_cast(BBI)) { From gohman at apple.com Mon Mar 2 20:25:07 2009 From: gohman at apple.com (Dan Gohman) Date: Tue, 03 Mar 2009 02:25:07 -0000 Subject: [llvm-commits] [test-suite] r65917 - /test-suite/trunk/External/SPEC/CINT2006/483.xalancbmk/Makefile Message-ID: <200903030225.n232P7ZU014726@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 20:25:07 2009 New Revision: 65917 URL: http://llvm.org/viewvc/llvm-project?rev=65917&view=rev Log: This benchmark wants SPEC_CPU_LINUX on "Linux" targets. Modified: test-suite/trunk/External/SPEC/CINT2006/483.xalancbmk/Makefile Modified: test-suite/trunk/External/SPEC/CINT2006/483.xalancbmk/Makefile URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/External/SPEC/CINT2006/483.xalancbmk/Makefile?rev=65917&r1=65916&r2=65917&view=diff ============================================================================== --- test-suite/trunk/External/SPEC/CINT2006/483.xalancbmk/Makefile (original) +++ test-suite/trunk/External/SPEC/CINT2006/483.xalancbmk/Makefile Mon Mar 2 20:25:07 2009 @@ -23,6 +23,9 @@ ifeq ($(OS),Darwin) CPPFLAGS += -DSPEC_CPU_MACOSX endif +ifeq ($(OS),Linux) + CPPFLAGS += -DSPEC_CPU_LINUX +endif LDFLAGS = -lstdc++ -lm LIBS = -lstdc++ -lm From tonic at nondot.org Mon Mar 2 20:50:58 2009 From: tonic at nondot.org (Tanya Lattner) Date: Tue, 03 Mar 2009 02:50:58 -0000 Subject: [llvm-commits] [llvm] r65918 - /llvm/branches/release_25/docs/LangRef.html Message-ID: <200903030250.n232owdf015552@zion.cs.uiuc.edu> Author: tbrethou Date: Mon Mar 2 20:50:57 2009 New Revision: 65918 URL: http://llvm.org/viewvc/llvm-project?rev=65918&view=rev Log: Merge 64066 from mainline. Document the 'llvm.OP.with.overflow' intrinsics. Modified: llvm/branches/release_25/docs/LangRef.html Modified: llvm/branches/release_25/docs/LangRef.html URL: http://llvm.org/viewvc/llvm-project/llvm/branches/release_25/docs/LangRef.html?rev=65918&r1=65917&r2=65918&view=diff ============================================================================== --- llvm/branches/release_25/docs/LangRef.html (original) +++ llvm/branches/release_25/docs/LangRef.html Mon Mar 2 20:50:57 2009 @@ -207,6 +207,15 @@
  • 'llvm.part.set.*' Intrinsic
  • +
  • Arithmetic with Overflow Intrinsics +
      +
    1. 'llvm.sadd.with.overflow.* Intrinsics
    2. +
    3. 'llvm.uadd.with.overflow.* Intrinsics
    4. +
    5. 'llvm.ssub.with.overflow.* Intrinsics
    6. +
    7. 'llvm.usub.with.overflow.* Intrinsics
    8. +
    9. 'llvm.smul.with.overflow.* Intrinsics
    10. +
    +
  • Debugger intrinsics
  • Exception Handling intrinsics
  • Trampoline Intrinsic @@ -5573,7 +5582,7 @@

    This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit width. Not all targets support all bit widths however.

    -  declare i8 @llvm.ctpop.i8 (i8  <src>)
    +  declare i8 @llvm.ctpop.i8(i8  <src>)
       declare i16 @llvm.ctpop.i16(i16 <src>)
       declare i32 @llvm.ctpop.i32(i32 <src>)
       declare i64 @llvm.ctpop.i64(i64 <src>)
    @@ -5753,8 +5762,8 @@
     with the replaced bits.

    Arguments:
    -

    The first argument, %val and the result may be integer types of -any bit width but they must have the same bit width. %val is the value +

    The first argument, %val, and the result may be integer types of +any bit width, but they must have the same bit width. %val is the value whose bits will be replaced. The second argument, %repl may be an integer of any bit width. The third and fourth arguments must be i32 type since they specify only a bit index.

    @@ -5764,17 +5773,22 @@ of operation: forwards and reverse. If %lo is greater than %hi then the intrinsic operates in reverse mode. Otherwise it operates in forward mode.

    +

    For both modes, the %repl value is prepared for use by either truncating it down to the size of the replacement area or zero extending it up to that size.

    +

    In forward mode, the bits between %lo and %hi (inclusive) are replaced with corresponding bits from %repl. That is the 0th bit in %repl replaces the %loth bit in %val and etc. up to the %hith bit.

    +

    In reverse mode, a similar computation is made except that the bits are reversed. That is, the 0th bit in %repl replaces the %hi bit in %val and etc. down to the %loth bit.

    +
    Examples:
    +
       llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
       llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
    @@ -5782,6 +5796,248 @@
       llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
       llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
     
    + + + + + + +
    + +
    Syntax:
    + +

    This is an overloaded intrinsic. You can use llvm.sadd.with.overflow +on any integer bit width. However, not all targets support all bit widths.

    + +
    +  declare {i16, i1} @llvm.sadd.with.overflow.i16(i16 %a, i16 %b)
    +  declare {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
    +  declare {i64, i1} @llvm.sadd.with.overflow.i64(i64 %a, i64 %b)
    +
    + +
    Overview:
    + +

    The 'llvm.sadd.with.overflow' family of intrinsic functions perform +a signed addition of the two arguments, and indicate whether an overflow +occurred during the signed summation.

    + +
    Arguments:
    + +

    The arguments (%a and %b) and the first element of the result structure may +be of integer types of any bit width, but they must have the same bit width. The +second element of the result structure must be of type i1. %a +and %b are the two values that will undergo signed addition.

    + +
    Semantics:
    + +

    The 'llvm.sadd.with.overflow' family of intrinsic functions perform +a signed addition of the two variables. They return a structure — the +first element of which is the signed summation, and the second element of which +is a bit specifying if the signed summation resulted in an overflow.

    + +
    Examples:
    +
    +  %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
    +  %sum = extractvalue {i32, i1} %res, 0
    +  %obit = extractvalue {i32, i1} %res, 1
    +  br i1 %obit, label %overflow, label %normal
    +
    + +
    + + + + +
    + +
    Syntax:
    + +

    This is an overloaded intrinsic. You can use llvm.uadd.with.overflow +on any integer bit width. However, not all targets support all bit widths.

    + +
    +  declare {i16, i1} @llvm.uadd.with.overflow.i16(i16 %a, i16 %b)
    +  declare {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
    +  declare {i64, i1} @llvm.uadd.with.overflow.i64(i64 %a, i64 %b)
    +
    + +
    Overview:
    + +

    The 'llvm.uadd.with.overflow' family of intrinsic functions perform +an unsigned addition of the two arguments, and indicate whether a carry occurred +during the unsigned summation.

    + +
    Arguments:
    + +

    The arguments (%a and %b) and the first element of the result structure may +be of integer types of any bit width, but they must have the same bit width. The +second element of the result structure must be of type i1. %a +and %b are the two values that will undergo unsigned addition.

    + +
    Semantics:
    + +

    The 'llvm.uadd.with.overflow' family of intrinsic functions perform +an unsigned addition of the two arguments. They return a structure — the +first element of which is the sum, and the second element of which is a bit +specifying if the unsigned summation resulted in a carry.

    + +
    Examples:
    +
    +  %res = call {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
    +  %sum = extractvalue {i32, i1} %res, 0
    +  %obit = extractvalue {i32, i1} %res, 1
    +  br i1 %obit, label %carry, label %normal
    +
    + +
    + + + + +
    + +
    Syntax:
    + +

    This is an overloaded intrinsic. You can use llvm.ssub.with.overflow +on any integer bit width. However, not all targets support all bit widths.

    + +
    +  declare {i16, i1} @llvm.ssub.with.overflow.i16(i16 %a, i16 %b)
    +  declare {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
    +  declare {i64, i1} @llvm.ssub.with.overflow.i64(i64 %a, i64 %b)
    +
    + +
    Overview:
    + +

    The 'llvm.ssub.with.overflow' family of intrinsic functions perform +a signed subtraction of the two arguments, and indicate whether an overflow +occurred during the signed subtraction.

    + +
    Arguments:
    + +

    The arguments (%a and %b) and the first element of the result structure may +be of integer types of any bit width, but they must have the same bit width. The +second element of the result structure must be of type i1. %a +and %b are the two values that will undergo signed subtraction.

    + +
    Semantics:
    + +

    The 'llvm.ssub.with.overflow' family of intrinsic functions perform +a signed subtraction of the two arguments. They return a structure — the +first element of which is the subtraction, and the second element of which is a bit +specifying if the signed subtraction resulted in an overflow.

    + +
    Examples:
    +
    +  %res = call {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
    +  %sum = extractvalue {i32, i1} %res, 0
    +  %obit = extractvalue {i32, i1} %res, 1
    +  br i1 %obit, label %overflow, label %normal
    +
    + +
    + + + + +
    + +
    Syntax:
    + +

    This is an overloaded intrinsic. You can use llvm.usub.with.overflow +on any integer bit width. However, not all targets support all bit widths.

    + +
    +  declare {i16, i1} @llvm.usub.with.overflow.i16(i16 %a, i16 %b)
    +  declare {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
    +  declare {i64, i1} @llvm.usub.with.overflow.i64(i64 %a, i64 %b)
    +
    + +
    Overview:
    + +

    The 'llvm.usub.with.overflow' family of intrinsic functions perform +an unsigned subtraction of the two arguments, and indicate whether an overflow +occurred during the unsigned subtraction.

    + +
    Arguments:
    + +

    The arguments (%a and %b) and the first element of the result structure may +be of integer types of any bit width, but they must have the same bit width. The +second element of the result structure must be of type i1. %a +and %b are the two values that will undergo unsigned subtraction.

    + +
    Semantics:
    + +

    The 'llvm.usub.with.overflow' family of intrinsic functions perform +an unsigned subtraction of the two arguments. They return a structure — the +first element of which is the subtraction, and the second element of which is a bit +specifying if the unsigned subtraction resulted in an overflow.

    + +
    Examples:
    +
    +  %res = call {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
    +  %sum = extractvalue {i32, i1} %res, 0
    +  %obit = extractvalue {i32, i1} %res, 1
    +  br i1 %obit, label %overflow, label %normal
    +
    + +
    + + + + +
    + +
    Syntax:
    + +

    This is an overloaded intrinsic. You can use llvm.smul.with.overflow +on any integer bit width. However, not all targets support all bit widths.

    + +
    +  declare {i16, i1} @llvm.smul.with.overflow.i16(i16 %a, i16 %b)
    +  declare {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
    +  declare {i64, i1} @llvm.smul.with.overflow.i64(i64 %a, i64 %b)
    +
    + +
    Overview:
    + +

    The 'llvm.smul.with.overflow' family of intrinsic functions perform +a signed multiplication of the two arguments, and indicate whether an overflow +occurred during the signed multiplication.

    + +
    Arguments:
    + +

    The arguments (%a and %b) and the first element of the result structure may +be of integer types of any bit width, but they must have the same bit width. The +second element of the result structure must be of type i1. %a +and %b are the two values that will undergo signed multiplication.

    + +
    Semantics:
    + +

    The 'llvm.smul.with.overflow' family of intrinsic functions perform +a signed multiplication of the two arguments. They return a structure — +the first element of which is the multiplication, and the second element of +which is a bit specifying if the signed multiplication resulted in an +overflow.

    + +
    Examples:
    +
    +  %res = call {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
    +  %sum = extractvalue {i32, i1} %res, 0
    +  %obit = extractvalue {i32, i1} %res, 1
    +  br i1 %obit, label %overflow, label %normal
    +
    +
    From gohman at apple.com Mon Mar 2 20:55:14 2009 From: gohman at apple.com (Dan Gohman) Date: Tue, 03 Mar 2009 02:55:14 -0000 Subject: [llvm-commits] [llvm] r65920 - in /llvm/trunk: include/llvm/ include/llvm/CodeGen/ include/llvm/System/ include/llvm/Target/ lib/Target/ARM/AsmPrinter/ lib/Target/CellSPU/AsmPrinter/ lib/Target/PowerPC/ lib/Target/PowerPC/AsmPrinter/ lib/Target/X86/AsmPrinter/ lib/Transforms/Scalar/ lib/Transforms/Utils/ lib/VMCore/ Message-ID: <200903030255.n232tFI8015741@zion.cs.uiuc.edu> Author: djg Date: Mon Mar 2 20:55:14 2009 New Revision: 65920 URL: http://llvm.org/viewvc/llvm-project?rev=65920&view=rev Log: Fix a bunch of Doxygen syntax issues. Escape special characters, and put @file directives on their own comment line. Modified: llvm/trunk/include/llvm/CodeGen/MachineConstantPool.h llvm/trunk/include/llvm/CodeGen/MachineFrameInfo.h llvm/trunk/include/llvm/CodeGen/RegisterCoalescer.h llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h llvm/trunk/include/llvm/Constants.h llvm/trunk/include/llvm/Module.h llvm/trunk/include/llvm/System/IncludeFile.h llvm/trunk/include/llvm/Target/TargetLowering.h llvm/trunk/lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp llvm/trunk/lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp llvm/trunk/lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.cpp llvm/trunk/lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.cpp llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp llvm/trunk/lib/VMCore/Constants.cpp Modified: llvm/trunk/include/llvm/CodeGen/MachineConstantPool.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/MachineConstantPool.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/CodeGen/MachineConstantPool.h (original) +++ llvm/trunk/include/llvm/CodeGen/MachineConstantPool.h Mon Mar 2 20:55:14 2009 @@ -7,7 +7,8 @@ // //===----------------------------------------------------------------------===// // -/// @file This file declares the MachineConstantPool class which is an abstract +/// @file +/// This file declares the MachineConstantPool class which is an abstract /// constant pool to keep track of constants referenced by a function. // //===----------------------------------------------------------------------===// Modified: llvm/trunk/include/llvm/CodeGen/MachineFrameInfo.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/MachineFrameInfo.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/CodeGen/MachineFrameInfo.h (original) +++ llvm/trunk/include/llvm/CodeGen/MachineFrameInfo.h Mon Mar 2 20:55:14 2009 @@ -119,7 +119,7 @@ bool HasVarSizedObjects; /// FrameAddressTaken - This boolean keeps track of whether there is a call - /// to builtin @llvm.frameaddress. + /// to builtin \@llvm.frameaddress. bool FrameAddressTaken; /// StackSize - The prolog/epilog code inserter calculates the final stack @@ -207,7 +207,7 @@ /// isFrameAddressTaken - This method may be called any time after instruction /// selection is complete to determine if there is a call to - /// @llvm.frameaddress in this function. + /// \@llvm.frameaddress in this function. bool isFrameAddressTaken() const { return FrameAddressTaken; } void setFrameAddressIsTaken(bool T) { FrameAddressTaken = T; } Modified: llvm/trunk/include/llvm/CodeGen/RegisterCoalescer.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/RegisterCoalescer.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/CodeGen/RegisterCoalescer.h (original) +++ llvm/trunk/include/llvm/CodeGen/RegisterCoalescer.h Mon Mar 2 20:55:14 2009 @@ -64,7 +64,7 @@ /// /// class LinearScanRegallocQuery : public RegallocQuery { /// private: - /// const LiveIntervals &li; + /// const LiveIntervals \&li; /// /// public: /// LinearScanRegallocQuery(LiveIntervals &intervals) Modified: llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h (original) +++ llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h Mon Mar 2 20:55:14 2009 @@ -1125,7 +1125,7 @@ unsigned getOpcode() const { return (unsigned short)NodeType; } /// isTargetOpcode - Test if this node has a target-specific opcode (in the - /// ISD namespace). + /// \ISD namespace). bool isTargetOpcode() const { return NodeType >= ISD::BUILTIN_OP_END; } /// isMachineOpcode - Test if this node has a post-isel opcode, directly Modified: llvm/trunk/include/llvm/Constants.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Constants.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/Constants.h (original) +++ llvm/trunk/include/llvm/Constants.h Mon Mar 2 20:55:14 2009 @@ -7,7 +7,8 @@ // //===----------------------------------------------------------------------===// // -/// @file This file contains the declarations for the subclasses of Constant, +/// @file +/// This file contains the declarations for the subclasses of Constant, /// which represent the different flavors of constant values that live in LLVM. /// Note that Constants are immutable (once created they never change) and are /// fully shared by structural equivalence. This means that two structurally Modified: llvm/trunk/include/llvm/Module.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Module.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/Module.h (original) +++ llvm/trunk/include/llvm/Module.h Mon Mar 2 20:55:14 2009 @@ -7,7 +7,8 @@ // //===----------------------------------------------------------------------===// // -/// @file This file contains the declarations for the Module class. +/// @file +/// Module.h This file contains the declarations for the Module class. // //===----------------------------------------------------------------------===// Modified: llvm/trunk/include/llvm/System/IncludeFile.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/System/IncludeFile.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/System/IncludeFile.h (original) +++ llvm/trunk/include/llvm/System/IncludeFile.h Mon Mar 2 20:55:14 2009 @@ -64,7 +64,8 @@ /// helps to resolve that problem. The basic strategy is to use this class in /// a header file and pass the address of a variable to the constructor. If the /// variable is defined in the header file's corresponding .cpp file then all -/// tools/libraries that #include the header file will require the .cpp as well. +/// tools/libraries that \#include the header file will require the .cpp as +/// well. /// For example:
    /// extern int LinkMyCodeStub;
    /// static IncludeFile LinkMyModule(&LinkMyCodeStub);
    Modified: llvm/trunk/include/llvm/Target/TargetLowering.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Target/TargetLowering.h?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/include/llvm/Target/TargetLowering.h (original) +++ llvm/trunk/include/llvm/Target/TargetLowering.h Mon Mar 2 20:55:14 2009 @@ -1597,7 +1597,7 @@ ISD::CondCode CmpLibcallCCs[RTLIB::UNKNOWN_LIBCALL]; protected: - /// When lowering @llvm.memset this field specifies the maximum number of + /// When lowering \@llvm.memset this field specifies the maximum number of /// store operations that may be substituted for the call to memset. Targets /// must set this value based on the cost threshold for that target. Targets /// should assume that the memset will be done using as many of the largest @@ -1608,7 +1608,7 @@ /// @brief Specify maximum number of store instructions per memset call. unsigned maxStoresPerMemset; - /// When lowering @llvm.memcpy this field specifies the maximum number of + /// When lowering \@llvm.memcpy this field specifies the maximum number of /// store operations that may be substituted for a call to memcpy. Targets /// must set this value based on the cost threshold for that target. Targets /// should assume that the memcpy will be done using as many of the largest @@ -1620,7 +1620,7 @@ /// @brief Specify maximum bytes of store instructions per memcpy call. unsigned maxStoresPerMemcpy; - /// When lowering @llvm.memmove this field specifies the maximum number of + /// When lowering \@llvm.memmove this field specifies the maximum number of /// store instructions that may be substituted for a call to memmove. Targets /// must set this value based on the cost threshold for that target. Targets /// should assume that the memmove will be done using as many of the largest Modified: llvm/trunk/lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp (original) +++ llvm/trunk/lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp Mon Mar 2 20:55:14 2009 @@ -799,7 +799,7 @@ } /// PrintUnmangledNameSafely - Print out the printable characters in the name. -/// Don't print things like \n or \0. +/// Don't print things like \\n or \\0. static void PrintUnmangledNameSafely(const Value *V, raw_ostream &OS) { for (const char *Name = V->getNameStart(), *E = Name+V->getNameLen(); Name != E; ++Name) Modified: llvm/trunk/lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp (original) +++ llvm/trunk/lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp Mon Mar 2 20:55:14 2009 @@ -496,7 +496,7 @@ } /// PrintUnmangledNameSafely - Print out the printable characters in the name. -/// Don't print things like \n or \0. +/// Don't print things like \\n or \\0. static void PrintUnmangledNameSafely(const Value *V, raw_ostream &OS) { for (const char *Name = V->getNameStart(), *E = Name+V->getNameLen(); Name != E; ++Name) Modified: llvm/trunk/lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp (original) +++ llvm/trunk/lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp Mon Mar 2 20:55:14 2009 @@ -657,7 +657,7 @@ } /// PrintUnmangledNameSafely - Print out the printable characters in the name. -/// Don't print things like \n or \0. +/// Don't print things like \\n or \\0. static void PrintUnmangledNameSafely(const Value *V, raw_ostream &OS) { for (const char *Name = V->getNameStart(), *E = Name+V->getNameLen(); Name != E; ++Name) Modified: llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.cpp (original) +++ llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.cpp Mon Mar 2 20:55:14 2009 @@ -467,9 +467,9 @@ /// lowerDynamicAlloc - Generate the code for allocating an object in the /// current frame. The sequence of code with be in the general form /// -/// addi R0, SP, #frameSize ; get the address of the previous frame +/// addi R0, SP, \#frameSize ; get the address of the previous frame /// stwxu R0, SP, Rnegsize ; add and update the SP with the negated size -/// addi Rnew, SP, #maxCalFrameSize ; get the top of the allocation +/// addi Rnew, SP, \#maxCalFrameSize ; get the top of the allocation /// void PPCRegisterInfo::lowerDynamicAlloc(MachineBasicBlock::iterator II, int SPAdj, RegScavenger *RS) const { Modified: llvm/trunk/lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.cpp (original) +++ llvm/trunk/lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.cpp Mon Mar 2 20:55:14 2009 @@ -85,7 +85,7 @@ } /// PrintUnmangledNameSafely - Print out the printable characters in the name. -/// Don't print things like \n or \0. +/// Don't print things like \\n or \\0. static void PrintUnmangledNameSafely(const Value *V, raw_ostream &OS) { for (const char *Name = V->getNameStart(), *E = Name+V->getNameLen(); Name != E; ++Name) Modified: llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp (original) +++ llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Mon Mar 2 20:55:14 2009 @@ -11381,9 +11381,9 @@ /// equivalentAddressValues - Test if A and B will obviously have the same /// value. This includes recognizing that %t0 and %t1 will have the same /// value in code like this: -/// %t0 = getelementptr @a, 0, 3 +/// %t0 = getelementptr \@a, 0, 3 /// store i32 0, i32* %t0 -/// %t1 = getelementptr @a, 0, 3 +/// %t1 = getelementptr \@a, 0, 3 /// %t2 = load i32* %t1 /// static bool equivalentAddressValues(Value *A, Value *B) { Modified: llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp (original) +++ llvm/trunk/lib/Transforms/Utils/BasicBlockUtils.cpp Mon Mar 2 20:55:14 2009 @@ -425,9 +425,9 @@ /// AreEquivalentAddressValues - Test if A and B will obviously have the same /// value. This includes recognizing that %t0 and %t1 will have the same /// value in code like this: -/// %t0 = getelementptr @a, 0, 3 +/// %t0 = getelementptr \@a, 0, 3 /// store i32 0, i32* %t0 -/// %t1 = getelementptr @a, 0, 3 +/// %t1 = getelementptr \@a, 0, 3 /// %t2 = load i32* %t1 /// static bool AreEquivalentAddressValues(const Value *A, const Value *B) { Modified: llvm/trunk/lib/VMCore/Constants.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Constants.cpp?rev=65920&r1=65919&r2=65920&view=diff ============================================================================== --- llvm/trunk/lib/VMCore/Constants.cpp (original) +++ llvm/trunk/lib/VMCore/Constants.cpp Mon Mar 2 20:55:14 2009 @@ -1277,8 +1277,8 @@ return AggZeroConstants->getOrCreate(Ty, 0); } -// destroyConstant - Remove the constant from the constant table... -// +/// destroyConstant - Remove the constant from the constant table... +/// void ConstantAggregateZero::destroyConstant() { AggZeroConstants->remove(this); destroyConstantImpl(); @@ -1328,8 +1328,8 @@ return ConstantAggregateZero::get(Ty); } -// destroyConstant - Remove the constant from the constant table... -// +/// destroyConstant - Remove the constant from the constant table... +/// void ConstantArray::destroyConstant() { ArrayConstants->remove(this); destroyConstantImpl(); @@ -1370,7 +1370,7 @@ } /// isCString - This method returns true if the array is a string (see -/// isString) and it ends in a null byte \0 and does not contains any other +/// isString) and it ends in a null byte \\0 and does not contains any other /// null bytes except its terminator. bool ConstantArray::isCString() const { // Check the element type for i8... @@ -1391,10 +1391,10 @@ } -// getAsString - If the sub-element type of this array is i8 -// then this method converts the array to an std::string and returns it. -// Otherwise, it asserts out. -// +/// getAsString - If the sub-element type of this array is i8 +/// then this method converts the array to an std::string and returns it. +/// Otherwise, it asserts out. +/// std::string ConstantArray::getAsString() const { assert(isString() && "Not a string!"); std::string Result; From nicholas at mxc.ca Mon Mar 2 21:14:53 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Mon, 02 Mar 2009 19:14:53 -0800 Subject: [llvm-commits] [llvm] r65846 - /llvm/trunk/docs/ReleaseNotes.html In-Reply-To: <200903021658.n22Gw3Qe023616@zion.cs.uiuc.edu> References: <200903021658.n22Gw3Qe023616@zion.cs.uiuc.edu> Message-ID: <49ACA0AD.9040900@mxc.ca> Duncan Sands wrote: > Author: baldrick > Date: Mon Mar 2 10:58:00 2009 > New Revision: 65846 > > URL: http://llvm.org/viewvc/llvm-project?rev=65846&view=rev > Log: > Try to make the meaning of 'nocapture' a bit clearer. I > commented out the line about simplifylibcalls because I > think this doesn't work in the release (it was fixed in > svn after the release branched). Yes, I think that's right also. > > Modified: > llvm/trunk/docs/ReleaseNotes.html > > Modified: llvm/trunk/docs/ReleaseNotes.html > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=65846&r1=65845&r2=65846&view=diff > > ============================================================================== > --- llvm/trunk/docs/ReleaseNotes.html (original) > +++ llvm/trunk/docs/ReleaseNotes.html Mon Mar 2 10:58:00 2009 > @@ -368,13 +368,16 @@ >
  • LLVM IR supports two new attributes for better alias analysis. The href="LangRef.html#paramattrs">noalias attribute can now be used on the > return value of a function to indicate that it returns new memory (e.g. > -'malloc', 'calloc', etc).
  • > - > -
  • The new nocapture attribute can be > -used on pointer arguments to functions that access through but do not return the > -pointer in a data structure that out lives the call (e.g. 'strlen', 'memcpy', > -and many others). The simplifylibcalls pass applies these attributes to > -standard libc functions.
  • > +'malloc', 'calloc', etc). > +The new nocapture attribute can be used > +on pointer arguments to indicate that the function does not return the pointer, > +store it in an object that outlives the call, or let the value of the pointer > +escape from the function in any other way. > +Note that it is the pointer itself that must not escape, not the value it > +points to: loading a value out of the pointer is perfectly fine. > +Many standard library functions (e.g. 'strlen', 'memcpy') have this property. Does this note really belong in the release notes? Perhaps the link to the LangRef is enough? Nick > + > +
  • > >
  • The parser for ".ll" files in lib/AsmParser is now completely rewritten as a > recursive descent parser. This parser produces better error messages (including > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > From nicholas at mxc.ca Mon Mar 2 21:36:51 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Tue, 03 Mar 2009 03:36:51 -0000 Subject: [llvm-commits] [llvm] r65922 - /llvm/trunk/Makefile.rules Message-ID: <200903030336.n233apXI017219@zion.cs.uiuc.edu> Author: nicholas Date: Mon Mar 2 21:36:50 2009 New Revision: 65922 URL: http://llvm.org/viewvc/llvm-project?rev=65922&view=rev Log: Fix build on Cygwin. Modified: llvm/trunk/Makefile.rules Modified: llvm/trunk/Makefile.rules URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.rules?rev=65922&r1=65921&r2=65922&view=diff ============================================================================== --- llvm/trunk/Makefile.rules (original) +++ llvm/trunk/Makefile.rules Mon Mar 2 21:36:50 2009 @@ -313,7 +313,7 @@ endif ifeq ($(ENABLE_PIC),1) - ifeq ($(LLVM_ON_WIN32),1) + ifeq ($(OS), $(filter $(OS), Cygwin MingW)) # Nothing. Win32 defaults to PIC and warns when given -fPIC else ifeq ($(OS),Darwin) @@ -471,7 +471,13 @@ -mmacosx-version-min=$(DARWIN_VERSION) CompileCommonOpts += -mmacosx-version-min=$(DARWIN_VERSION) else - SharedLinkOptions=-shared + ifeq ($(OS),Cygwin) + SharedLinkOptions=-shared -nostdlib -Wl,--export-all-symbols \ + -Wl,--enable-auto-import -Wl,--enable-auto-image-base \ + -Wl,--enable-runtime-pseudo-relocs + else + SharedLinkOptions=-shared + endif endif #---------------------------------------------------------- From tonic at nondot.org Mon Mar 2 22:36:04 2009 From: tonic at nondot.org (Tanya Lattner) Date: Tue, 03 Mar 2009 04:36:04 -0000 Subject: [llvm-commits] [llvm] r65923 - /llvm/branches/release_25/docs/ReleaseNotes.html Message-ID: <200903030436.n234a40n019308@zion.cs.uiuc.edu> Author: tbrethou Date: Mon Mar 2 22:36:03 2009 New Revision: 65923 URL: http://llvm.org/viewvc/llvm-project?rev=65923&view=rev Log: 2.5 release notes. Modified: llvm/branches/release_25/docs/ReleaseNotes.html Modified: llvm/branches/release_25/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/branches/release_25/docs/ReleaseNotes.html?rev=65923&r1=65922&r2=65923&view=diff ============================================================================== --- llvm/branches/release_25/docs/ReleaseNotes.html (original) +++ llvm/branches/release_25/docs/ReleaseNotes.html Mon Mar 2 22:36:03 2009 @@ -4,16 +4,17 @@ - LLVM 2.4 Release Notes + LLVM 2.5 Release Notes -
    LLVM 2.4 Release Notes
    +
    LLVM 2.5 Release Notes
    1. Introduction
    2. Sub-project Status Update
    3. -
    4. What's New in LLVM?
    5. +
    6. External Projects Using LLVM 2.5
    7. +
    8. What's New in LLVM 2.5?
    9. Installation Instructions
    10. Portability and Supported Platforms
    11. Known Problems
    12. @@ -33,9 +34,9 @@

      This document contains the release notes for the LLVM Compiler -Infrastructure, release 2.4. Here we describe the status of LLVM, including +Infrastructure, release 2.5. Here we describe the status of LLVM, including major improvements from the previous release and significant known problems. -All LLVM releases may be downloaded from the LLVM releases web site.

      For more information about LLVM, including information about the latest @@ -51,18 +52,25 @@

      - + -->
      @@ -72,12 +80,12 @@

      -The LLVM 2.4 distribution currently consists of code from the core LLVM -repository (which roughly includes the LLVM optimizers, code generators and -supporting tools) and the llvm-gcc repository. In addition to this code, the -LLVM Project includes other sub-projects that are in development. The two which -are the most actively developed are the Clang Project and -the VMKit Project. +The LLVM 2.5 distribution currently consists of code from the core LLVM +repository —which roughly includes the LLVM optimizers, code generators +and supporting tools — and the llvm-gcc repository. In addition to this +code, the LLVM Project includes other sub-projects that are in development. The +two which are the most actively developed are the Clang +Project and the VMKit Project.

      @@ -91,40 +99,38 @@

      The Clang project is an effort to build -a set of new 'LLVM native' front-end technologies for the LLVM optimizer -and code generator. Clang is continuing to make major strides forward in all -areas. Its C and Objective-C parsing support is very solid, and the code -generation support is far enough along to build many C applications. While not -yet production quality, it is progressing very nicely. In addition, C++ -front-end work has started to make significant progress.

      - -

      Clang, in conjunction with the ccc driver, is now usable as a -replacement for gcc for building some small- to medium-sized C applications. -Additionally, Clang now has code generation support for Objective-C on Mac OS X -platform. Major highlights include:

      - -
        -
      • Clang/ccc pass almost all of the LLVM test suite on Mac OS X and Linux -on the 32-bit x86 architecture. This includes significant C -applications such as sqlite3, -lua, and -Clam AntiVirus.
      • - -
      • Clang can build the majority of Objective-C examples shipped with the -Mac OS X Developer Tools.
      • -
      - -

      Clang code generation still needs considerable testing and development, -however. Some areas under active development include:

      - -
        -
      • Improved support for C and Objective-C features, for example - variable-length arrays, va_arg, exception handling (Obj-C), and garbage - collection (Obj-C).
      • -
      • ABI compatibility, especially for platforms other than 32-bit - x86.
      • +a set of new 'LLVM native' front-end technologies for the LLVM optimizer and +code generator. While Clang is not included in the LLVM 2.5 release, it is +continuing to make major strides forward in all areas. Its C and Objective-C +parsing and code generation support is now very solid. For example, it is +capable of successfully building many real-world applications for X86-32 +and X86-64, +including the FreeBSD +kernel and gcc 4.2. C++ is also +making incredible progress, +and work on templates has recently started. If you are +interested in fast compiles and good diagnostics, we encourage you to try it out +by building from mainline +and reporting any issues you hit to the Clang front-end mailing +list.

        + +

        In the LLVM 2.5 time-frame, the Clang team has made many improvements:

        + +
          +
        • Clang now has a new driver, which is focused on providing a GCC-compatible + interface.
        • +
        • The X86-64 ABI is now supported, including support for the Apple + 64-bit Objective-C runtime and zero cost exception handling.
        • +
        • Precompiled header support is now implemented.
        • +
        • Objective-C support is significantly improved beyond LLVM 2.4, supporting + many features, such as Objective-C Garbage Collection.
        • +
        • Variable length arrays are now fully supported.
        • +
        • C99 designated initializers are now fully supported.
        • +
        • Clang now includes all major compiler headers, including a + redesigned tgmath.h and several more intrinsic headers.
        • +
        • Many many bugs are fixed and many features have been added.
        -
      @@ -134,28 +140,25 @@
      -

      The Clang project also includes an early stage static source code analysis -tool for automatically -finding bugs in C and Objective-C programs. The tool performs a growing set -of checks to find bugs that occur on a specific path within a program. Examples -of bugs the tool finds include logic errors such as null dereferences, -violations of various API rules, dead code, and potential memory leaks in -Objective-C programs. Since its inception, public feedback on the tool has been -extremely positive, and conservative estimates put the number of real bugs it -has found in industrial-quality software on the order of thousands.

      - -

      The tool also provides a simple web GUI to inspect potential bugs found by -the tool. While still early in development, the GUI illustrates some of the key -features of Clang: accurate source location information, which is used by the -GUI to highlight specific code expressions that relate to a bug (including those -that span multiple lines); and built-in knowledge of macros, which is used to -perform inline expansion of macros within the GUI itself.

      - -

      The set of checks performed by the static analyzer is gradually expanding, -and future plans for the tool include full source-level inter-procedural -analysis and deeper checks such as buffer overrun detection. There are many -opportunities to extend and enhance the static analyzer, and anyone interested -in working on this project is encouraged to get involved!

      +

      Previously announced in the last LLVM release, the Clang project also +includes an early stage static source code analysis tool for automatically finding bugs +in C and Objective-C programs. The tool performs a growing set of checks to find +bugs that occur on a specific path within a program.

      + +

      In the LLVM 2.5 time-frame there have been many significant improvements to +the analyzer's core path simulation engine and machinery for generating +path-based bug reports to end-users. Particularly noteworthy improvements +include experimental support for full field-sensitivity and reasoning about heap +objects as well as an improved value-constraints subengine that does a much +better job of reasoning about inequality relationships (e.g., x > 2) +between variables and constants. + +

      The set of checks performed by the static analyzer continues to expand, and +future plans for the tool include full source-level inter-procedural analysis +and deeper checks such as buffer overrun detection. There are many opportunities +to extend and enhance the static analyzer, and anyone interested in working on +this project is encouraged to get involved!

      @@ -170,29 +173,101 @@ a JVM and a CLI Virtual Machines (Microsoft .NET is an implementation of the CLI) using the Just-In-Time compiler of LLVM.

      -

      Following LLVM 2.4, VMKit has its first release 0.24 that you can find on its +

      Following LLVM 2.5, VMKit has its second release that you can find on its webpage. The release includes bug fixes, cleanup and new features. The major changes are:

        -
      • Support for generics in the .Net virtual machine.
      • -
      • Initial support for the Mono class libraries.
      • -
      • Support for MacOSX/x86, following LLVM's support for exceptions in -JIT on MacOSX/x86.
      • -
      • A new vmkit driver: a program to run java or .net applications. The driver -supports llvm command line arguments including the new "-fast" option.
      • -
      • A new memory allocation scheme in the JVM that makes unloading a -class loader very fast.
      • -
      • VMKit now follows the LLVM Makefile machinery.
      • +
      • Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this +functionality to native compile the standard classes (e.g. java.lang.String). +Users can compile AoT .class files into dynamic libraries and run them with the +help of VMKit.
      • + +
      • New exception model: the dwarf exception model is very slow for +exception-intensive applications, so the JVM has had a new implementation of +exceptions which check at each function call if an exception happened. There is +a low performance penalty on applications without exceptions, but it is a big +gain for exception-intensive applications. For example the jack benchmark in +Spec JVM98 is 6x faster (performance gain of 83%).
      • + +
      • User-level management of thread stacks, so that thread local data access +at runtime is fast and portable.
      • + +
      • Implementation of biased locking for faster object synchronizations at +runtime.
      • + +
      • New support for OSX/X64, Linux/X64 (with the Boehm GC) and Linux/ppc32.
      + + + + + +
      +Pure +
      + +
      +

      +Pure +is an algebraic/functional programming language based on term rewriting. +Programs are collections of equations which are used to evaluate expressions in +a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation, +lexical closures, a hygienic macro system (also based on term rewriting), +built-in list and matrix support (including list and matrix comprehensions) and +an easy-to-use C interface. The interpreter uses LLVM as a backend to + JIT-compile Pure programs to fast native code.

      + +

      In addition to the usual algebraic data structures, Pure also has +MATLAB-style matrices in order to support numeric computations and signal +processing in an efficient way. Pure is mainly aimed at mathematical +applications right now, but it has been designed as a general purpose language. +The dynamic interpreter environment and the C interface make it possible to use +it as a kind of functional scripting language for many application areas. +

      +
      + + + + + +
      +

      +LDC is an implementation of +the D Programming Language using the LLVM optimizer and code generator. +The LDC project works great with the LLVM 2.5 release. General improvements in +this +cycle have included new inline asm constraint handling, better debug info +support, general bugfixes, and better x86-64 support. This has allowed +some major improvements in LDC, getting us much closer to being as +fully featured as the original DMD compiler from DigitalMars. +

      +
      + + + + +
      +

      Roadsend PHP (rphp) is an open +source implementation of the PHP programming +language that uses LLVM for its optimizer, JIT, and static compiler. This is a +reimplementation of an earlier project that is now based on LLVM.

      +
      + @@ -211,30 +286,28 @@
      -

      LLVM 2.4 includes several major new capabilities:

      +

      LLVM 2.5 includes several major new capabilities:

        -
      • The most visible end-user change in LLVM 2.4 is that it includes many -optimizations and changes to make -O0 compile times much faster. You should see -improvements in speed on the order of 30% (or more) than in LLVM 2.3. There are -many pieces to this change described in more detail below. The speedups and new -components can also be used for JIT compilers that want fast -compilation.

      • - -
      • The biggest change to the LLVM IR is that Multiple Return Values (which -were introduced in LLVM 2.3) have been generalized to full support for "First -Class Aggregate" values in LLVM 2.4. This means that LLVM IR supports using -structs and arrays as values in a function. This capability is mostly useful -for front-end authors, who prefer to treat things like complex numbers, simple -tuples, dope vectors, etc., as Value*'s instead of as a tuple of Value*'s or as -memory values. Bitcode files from LLVM 2.3 will automatically migrate to the -general representation.

      • - -
      • LLVM 2.4 also includes an initial port for the PIC16 microprocessor. This -target only has support for 8 bit registers, and a number of other crazy -constraints. While the port is still in early development stages, it shows some -interesting things you can do with LLVM.

      • +
      • LLVM 2.5 includes a brand new XCore backend.
      • +
      • llvm-gcc now generally supports the GFortran front-end, and the precompiled +release binaries now support Fortran, even on Mac OS/X.
      • + +
      • CMake is now used by the LLVM build process +on Windows. It automatically generates Visual Studio project files (and +more) from a set of simple text files. This makes it much easier to +maintain. In time, we'd like to standardize on CMake for everything.
      • + +
      • LLVM 2.5 now uses (and includes) Google Test for unit testing.
      • + +
      • The LLVM native code generator now supports arbitrary precision integers. +Types like i33 have long been valid in the LLVM IR, but were previously +only supported by the interpreter. Note that the C backend still does not +support these.
      • + +
      • LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.
      @@ -252,29 +325,18 @@ includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.

        -
      • LLVM 2.4 supports the full set of atomic __sync_* builtins. LLVM -2.3 only supported those used by OpenMP, but 2.4 supports them all. Note that -while llvm-gcc supports all of these builtins, not all targets do. X86 support -them all in both 32-bit and 64-bit mode and PowerPC supports them all except for -the 64-bit operations when in 32-bit mode.
      • - -
      • llvm-gcc now supports an -flimited-precision option, which tells -the compiler that it is okay to use low-precision approximations of certain libm -functions (like exp, log, etc). This allows you to get high -performance if you only need (say) 12-bits of precision.
      • - -
      • llvm-gcc now supports a C language extension known as "Blocks". -This feature is similar to nested functions and closures, but does not -require stack trampolines (with most ABIs), and supports returning closures -from functions that define them. Note that actually using Blocks -requires a small runtime that is not included with llvm-gcc.
      • - -
      • llvm-gcc now supports a new -flto option. On systems that support -transparent Link Time Optimization (currently Darwin systems with Xcode 3.1 and -later) this allows the use of LTO with other optimization levels like -Os. -Previously, LTO could only be used with -O4, which implied optimizations in --O3 that can increase code size.
      • +
      • In this release, the GCC inliner is completely disabled. Previously the GCC +inliner was used to handle always-inline functions and other cases. This caused +problems with code size growth, and it is completely disabled in this +release.
      • + +
      • llvm-gcc (and LLVM in general) now support code generation for stack +canaries, which is an effective form of buffer overflow +protection. llvm-gcc supports this with the -fstack-protector +command line option (just like GCC). In LLVM IR, you can request code +generation for stack canaries with function attributes. +
      @@ -282,51 +344,56 @@
      -

      New features include:

      +

      LLVM IR has several new features that are used by our existing front-ends and +can be useful if you are writing a front-end for LLVM:

        -
      • A major change to the Use class landed, which shrank it by 25%. Since -this is a pervasive part of the LLVM, it ended up reducing the memory use of -LLVM IR in general by 15% for most programs.
      • - -
      • Values with no names are now pretty printed by llvm-dis more -nicely. They now print as "%3 = add i32 %A, 4" instead of -"add i32 %A, 4 ; <i32>:3", which makes it much easier to read. +
      • The shufflevector instruction +has been generalized to allow different shuffle mask width than its input +vectors. This allows you to use shufflevector to combine two +"<4 x float>" vectors into a "<8 x float>" for example.
      • + +
      • LLVM IR now supports new intrinsics for computing and acting on overflow of integer operations. This allows +efficient code generation for languages that must trap or throw an exception on +overflow. While these intrinsics work on all targets, they only generate +efficient code on X86 so far.
      • + +
      • LLVM IR now supports a new private +linkage type to produce labels that are stripped by the assembler before it +produces a .o file (thus they are invisible to the linker).
      • + +
      • LLVM IR supports two new attributes for better alias analysis. The noalias attribute can now be used on the +return value of a function to indicate that it returns new memory (e.g. +'malloc', 'calloc', etc). +The new nocapture attribute can be used +on pointer arguments to indicate that the function does not return the pointer, +store it in an object that outlives the call, or let the value of the pointer +escape from the function in any other way. +Note that it is the pointer itself that must not escape, not the value it +points to: loading a value out of the pointer is perfectly fine. +Many standard library functions (e.g. 'strlen', 'memcpy') have this property. +
      • -
      • LLVM 2.4 includes some changes for better vector support. First, the shift -operations (shl, ashr, and lshr) now all support -vectors and do an element-by-element shift (shifts of the whole vector can be -accomplished by bitcasting the vector to <1 x i128>, for example). Second, -there is initial support in development for vector comparisons with the -fcmp/icmp -instructions. These instructions compare two vectors and return a vector of -i1's for each result. Note that there is very little codegen support -available for any of these IR features though.
      • - -
      • A new DebugInfoBuilder class is available, which makes it much -easier for front-ends to create debug info descriptors, similar to the way that -IRBuilder makes it easier to create LLVM IR.
      • - -
      • The IRBuilder class is now parameterized by a class responsible -for constant folding. The default ConstantFolder class does target independent -constant folding. The NoFolder class does no constant folding at all, which is -useful when learning how LLVM works. The TargetFolder class folds the most, -doing target dependent constant folding.
      • - -
      • LLVM now supports "function attributes", which allow us to separate return -value attributes from function attributes. LLVM now supports attributes on a -function itself, a return value, and its parameters. New supported function -attributes include noinline/alwaysinline and the opt-size flag, -which says the function should be optimized for code size.
      • +
      • The parser for ".ll" files in lib/AsmParser is now completely rewritten as a +recursive descent parser. This parser produces better error messages (including +caret diagnostics), is less fragile (less likely to crash on strange things), +does not leak memory, is more efficient, and eliminates LLVM's last use of the +'bison' tool.
      • + +
      • Debug information representation and manipulation internals have been + consolidated to use a new set of classes in + llvm/Analysis/DebugInfo.h. These routines are more + efficient, robust, and extensible and replace the older mechanisms. + llvm-gcc, clang, and the code generator now use them to create and process + debug information.
      • -
      • LLVM IR now directly represents "common" linkage, instead of - representing it as a form of weak linkage.
      • -
      @@ -338,44 +405,26 @@
      -

      In addition to a huge array of bug fixes and minor performance tweaks, this +

      In addition to a large array of bug fixes and minor performance tweaks, this release includes a few major enhancements and additions to the optimizers:

        -
      • The Global Value Numbering (GVN) pass now does local Partial Redundancy -Elimination (PRE) to eliminate some partially redundant expressions in cases -where doing so won't grow code size.
      • - -
      • LLVM 2.4 includes a new loop deletion pass (which removes output-free -provably-finite loops) and a rewritten Aggressive Dead Code Elimination (ADCE) -pass that no longer uses control dependence information. These changes speed up -the optimizer and also prevent it from deleting output-free infinite -loops.
      • +
      • The loop optimizer now improves floating point induction variables in +several ways, including adding shadow induction variables to avoid +"integer <-> floating point" conversions in loops when safe.
      • -
      • The new AddReadAttrs pass works out which functions are read-only or -read-none (these correspond to 'pure' and 'const' in GCC) and marks them -with the appropriate attribute.
      • +
      • The "-mem2reg" pass is now much faster on code with large basic blocks.
      • -
      • LLVM 2.4 now includes a new SparsePropagation framework, which makes it -trivial to build lattice-based dataflow solvers that operate over LLVM IR. Using -this interface means that you just define objects to represent your lattice -values and the transfer functions that operate on them. It handles the -mechanics of worklist processing, liveness tracking, handling PHI nodes, -etc.
      • +
      • The "-jump-threading" pass is more powerful: it is iterative + and handles threading based on values with fully and partially redundant + loads.
      • -
      • The Loop Strength Reduction and induction variable optimization passes have -several improvements to avoid inserting MAX expressions, to optimize simple -floating point induction variables and to analyze trip counts of more -loops.
      • +
      • The "-memdep" memory dependence analysis pass (used by GVN and memcpyopt) is + both faster and more aggressive.
      • -
      • Various helper functions (ComputeMaskedBits, ComputeNumSignBits, etc) were -pulled out of the Instruction Combining pass and put into a new -ValueTracking.h header, where they can be reused by other passes.
      • - -
      • The tail duplication pass has been removed from the standard optimizer -sequence used by llvm-gcc. This pass still exists, but the benefits it once -provided are now achieved by other passes.
      • +
      • The "-scalarrepl" scalar replacement of aggregates pass is more aggressive + about promoting unions to registers.
      @@ -383,78 +432,120 @@
      -

      We have put a significant amount of work into the code generator infrastructure, -which allows us to implement more aggressive algorithms and make it run -faster:

      +

      We have put a significant amount of work into the code generator +infrastructure, which allows us to implement more aggressive algorithms and make +it run faster:

        -
      • The target-independent code generator supports (and the X86 backend - currently implements) a new interface for "fast" instruction selection. This - interface is optimized to produce code as quickly as possible, sacrificing - code quality to do it. This is used by default at -O0 or when using - "llc -fast" on X86. It is straight-forward to add support for - other targets if faster -O0 compilation is desired.
      • - -
      • In addition to the new 'fast' instruction selection path, many existing - pieces of the code generator have been optimized in significant ways. - SelectionDAG's are now pool allocated and use better algorithms in many - places, the ".s" file printers now use raw_ostream to emit text much faster, - etc. The end result of these improvements is that the compiler also takes - substantially less time to generate code that is just as good (and often - better) than before.
      • +
      • The Writing an LLVM Compiler +Backend document has been greatly expanded and is substantially more +complete.
      • -
      • Each target has been split to separate the ".s" file printing logic from the - rest of the target. This enables JIT compilers that don't link in the - (somewhat large) code and data tables used for printing a ".s" file.
      • +
      • The SelectionDAG type legalization logic has been completely rewritten, is +now more powerful (it supports arbitrary precision integer types for example), +and is more correct in several corner cases. The type legalizer converts +operations on types that are not natively supported by the target machine into +equivalent code sequences that only use natively supported types. The old type +legalizer is still available (for now) and will be used if +-disable-legalize-types is passed to the code generator. +
      • -
      • The code generator now includes a "stack slot coloring" pass, which packs - together individual spilled values into common stack slots. This reduces - the size of stack frames with many spills, which tends to increase L1 cache - effectiveness.
      • +
      • The code generator now supports widening illegal vectors to larger legal +ones (for example, converting operations on <3 x float> to work on +<4 x float>) which is very important for common graphics +applications.
      • + +
      • The assembly printers for each target are now split out into their own +libraries that are separate from the main code generation logic. This reduces +the code size of JIT compilers by not requiring them to be linked in.
      • + +
      • The 'fast' instruction selection path (used at -O0 and for fast JIT + compilers) now supports accelerating codegen for code that uses exception + handling constructs.
      • + +
      • The optional PBQP register allocator now supports register coalescing.
      • +
      +
      -
    13. Various pieces of the register allocator (e.g. the coalescer and two-address - operation elimination pass) now know how to rematerialize trivial operations - to avoid copies and include several other optimizations.
    14. + + -
    15. The graphs produced by - the llc -view-*-dags options are now significantly prettier and - easier to read.
    16. +
      +

      New features of the X86 target include: +

      -
    17. LLVM 2.4 includes a new register allocator based on Partitioned Boolean - Quadratic Programming (PBQP). This register allocator is still in - development, but is very simple and clean.
    18. +
        +
      • The llvm.returnaddress +intrinsic (which is used to implement __builtin_return_address) now +supports non-zero stack depths on X86.
      • + +
      • The X86 backend now supports code generation of vector shift operations +using SSE instructions.
      • + +
      • X86-64 code generation now takes advantage of red zone, unless the +-mno-red-zone option is specified.
      • + +
      • The X86 backend now supports using address space #256 in LLVM IR as a way of +performing memory references off the GS segment register. This allows a +front-end to take advantage of very low-level programming techniques when +targeting X86 CPUs. See test/CodeGen/X86/movgs.ll for a simple +example.
      • + +
      • The X86 backend now supports a -disable-mmx command line option to + prevent use of MMX even on chips that support it. This is important for cases + where code does not contain the proper llvm.x86.mmx.emms + intrinsics.
      • + +
      • The X86 JIT now detects the new Intel Core i7 and Atom chips and + auto-configures itself appropriately for the features of these chips.
      • + +
      • The JIT now supports exception handling constructs on Linux/X86-64 and + Darwin/x86-64.
      • +
      • The JIT supports Thread Local Storage (TLS) on Linux/X86-32 but not yet on + X86-64.
      -
      -

      New target-specific features include: +

      New features of the PIC16 target include:

        -
      • Exception handling is supported by default on Linux/x86-64.
      • -
      • Position Independent Code (PIC) is now supported on Linux/x86-64.
      • -
      • @llvm.frameaddress now supports getting the frame address of stack frames - > 0 on x86/x86-64.
      • -
      • MIPS has improved a lot since last release, the most important changes - are: Little endian support, floating point support, allegrex core and - intrinsics support. O32 ABI is improved but isn't complete. The EABI - was implemented and is fully supported. We also have support for small - sections and gp_rel relocation for its access, a threshold in bytes can be - specified through command line.
      • -
      • The PowerPC backend now supports trampolines.
      • +
      • Both direct and indirect load/stores work now.
      • +
      • Logical, bitwise and conditional operations now work for integer data +types.
      • +
      • Function calls involving basic types work now.
      • +
      • Support for integer arrays.
      • +
      • The compiler can now emit libcalls for operations not supported by m/c +instructions.
      • +
      • Support for both data and ROM address spaces.
      • +
      + +

      Things not yet supported:

      + +
        +
      • Floating point.
      • +
      • Passing/returning aggregate types to and from functions.
      • +
      • Variable arguments.
      • +
      • Indirect function calls.
      • +
      • Interrupts/programs.
      • +
      • Debug info.
      @@ -462,34 +553,50 @@
      -

      New features include: -

      +

      New features include:

        -
      • llvmc2 (the generic compiler driver) gained plugin - support. It is now easier to experiment with llvmc2 and - build your own tools based on it.
      • - -
      • LLVM 2.4 includes a number of new generic algorithms and data structures, - including a scoped hash table, 'immutable' data structures, a simple - free-list manager, and a raw_ostream class. - The raw_ostream class and - format allow for efficient file output, and various pieces of LLVM - have switched over to use it. The eventual goal is to eliminate - use of std::ostream in favor of it.
      • - -
      • LLVM 2.4 includes an optional build system based on CMake. It - still is in its early stages but can be useful for Visual C++ - users who can not use the Visual Studio IDE.
      • +
      • Beginning with LLVM 2.5, llvmc2 is known as + just llvmc. The old llvmc driver was removed.
      • + +
      • The Clang plugin was substantially improved and is now enabled + by default. The command llvmc --clang can be now used as a + synonym to ccc.
      • + +
      • There is now a --check-graph option, which is supposed to catch + common errors like multiple default edges, mismatched output/input language + names and cycles. In general, these checks can't be done at compile-time + because of the need to support plugins.
      • + +
      • Plugins are now more flexible and can refer to compilation graph nodes and + options defined in other plugins. To manage dependencies, a priority-sorting + mechanism was introduced. This change affects the TableGen file syntax. See the + documentation for details.
      • + +
      • Hooks can now be provided with arguments. The syntax is "$CALL(MyHook, + 'Arg1', 'Arg2', 'Arg3')".
      • + +
      • A new option type: multi-valued option, for options that take more than one + argument (for example, "-foo a b c").
      • + +
      • New option properties: 'one_or_more', 'zero_or_more', +'hidden' and 'really_hidden'.
      • + +
      • The 'case' expression gained an 'error' action and + an 'empty' test (equivalent to "(not (not_empty ...))").
      • + +
      • Documentation now looks more consistent to the rest of the LLVM + docs. There is also a man page now.
      +
      Major Changes and Removed Features @@ -498,19 +605,13 @@

      If you're already an LLVM user or developer with out-of-tree changes based -on LLVM 2.3, this section lists some "gotchas" that you may run into upgrading +on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading from the previous release.

        -
      • The LLVM IR generated by llvm-gcc no longer names all instructions. This - makes it run faster, but may be more confusing to some people. If you - prefer to have names, the 'opt -instnamer' pass will add names to - all instructions.
      • - -
      • The LoadVN and GCSE passes have been removed from the tree. They are - obsolete and have been replaced with the GVN and MemoryDependence passes. -
      • +
      • llvm-gcc defaults to -fno-math-errno on all X86 targets.
      • +
      @@ -518,51 +619,8 @@ API changes are:

        - -
      • Now, function attributes and return value attributes are managed -separately. Interface exported by ParameterAttributes.h header is now -exported by Attributes.h header. The new attributes interface changes are: -
          -
        • getParamAttrs method is now replaced by -getParamAttributes, getRetAttributes and -getFnAttributes methods.
        • -
        • Return value attributes are stored at index 0. Function attributes are -stored at index ~0U. Parameter attributes are stored at index that matches -parameter number.
        • -
        • ParamAttr namespace is now renamed as Attribute.
        • -
        • The name of the class that manages reference count of opaque -attributes is changed from PAListPtr to AttrListPtr.
        • -
        • ParamAttrsWithIndex is now renamed as AttributeWithIndex. -
        • -
        -
      • - -
      • The DbgStopPointInst methods getDirectory and -getFileName now return Value* instead of strings. These can be -converted to strings using llvm::GetConstantStringInfo defined via -"llvm/Analysis/ValueTracking.h".
      • - -
      • The APIs to create various instructions have changed from lower case - "create" methods to upper case "Create" methods (e.g. - BinaryOperator::create). LLVM 2.4 includes both cases, but the - lower case ones are removed in mainline (2.5 and later), please migrate.
      • - -
      • Various header files like "llvm/ADT/iterator" were given a ".h" suffix. - Change your code to #include "llvm/ADT/iterator.h" instead.
      • - -
      • The getresult instruction has been removed and replaced with the - extractvalue instruction. This is part of support for first class - aggregates.
      • - -
      • In the code generator, many MachineOperand predicates were renamed to be - shorter (e.g. isFrameIndex() -> isFI()), - SDOperand was renamed to SDValue (and the "Val" - member was changed to be the getNode() accessor), and the - MVT::ValueType enum has been replaced with an "MVT" - struct. The getSignExtended and getValue methods in the - ConstantSDNode class were renamed to getSExtValue and - getZExtValue respectively, to be more consistent with - the ConstantInt class.
      • +
      • Some deprecated interfaces to create Instruction subclasses, that + were spelled with lower case "create," have been removed.
      @@ -580,9 +638,9 @@

      LLVM is known to work on the following platforms:

        -
      • Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat +
      • Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat Linux, Fedora Core and FreeBSD (and probably other unix-like systems).
      • -
      • PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit +
      • PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit and 64-bit modes.
      • Intel and AMD machines running on Win32 using MinGW libraries (native).
      • Intel and AMD machines running on Win32 with the Cygwin libraries (limited @@ -607,7 +665,7 @@
        -

        This section contains significant known problems with the LLVM system, +

        This section contains significant known problems with the LLVM system, listed by component. If you run into a problem, please check the LLVM bug database and submit a bug if there isn't already one.

        @@ -630,8 +688,8 @@
        • The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.
        • -
        • The llc "-filetype=asm" (the default) is the only supported - value for this option.
        • +
        • The llc "-filetype=asm" (the default) is the only + supported value for this option.
        @@ -651,13 +709,14 @@
      • The X86 backend generates inefficient floating point code when configured to generate code for systems that don't have SSE2.
      • Win64 code generation wasn't widely tested. Everything should work, but we - expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime - currently due + expect small issues to happen. Also, llvm-gcc cannot build the mingw64 + runtime currently due to several - bugs due to lack of support for the - 'u' inline assembly constraint and X87 floating point inline assembly.
      • + bugs and due to lack of support for + the + 'u' inline assembly constraint and for X87 floating point inline assembly.
      • The X86-64 backend does not yet support the LLVM IR instruction - va_arg. Currently, the llvm-gcc front-end supports variadic + va_arg. Currently, the llvm-gcc and front-ends support variadic argument constructs on X86-64 by lowering them manually.
      @@ -688,7 +747,7 @@
    19. Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 processors, thumb programs can crash or produce wrong results (PR1388).
    20. -
    21. Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested. +
    22. Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
    23. There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly execute @@ -705,7 +764,7 @@
        -
      • The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not +
      • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not support the 64-bit SPARC ABI (-m64).
      @@ -748,7 +807,7 @@
        -
      • The Itanium backend is highly experimental, and has a number of known +
      • The Itanium backend is highly experimental and has a number of known issues. We are looking for a maintainer for the Itanium backend. If you are interested, please contact the LLVMdev mailing list.
      @@ -767,8 +826,9 @@ inline assembly code.
    24. The C backend violates the ABI of common C++ programs, preventing intermixing between C++ compiled by the CBE and - C++ code compiled with llc or native compilers.
    25. + C++ code compiled with llc or native compilers.
    26. The C backend does not support all exception handling constructs.
    27. +
    28. The C backend does not support arbitrary precision integers.
    29. @@ -823,9 +883,6 @@
      • Fortran support generally works, but there are still several unresolved bugs in Bugzilla. Please see the tools/gfortran component for details.
      • - -
      • The Fortran front-end currently does not build on Darwin (without tweaks) - due to unresolved dependencies on the C front-end.
      @@ -835,19 +892,23 @@
      -The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature -technology and problems should be expected. +The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature +technology, and problems should be expected.
    + +

    It is strongly encouraged that you get the latest version from Subversion as + changes are continually making the VS support better.

    + + + + + + + +
    + +

    Before you begin to use the LLVM system, review the requirements given + below. This may save you some trouble by knowing ahead of time what hardware + and software you will need.

    + +
    + + +
    + Hardware +
    + +
    + +

    Any system that can adequately run Visual Studio .NET 2005 SP1 is fine. + The LLVM source tree and object files, libraries and executables will consume + approximately 3GB.

    + +
    + + + +
    + +

    You will need Visual Studio .NET 2005 SP1 or higher. The VS2005 SP1 + beta and the normal VS2005 still have bugs that are not completely + compatible. VS2003 would work except (at last check) it has a bug with + friend classes that you can work-around with some minor code rewriting + (and please submit a patch if you do). Earlier versions of Visual Studio + do not support the C++ standard well enough and will not work.

    + +

    You will also need the CMake build + system since it generates the project files you will use to build with.

    + +

    + Do not install the LLVM directory tree into a path containing spaces (e.g. + C:\Documents and Settings\...) as the configure step will fail.

    + +
    + + + + + +
    + +

    The remainder of this guide is meant to get you up and running with + LLVM using Visual Studio and to give you some basic information about the LLVM + environment.

    + +
    + + + + +
    + +

    Throughout this manual, the following names are used to denote paths + specific to the local system and working environment. These are not + environment variables you need to set but just strings used in the rest + of this document below. In any of the examples below, simply replace + each of these names with the appropriate pathname on your local system. + All these paths are absolute:

    + +
    +
    SRC_ROOT
    +

    This is the top level directory of the LLVM source tree.

    + +
    OBJ_ROOT
    +

    This is the top level directory of the LLVM object tree (i.e. the + tree where object files and compiled programs will be placed. It is + fixed at SRC_ROOT/win32).

    +
    + +
    + + + + +
    + +

    The object files are placed under OBJ_ROOT/Debug for debug builds + and OBJ_ROOT/Release for release (optimized) builds. These include + both executables and libararies that your application can link against.

    + +

    The files that configure would create when building on Unix are + created by the Configure project and placed in + OBJ_ROOT/llvm. You application must have OBJ_ROOT in its include + search path just before SRC_ROOT/include.

    + +
    + + + + + +
    + +
      +
    1. First, create a simple C file, name it 'hello.c':

      + +
      +
      + #include <stdio.h>
      + int main() {
      +   printf("hello world\n");
      +   return 0;
      + }
      + 
    2. + +
    3. Next, compile the C file into a LLVM bitcode file:

      + +
      +
      + % llvm-gcc -c hello.c -emit-llvm -o hello.bc
      + 
      +
      + +

      This will create the result file hello.bc which is the LLVM + bitcode that corresponds the the compiled program and the library + facilities that it required. You can execute this file directly using + lli tool, compile it to native assembly with the llc, + optimize or analyze it further with the opt tool, etc.

      + +

      Note: while you cannot do this step on Windows, you can do it on a + Unix system and transfer hello.bc to Windows. Important: + transfer as a binary file!

    4. + +
    5. Run the program using the just-in-time compiler:

      + +
      +
      + % lli hello.bc
      + 
      +
      + +

      Note: this will only work for trivial C programs. Non-trivial programs + (and any C++ program) will have dependencies on the GCC runtime that + won't be satisfied by the Microsoft runtime libraries.

    6. + +
    7. Use the llvm-dis utility to take a look at the LLVM assembly + code:

      + +
      +
      + % llvm-dis < hello.bc | more
      + 
      +
    8. + +
    9. Compile the program to C using the LLC code generator:

      + +
      +
      + % llc -march=c hello.bc
      + 
      +
    10. + +
    11. Compile to binary using Microsoft C:

      + +
      +
      + % cl hello.cbe.c
      + 
      +
      + +

      Note: this will only work for trivial C programs. Non-trivial programs + (and any C++ program) will have dependencies on the GCC runtime that + won't be satisfied by the Microsoft runtime libraries.

    12. + +
    13. Execute the native code program:

      + +
      +
      + % hello.cbe.exe
      + 
      +
    14. +
    + +
    + + + + + +
    + +

    If you are having problems building or using LLVM, or if you have any other + general questions about LLVM, please consult the Frequently + Asked Questions page.

    + +
    + + +
    + Links +
    + + +
    + +

    This document is just an introduction to how to use LLVM to do + some simple things... there are many more interesting and complicated things + that you can do that aren't documented here (but we'll gladly accept a patch + if you want to write something up!). For more information about LLVM, check + out:

    + + + +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Jeff Cohen
    + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + Index: llvm-www/releases/2.5/docs/HowToReleaseLLVM.html diff -c /dev/null llvm-www/releases/2.5/docs/HowToReleaseLLVM.html:1.1 *** /dev/null Mon Mar 2 23:19:09 2009 --- llvm-www/releases/2.5/docs/HowToReleaseLLVM.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,600 ---- + + + + How To Release LLVM To The Public + + + + +
    How To Release LLVM To The Public
    +
      +
    1. Introduction
    2. +
    3. Release Timeline
    4. +
    5. Release Process
    6. +
    7. Distribution Targets
    8. +
    + + + + + + +
    +

    + This document collects information about successfully releasing LLVM to the + public. It is the release manager's guide to ensuring that a high quality + build of LLVM is released. +

    + +

    + The following is the basic criteria for releasing LLVM: +

    + +
      +
    1. Successful configure and build.
    2. +
    3. Clean 'make check'.
    4. +
    5. No regressions in the testsuite from the previous release. This may + include performance regressions for major benchmarks.
    6. +
    +
    + + + + +
    + The release manager should attempt to have a release every 3-4 months because LLVM + does time based releases (instead of feature based). The release schedule should + be roughly as follows: +
      +
    1. Set code freeze and branch creation date for 3 months after last release + date. Announce release schedule to the LLVM community and update the website.
    2. +
    3. Create release branch and begin release process.
    4. +
    5. Send out pre-release for first round of testing. Testing will last 7-10 days. + During the first round of testing, regressions should be found and fixed. Patches + are merged from mainline to the release branch.
    6. +
    7. Generate and send out second pre-release. Bugs found during this time will + not be fixed unless absolutely critical. Bugs introduce by patches merged in + will be fixed and if so, a 3rd round of testing is needed.
    8. +
    9. The release notes should be updated during the first and second round of + pre-release testing.
    10. +
    11. Finally, release!
    12. +
    +
    + + + + + + + + + + + + +
    +

    Branch the Subversion HEAD using the following procedure:

    +
      +
    1. +

      Verify that the current Subversion HEAD is in decent shape by examining nightly + tester results.

    2. +
    3. +

      Request all developers to refrain from committing. Offenders get commit + rights taken away (temporarily).

    4. +
    5. +

      Create the release branch for llvm, llvm-gcc4.2, and + the test-suite. The branch name will be release_XX, + where XX is the major and minor release numbers. These branches can + be created without checking out anything from subversion. +

      + +
      +
      + svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
      +          https://llvm.org/svn/llvm-project/llvm/branches/release_XX
      + svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk \
      +          https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX
      + svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
      +          https://llvm.org/svn/llvm-project/test-suite/branches/release_XX
      + 
      +
      + +
    6. +

      Advise developers they can work on Subversion HEAD again.

    7. + +
    8. +

      The Release Manager should switch to the release branch (as all changes + to the release will now be done in the branch). The easiest way to do this + is to grab another working copy using the following commands:

      + +
      +
      + svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XX
      + svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX
      + svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XX
      + 
      +
    9. + +
    + + + + + +
    +

    + After creating the LLVM release branch, update the release branches' + autoconf/configure.ac version from X.Xsvn to just X.X. Update it on mainline + as well to be the next version (X.X+1svn). Regenerated the configure script + for both. This must be done for both llvm and the test-suite. +

    +

    In addition, the version number of all the Bugzilla components must be + updated for the next release. +

    +
    + + + +
    +

    + Create source distributions for LLVM, LLVM GCC, and the LLVM Test Suite by + exporting the source from Subversion and archiving it. This can be done with + the following commands: +

    + +
    +
    + svn export https://llvm.org/svn/llvm-project/llvm/branches/release_XX llvm-X.X
    + svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX llvm-gcc4.2-X.X.source
    + svn export https://llvm.org/svn/llvm-project/test-suite/branches/release_XX llvm-test-X.X
    + tar -cvf - llvm-X.X          | gzip > llvm-X.X.tar.gz
    + tar -cvf - llvm-test-X.X     | gzip > llvm-test-X.X.tar.gz
    + tar -cvf - llvm-gcc4.2-X.X.source | gzip > llvm-gcc-4.2-X.X.source.tar.gz
    + 
    +
    +
    + + + +
    +

    + Build both debug and release (optimized) versions of LLVM on all + platforms. Ensure the build is warning and error free on each platform. + Note that when building the LLVM GCC Binary, use a release build of LLVM. +

    +
    + + + +
    +

    + Creating the LLVM GCC binary distribution (release/optimized) requires + performing the following steps for each supported platform: +

    + +
      +
    1. + Build the LLVM GCC front-end by following the directions in the README.LLVM + file. Be sure to build with LLVM_VERSION_INFO=X.X, where X is the major and + minor release numbers. +
    2. + +
    3. + Copy the installation directory to a directory named for the specific target. + For example on Red Hat Enterprise Linux, the directory would be named + llvm-gcc4.0-2.1-x86-linux-RHEL4. Archive and compress the new directory. +
    4. +
    +
    + + + +
    +

    + Using the newly built llvm-gcc and llvm, reconfigure llvm to locate llvm-gcc. + Run make check and ensure there are no unexpected failures. If there + are, resolve the failures or file a bug. If there is a fix commited to mainline, + merge back into the release branch, and restart testing by + re-building LLVM and llvm-gcc. If no + fix will be made, XFAIL the test and commit back to the release branch. +

    + +

    + Ensure that 'make check' passes on all platforms for all targets. The + test suite must complete with "0 unexpected failures" before sending out the + pre-releases for testing. +

    +
    + + + +
    +

    + Run the llvm-test suite and ensure there are no unacceptable + failures. Unacceptable failures are regression from the previous release + and (optionally) major performance regressions from the previous release. + If a regression is found a bug is filled, but the pre-releases may still go + out.

    +
    + + + +
    +

    + You can, optionally, create source and binary RPM packages for LLVM. These may + make it easier to get LLVM into a distribution. This can be done with the + following commands: +

    + +
    +
    + make dist        # Build the distribution source tarball
    + make dist-check  # Check that the source tarball can build itself.
    + cp llvm-M.m.tar.gz /usr/src/redhat/SOURCES  # Required by rpmbuild
    + make srpm # for source rpm
    + make rpm  # for binary rpm
    + 
    +
    + +

    + First, use make dist to simply build the distribution. Any failures + need to be corrected (on the branch). Once make dist can be + successful, do make dist-check. This target will do the same thing as + the 'dist' target but also test that distribution to make sure it can build + itself and runs make check as well. This ensures that needed files + are not missing and that the src tarball can be successfully unpacked, built, + installed, and cleaned. Once you have a reliable tarball, you need to copy it + to the /usr/src/redhat/SOURCES directory which is a requirement of + the rpmbuild tool. The last two make invocations just run rpmbuild to + build either a source (srpm) or binary (rpm) RPM package. +

    +
    + + + +
    +

    + Once all testing has been completed and appropriate bugs filed, the pre-release + tar balls may be put on the website and the LLVM community is notified. Ask that + all LLVM developers test the release in 2 ways:

    +
      +
    1. Download llvm-X.X, llvm-test-X.X, and the appropriate llvm-gcc4 binary. + Run "make check" and the full llvm-test suite (make TEST=nightly report).
    2. +
    3. Download llvm-X.X, llvm-test-X.X, and the llvm-gcc4 source. Compile + everything. Run "make check" and the full llvm-test suite (make TEST=nightly + report).
    4. +
    +

    Ask LLVM developers to submit the report and make check results to the list. + Verify that there are no regressions from the previous release. For + unsupported targets, verify that make check at least is clean.

    + +

    The first round of pre-release testing will be the longest. During this time, + all regressions must be fixed before the second pre-release is created (repeat + steps 4-8).

    + +

    If this is the second round of testing, this is only to ensure the bug fixes + previously merged in have not created new major problems. This is not the time + to solve additional and unrelated bugs. If no patches are merged in, the release + is determined to be ready and the release manager may move onto the next step.

    +
    + + + + +
    +

    Tag the release branch using the following procedure:

    +
    +
    + svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XX \
    +          https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XX
    + svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX \
    +          https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XX
    + svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
    +          https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XX
    + 
    +
    +
    + + + +
    +

    + Review the documentation and ensure that it is up to date. The Release Notes + must be updated to reflect bug fixes, new known issues, and changes in the + list of supported platforms. The Getting Started Guide should be updated to + reflect the new release version number tag avaiable from Subversion and + changes in basic system requirements. Merge both changes from mainline into + the release branch. +

    +
    + + + +
    +

    + The LLVM demo page must be updated to use the new release. This consists of + using the llvm-gcc binary and building LLVM. Update the website demo page + configuration to use the new release.

    +
    + + + +
    +

    + The website must be updated before the release announcement is sent out. Here is + what to do:

    +
      +
    1. Check out the website module from CVS.
    2. +
    3. Create a new subdirectory X.X in the releases directory.
    4. +
    5. Commit the llvm, test-suite, llvm-gcc source, + and llvm-gcc binaries in this new directory.
    6. +
    7. Copy and commit the llvm/docs and LICENSE.txt + files into this new directory. The docs should be built with BUILD_FOR_WEBSITE=1.
    8. +
    9. Commit the index.html to the release/X.X directory to redirect (use from previous + release.
    10. +
    11. Update the releases/download.html file with the new release.
    12. +
    13. Update the releases/index.html with the new release and link to + release documentation.
    14. +
    15. Finally, update the main page (index.html and sidebar) to + point to the new release and release announcement. Make sure this all gets + commited back into Subversion.
    16. +
    +
    + + + +
    +

    Have Chris send out the release announcement when everything is finished.

    +
    + + + + + + +
    Overview
    +
    +

    + The first thing you need to understand is that there are multiple make targets + to support this feature. Here's an overview, we'll delve into the details + later. +

    + +
      +
    • distdir - builds the distribution directory from which the + distribution will be packaged
    • +
    • dist - builds each of the distribution tarballs (tar.gz, + tar.bzip2, .zip). These can be built individually as well, with separate + targets.
    • +
    • dist-check - this is identical to dist but includes a + check on the distribution that ensures the tarball can: unpack + successfully, compile correctly, pass 'make check', and pass + 'make clean'.
    • +
    • dist-clean- this just does a normal clean but also cleans up the + stuff generated by the other three dist targets (above).
    • +
    + +

    + Okay, that's the basic functionality. When making a release, we want to ensure + that the tree you build the distribution from passes + dist-check. Beyond fixing the usual bugs, there is generally one + impediment to making the release in this fashion: missing files. The + dist-check process guards against that possibility. It will either + fail and that failure will indicate what's missing, or it will succeed meaning + that it has proved that the tarballs can actually succeed in building LLVM + correctly and that it passes make check. +

    +
    + + + +
    distdir
    +
    +

    + This target builds the distribution directory which is the directory from + which the tarballs are generated. The distribution directory has the same + name as the release, e.g. LLVM-1.7). This target goes through the following + process: +

    + +
      +
    1. First, if there was an old distribution directory (for the current + release), it is removed in its entirety and you see Removing old + LLVM-1.7
    2. +
    3. Second, it issues a make all ENABLE_OPTIMIZED=3D1 to ensure + that the everything in your tree can be built in release mode. Often + times there are discrepancies in building between debug and release + modes so it enforces release mode first. If that fails, the + distdir target fails too. This is preceded by the message + Making 'all' to verify build.
    4. +
    5. Next, it traverses your source tree and copies it to a new directory + that has the name of the release (LLVM-M.m in our current + case). This is the directory that will get tar'd. It contains all the + software that needs to be in the distribution. During the copying + process, it omits generated files, SVN directories, and any other + "cruft" that's in your build tree. This is done to eliminate the + possibility of huge distribution tarballs that include useless or + irrelevant stuff in them. This is the trickiest part of making the + distribution. Done manually you will either include stuff that + shouldn't be in the distribution or exclude stuff that should. This + step is preceded by the message Building Distribution Directory + LLVM-1.7
    6. +
    7. The distribution directory is then traversed and all CVS or + .svn directories are removed. You see: Eliminating CVS/.svn + directories from distribution
    8. +
    9. The recursive dist-hook target is executed. This gives each + directory a chance to modify the distribution in some way (more on this + below).
    10. +
    11. The distribution directory is traversed and the correct file + permissions and modes are set based on the type of file.
    12. +
    + +

    + To control the process of making the distribution directory correctly, each + Makefile can utilize two features: +

    + +
      +
    1. EXTRA_DIST - this make variable specifies which files + it should distribute. By default, all source files are automatically + included for distribution as well as certain well known files + (see DistAlways variable in Makefile.rules for details). Each Makefile + specifies, via the EXTRA_DIST variable, which additional files + need to be distributed. Only those files that are needed to build LLVM + should be added to EXTRA_DIST. EXTRA_DIST contains a + list of file or directory names that should be distributed. For example, + the top level Makefile contains EXTRA_DIST := test llvm.spec + include. This means that in addition to regular things that are + distributed at the top level (CREDITS.txt, LICENSE.txt, etc.) + the distribution should contain the entire test and + include directories as well as the llvm.spec file.
    2. +
    3. dist-hook - this make target can be used to alter the + content of the distribution directory. For example, in the top level + Makefile there is some logic to eliminate files in the include + subtree that are generated by the configure script. These should not be + distributed. Similarly, any dist-hook target found in any + directory can add or remove or modify things just before it gets + packaged. Any transformation is permitted. Generally, not much is + needed.
    4. +
    + +

    + You will see various messages if things go wrong: +

    + +
      +
    1. During the copying process, any files that are missing will be flagged + with: ===== WARNING: Distribution Source 'dir/file' Not Found! + These must be corrected by either adding the file or removing it from + EXTRA_DIST.
    2. +
    3. If you build the distribution with VERBOSE=1, then you might + also see: Skipping non-existent 'dir/file' in certain cases + where it's okay to skip the file.
    4. +
    5. The target can fail if any of the things it does fail. Error messages + should indicate what went wrong.
    6. +
    +
    + + +
    dist
    +
    +

    + This target does exactly what distdir target does, but also includes + assembling the tarballs. There are actually four related targets here: +

    + +
      +
    • dist-gzip: package the gzipped distribution tar + file. The distribution directory is packaged into a single file ending + in .tar.gz which is gzip compressed.
    • +
    • dist-bzip2: package the bzip2 distribution tar file. + The distribution directory is packaged into a single file ending in + .tar.bzip2 which is bzip2 compressed.
    • +
    • dist-zip: package the zip distribution file. The + distribution directory is packaged into a single file ending in + .zip which is zip compressed.
    • +
    • dist: does all three, dist-gzip, dist-bzip2, + dist-zip
    • +
    +
    + + +
    dist-check
    +
    +

    + This target checks the distribution. The basic idea is that it unpacks the + distribution tarball and ensures that it can build. It takes the following + actions: +

    + +
      +
    1. It depends on the dist-gzip target which, if it hasn't already + been built, builds the gzip tar bundle (see dist and distdir + above).
    2. +
    3. removes any pre-existing _distcheckdir at the top level.
    4. +
    5. creates a new _distcheckdir directory at the top level.
    6. +
    7. creates a build subdirectory and an install + subdirectory under _distcheckdir.
    8. +
    9. unzips and untars the release tarball into _distcheckdir, + creating LLVM-1.7 directory (from the tarball).
    10. +
    11. in the build subdirectory, it configures with appropriate options to + build from the unpacked source tarball into the build directory + with installation in the install directory.
    12. +
    13. runs make all
    14. +
    15. runs make check
    16. +
    17. runs make install
    18. +
    19. runs make uninstall
    20. +
    21. runs make dist
    22. +
    23. runs make clean
    24. +
    25. runs make dist-clean
    26. +
    + +

    + If it can pass all that, the distribution will be deemed distribution worth y + and you will see: +

    + +
    ===== LLVM-1.7.tar.gz Ready For Distribution =====
    + +

    + This means the tarball should then be tested on other platforms and have the + nightly test run against it. If those all pass, THEN it is ready for + distribution. +

    + +

    + A note about disk space: using dist-check will easily triple the + amount of disk space your build tree is using. You might want to check + available space before you begin. +

    +
    + + +
    dist-clean
    +
    +

    + In addition to doing a normal clean, this target will clean up the + files and directories created by the distribution targets. In particular the + distribution directory (LLVM-X.X), check directory + (_distcheckdir), and the various tarballs will be removed. You do + this after the release has shipped and you no longer need this stuff in your + build tree. +

    +
    + + +
    +
    + Valid CSS + Valid HTML 4.01 + The LLVM Compiler Infrastructure +
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + Index: llvm-www/releases/2.5/docs/HowToSubmitABug.html diff -c /dev/null llvm-www/releases/2.5/docs/HowToSubmitABug.html:1.1 *** /dev/null Mon Mar 2 23:19:09 2009 --- llvm-www/releases/2.5/docs/HowToSubmitABug.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,355 ---- + + + + How to submit an LLVM bug report + + + + +
    + How to submit an LLVM bug report +
    + + + + + + +
    +
      +
    1. Introduction - Got bugs?
    2. +
    3. Crashing Bugs +
    4. +
    5. Miscompilations
    6. +
    7. Incorrect code generation (JIT and LLC)
    8. +
    +
    +

    Written by Chris Lattner and + Misha Brukman

    +
    +
    + Debugging +
    + + + + + +
    + +

    If you're working with LLVM and run into a bug, we definitely want to know + about it. This document describes what you can do to increase the odds of + getting it fixed quickly.

    + +

    Basically you have to do two things at a minimum. First, decide whether the + bug crashes the compiler (or an LLVM pass), or if the + compiler is miscompiling the program (i.e., the + compiler successfully produces an executable, but it doesn't run right). Based + on + what type of bug it is, follow the instructions in the linked section to narrow + down the bug so that the person who fixes it will be able to find the problem + more easily.

    + +

    Once you have a reduced test-case, go to the LLVM Bug Tracking + System and fill out the form with the necessary details (note that you don't + need to pick a catagory, just use the "new-bugs" catagory if you're not sure). + The bug description should contain the following + information:

    + +
      +
    • All information necessary to reproduce the problem.
    • +
    • The reduced test-case that triggers the bug.
    • +
    • The location where you obtained LLVM (if not from our Subversion + repository).
    • +
    + +

    Thanks for helping us make LLVM better!

    + +
    + + + + + +
    + +

    More often than not, bugs in the compiler cause it to crash—often due + to an assertion failure of some sort. The most important + piece of the puzzle is to figure out if it is crashing in the GCC front-end + or if it is one of the LLVM libraries (e.g. the optimizer or code generator) + that has problems.

    + +

    To figure out which component is crashing (the front-end, + optimizer or code generator), run the + llvm-gcc command line as you were when the crash occurred, but + with the following extra command line options:

    + +
      +
    • -O0 -emit-llvm: If llvm-gcc still crashes when + passed these options (which disable the optimizer and code generator), then + the crash is in the front-end. Jump ahead to the section on front-end bugs.
    • + +
    • -emit-llvm: If llvm-gcc crashes with this option + (which disables the code generator), you found an optimizer bug. Jump ahead + to compile-time optimization bugs.
    • + +
    • Otherwise, you have a code generator crash. Jump ahead to code generator bugs.
    • + +
    + +
    + + + + +
    + +

    If the problem is in the front-end, you should re-run the same + llvm-gcc command that resulted in the crash, but add the + -save-temps option. The compiler will crash again, but it will leave + behind a foo.i file (containing preprocessed C source code) and + possibly foo.s for each + compiled foo.c file. Send us the foo.i file, + along with the options you passed to llvm-gcc, and a brief description of the + error it caused.

    + +

    The delta tool helps to reduce the + preprocessed file down to the smallest amount of code that still replicates the + problem. You're encouraged to use delta to reduce the code to make the + developers' lives easier. This website + has instructions on the best way to use delta.

    + +
    + + + + +
    + +

    If you find that a bug crashes in the optimizer, compile your test-case to a + .bc file by passing "-emit-llvm -O0 -c -o foo.bc". + Then run:

    + +
    +

    opt -std-compile-opts -debug-pass=Arguments foo.bc + -disable-output

    +
    + +

    This command should do two things: it should print out a list of passes, and + then it should crash in the same was as llvm-gcc. If it doesn't crash, please + follow the instructions for a front-end bug.

    + +

    If this does crash, then you should be able to debug this with the following + bugpoint command:

    + +
    +

    bugpoint foo.bc <list of passes printed by + opt>

    +
    + +

    Please run this, then file a bug with the instructions and reduced .bc files + that bugpoint emits. If something goes wrong with bugpoint, please submit the + "foo.bc" file and the list of passes printed by opt.

    + +
    + + + + +
    + +

    If you find a bug that crashes llvm-gcc in the code generator, compile your + source file to a .bc file by passing "-emit-llvm -c -o foo.bc" + to llvm-gcc (in addition to the options you already pass). Once your have + foo.bc, one of the following commands should fail:

    + +
      +
    1. llc foo.bc -f
    2. +
    3. llc foo.bc -f -relocation-model=pic
    4. +
    5. llc foo.bc -f -relocation-model=static
    6. +
    7. llc foo.bc -f -enable-eh
    8. +
    9. llc foo.bc -f -relocation-model=pic -enable-eh
    10. +
    11. llc foo.bc -f -relocation-model=static -enable-eh
    12. +
    + +

    If none of these crash, please follow the instructions for a + front-end bug. If one of these do crash, you should + be able to reduce this with one of the following bugpoint command lines (use + the one corresponding to the command above that failed):

    + +
      +
    1. bugpoint -run-llc foo.bc
    2. +
    3. bugpoint -run-llc foo.bc --tool-args + -relocation-model=pic
    4. +
    5. bugpoint -run-llc foo.bc --tool-args + -relocation-model=static
    6. +
    7. bugpoint -run-llc foo.bc --tool-args -enable-eh
    8. +
    9. bugpoint -run-llc foo.bc --tool-args + -relocation-model=pic -enable-eh
    10. +
    11. bugpoint -run-llc foo.bc --tool-args + -relocation-model=static -enable-eh
    12. +
    + +

    Please run this, then file a bug with the instructions and reduced .bc file + that bugpoint emits. If something goes wrong with bugpoint, please submit the + "foo.bc" file and the option that llc crashes with.

    + +
    + + + + + +
    + +

    If llvm-gcc successfully produces an executable, but that executable doesn't + run right, this is either a bug in the code or a bug in the + compiler. The first thing to check is to make sure it is not using undefined + behavior (e.g. reading a variable before it is defined). In particular, check + to see if the program valgrinds clean, + passes purify, or some other memory checker tool. Many of the "LLVM bugs" that + we have chased down ended up being bugs in the program being compiled, not + LLVM.

    + +

    Once you determine that the program itself is not buggy, you should choose + which code generator you wish to compile the program with (e.g. C backend, the + JIT, or LLC) and optionally a series of LLVM passes to run. For example:

    + +
    +

    + bugpoint -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]

    +
    + +

    bugpoint will try to narrow down your list of passes to the one pass + that causes an error, and simplify the bitcode file as much as it can to assist + you. It will print a message letting you know how to reproduce the resulting + error.

    + +
    + + + + + +
    + +

    Similarly to debugging incorrect compilation by mis-behaving passes, you can + debug incorrect code generation by either LLC or the JIT, using + bugpoint. The process bugpoint follows in this case is to try + to narrow the code down to a function that is miscompiled by one or the other + method, but since for correctness, the entire program must be run, + bugpoint will compile the code it deems to not be affected with the C + Backend, and then link in the shared object it generates.

    + +

    To debug the JIT:

    + +
    +
    + bugpoint -run-jit -output=[correct output file] [bitcode file]  \
    +          --tool-args -- [arguments to pass to lli]               \
    +          --args -- [program arguments]
    + 
    +
    + +

    Similarly, to debug the LLC, one would run:

    + +
    +
    + bugpoint -run-llc -output=[correct output file] [bitcode file]  \
    +          --tool-args -- [arguments to pass to llc]               \
    +          --args -- [program arguments]
    + 
    +
    + +

    Special note: if you are debugging MultiSource or SPEC tests that + already exist in the llvm/test hierarchy, there is an easier way to + debug the JIT, LLC, and CBE, using the pre-written Makefile targets, which + will pass the program options specified in the Makefiles:

    + +
    +

    + cd llvm/test/../../program
    + make bugpoint-jit +

    +
    + +

    At the end of a successful bugpoint run, you will be presented + with two bitcode files: a safe file which can be compiled with the C + backend and the test file which either LLC or the JIT + mis-codegenerates, and thus causes the error.

    + +

    To reproduce the error that bugpoint found, it is sufficient to do + the following:

    + +
      + +
    1. Regenerate the shared object from the safe bitcode file:

      + +
      +

      + llc -march=c safe.bc -o safe.c
      + gcc -shared safe.c -o safe.so +

      +
    2. + +
    3. If debugging LLC, compile test bitcode native and link with the shared + object:

      + +
      +

      + llc test.bc -o test.s -f
      + gcc test.s safe.so -o test.llc
      + ./test.llc [program options] +

      +
    4. + +
    5. If debugging the JIT, load the shared object and supply the test + bitcode:

      + +
      +

      lli -load=safe.so test.bc [program options]

      +
    6. + +
    + +
    + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Chris Lattner
    + The LLVM Compiler Infrastructure +
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/LangRef.html diff -c /dev/null llvm-www/releases/2.5/docs/LangRef.html:1.1 *** /dev/null Mon Mar 2 23:19:09 2009 --- llvm-www/releases/2.5/docs/LangRef.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,6551 ---- + + + + LLVM Assembly Language Reference Manual + + + + + + + + +
    LLVM Language Reference Manual
    +
      +
    1. Abstract
    2. +
    3. Introduction
    4. +
    5. Identifiers
    6. +
    7. High Level Structure +
        +
      1. Module Structure
      2. +
      3. Linkage Types
      4. +
      5. Calling Conventions
      6. +
      7. Named Types
      8. +
      9. Global Variables
      10. +
      11. Functions
      12. +
      13. Aliases
      14. +
      15. Parameter Attributes
      16. +
      17. Function Attributes
      18. +
      19. Garbage Collector Names
      20. +
      21. Module-Level Inline Assembly
      22. +
      23. Data Layout
      24. +
      +
    8. +
    9. Type System +
        +
      1. Type Classifications
      2. +
      3. Primitive Types +
          +
        1. Floating Point Types
        2. +
        3. Void Type
        4. +
        5. Label Type
        6. +
        +
      4. +
      5. Derived Types +
          +
        1. Integer Type
        2. +
        3. Array Type
        4. +
        5. Function Type
        6. +
        7. Pointer Type
        8. +
        9. Structure Type
        10. +
        11. Packed Structure Type
        12. +
        13. Vector Type
        14. +
        15. Opaque Type
        16. +
        +
      6. +
      7. Type Up-references
      8. +
      +
    10. +
    11. Constants +
        +
      1. Simple Constants
      2. +
      3. Aggregate Constants
      4. +
      5. Global Variable and Function Addresses
      6. +
      7. Undefined Values
      8. +
      9. Constant Expressions
      10. +
      +
    12. +
    13. Other Values +
        +
      1. Inline Assembler Expressions
      2. +
      +
    14. +
    15. Instruction Reference +
        +
      1. Terminator Instructions +
          +
        1. 'ret' Instruction
        2. +
        3. 'br' Instruction
        4. +
        5. 'switch' Instruction
        6. +
        7. 'invoke' Instruction
        8. +
        9. 'unwind' Instruction
        10. +
        11. 'unreachable' Instruction
        12. +
        +
      2. +
      3. Binary Operations +
          +
        1. 'add' Instruction
        2. +
        3. 'sub' Instruction
        4. +
        5. 'mul' Instruction
        6. +
        7. 'udiv' Instruction
        8. +
        9. 'sdiv' Instruction
        10. +
        11. 'fdiv' Instruction
        12. +
        13. 'urem' Instruction
        14. +
        15. 'srem' Instruction
        16. +
        17. 'frem' Instruction
        18. +
        +
      4. +
      5. Bitwise Binary Operations +
          +
        1. 'shl' Instruction
        2. +
        3. 'lshr' Instruction
        4. +
        5. 'ashr' Instruction
        6. +
        7. 'and' Instruction
        8. +
        9. 'or' Instruction
        10. +
        11. 'xor' Instruction
        12. +
        +
      6. +
      7. Vector Operations +
          +
        1. 'extractelement' Instruction
        2. +
        3. 'insertelement' Instruction
        4. +
        5. 'shufflevector' Instruction
        6. +
        +
      8. +
      9. Aggregate Operations +
          +
        1. 'extractvalue' Instruction
        2. +
        3. 'insertvalue' Instruction
        4. +
        +
      10. +
      11. Memory Access and Addressing Operations +
          +
        1. 'malloc' Instruction
        2. +
        3. 'free' Instruction
        4. +
        5. 'alloca' Instruction
        6. +
        7. 'load' Instruction
        8. +
        9. 'store' Instruction
        10. +
        11. 'getelementptr' Instruction
        12. +
        +
      12. +
      13. Conversion Operations +
          +
        1. 'trunc .. to' Instruction
        2. +
        3. 'zext .. to' Instruction
        4. +
        5. 'sext .. to' Instruction
        6. +
        7. 'fptrunc .. to' Instruction
        8. +
        9. 'fpext .. to' Instruction
        10. +
        11. 'fptoui .. to' Instruction
        12. +
        13. 'fptosi .. to' Instruction
        14. +
        15. 'uitofp .. to' Instruction
        16. +
        17. 'sitofp .. to' Instruction
        18. +
        19. 'ptrtoint .. to' Instruction
        20. +
        21. 'inttoptr .. to' Instruction
        22. +
        23. 'bitcast .. to' Instruction
        24. +
        +
      14. +
      15. Other Operations +
          +
        1. 'icmp' Instruction
        2. +
        3. 'fcmp' Instruction
        4. +
        5. 'phi' Instruction
        6. +
        7. 'select' Instruction
        8. +
        9. 'call' Instruction
        10. +
        11. 'va_arg' Instruction
        12. +
        +
      16. +
      +
    16. +
    17. Intrinsic Functions +
        +
      1. Variable Argument Handling Intrinsics +
          +
        1. 'llvm.va_start' Intrinsic
        2. +
        3. 'llvm.va_end' Intrinsic
        4. +
        5. 'llvm.va_copy' Intrinsic
        6. +
        +
      2. +
      3. Accurate Garbage Collection Intrinsics +
          +
        1. 'llvm.gcroot' Intrinsic
        2. +
        3. 'llvm.gcread' Intrinsic
        4. +
        5. 'llvm.gcwrite' Intrinsic
        6. +
        +
      4. +
      5. Code Generator Intrinsics +
          +
        1. 'llvm.returnaddress' Intrinsic
        2. +
        3. 'llvm.frameaddress' Intrinsic
        4. +
        5. 'llvm.stacksave' Intrinsic
        6. +
        7. 'llvm.stackrestore' Intrinsic
        8. +
        9. 'llvm.prefetch' Intrinsic
        10. +
        11. 'llvm.pcmarker' Intrinsic
        12. +
        13. llvm.readcyclecounter' Intrinsic
        14. +
        +
      6. +
      7. Standard C Library Intrinsics +
          +
        1. 'llvm.memcpy.*' Intrinsic
        2. +
        3. 'llvm.memmove.*' Intrinsic
        4. +
        5. 'llvm.memset.*' Intrinsic
        6. +
        7. 'llvm.sqrt.*' Intrinsic
        8. +
        9. 'llvm.powi.*' Intrinsic
        10. +
        11. 'llvm.sin.*' Intrinsic
        12. +
        13. 'llvm.cos.*' Intrinsic
        14. +
        15. 'llvm.pow.*' Intrinsic
        16. +
        +
      8. +
      9. Bit Manipulation Intrinsics +
          +
        1. 'llvm.bswap.*' Intrinsics
        2. +
        3. 'llvm.ctpop.*' Intrinsic
        4. +
        5. 'llvm.ctlz.*' Intrinsic
        6. +
        7. 'llvm.cttz.*' Intrinsic
        8. +
        9. 'llvm.part.select.*' Intrinsic
        10. +
        11. 'llvm.part.set.*' Intrinsic
        12. +
        +
      10. +
      11. Debugger intrinsics
      12. +
      13. Exception Handling intrinsics
      14. +
      15. Trampoline Intrinsic +
          +
        1. 'llvm.init.trampoline' Intrinsic
        2. +
        +
      16. +
      17. Atomic intrinsics +
          +
        1. llvm.memory_barrier
        2. +
        3. llvm.atomic.cmp.swap
        4. +
        5. llvm.atomic.swap
        6. +
        7. llvm.atomic.load.add
        8. +
        9. llvm.atomic.load.sub
        10. +
        11. llvm.atomic.load.and
        12. +
        13. llvm.atomic.load.nand
        14. +
        15. llvm.atomic.load.or
        16. +
        17. llvm.atomic.load.xor
        18. +
        19. llvm.atomic.load.max
        20. +
        21. llvm.atomic.load.min
        22. +
        23. llvm.atomic.load.umax
        24. +
        25. llvm.atomic.load.umin
        26. +
        +
      18. +
      19. General intrinsics +
          +
        1. + 'llvm.var.annotation' Intrinsic
        2. +
        3. + 'llvm.annotation.*' Intrinsic
        4. +
        5. + 'llvm.trap' Intrinsic
        6. +
        7. + 'llvm.stackprotector' Intrinsic
        8. +
        +
      20. +
      +
    18. +
    + +
    +

    Written by Chris Lattner + and Vikram Adve

    +
    + + + + + +
    +

    This document is a reference manual for the LLVM assembly language. + LLVM is a Static Single Assignment (SSA) based representation that provides + type safety, low-level operations, flexibility, and the capability of + representing 'all' high-level languages cleanly. It is the common code + representation used throughout all phases of the LLVM compilation + strategy.

    +
    + + + + + +
    + +

    The LLVM code representation is designed to be used in three + different forms: as an in-memory compiler IR, as an on-disk bitcode + representation (suitable for fast loading by a Just-In-Time compiler), + and as a human readable assembly language representation. This allows + LLVM to provide a powerful intermediate representation for efficient + compiler transformations and analysis, while providing a natural means + to debug and visualize the transformations. The three different forms + of LLVM are all equivalent. This document describes the human readable + representation and notation.

    + +

    The LLVM representation aims to be light-weight and low-level + while being expressive, typed, and extensible at the same time. It + aims to be a "universal IR" of sorts, by being at a low enough level + that high-level ideas may be cleanly mapped to it (similar to how + microprocessors are "universal IR's", allowing many source languages to + be mapped to them). By providing type information, LLVM can be used as + the target of optimizations: for example, through pointer analysis, it + can be proven that a C automatic variable is never accessed outside of + the current function... allowing it to be promoted to a simple SSA + value instead of a memory location.

    + +
    + + + + +
    + +

    It is important to note that this document describes 'well formed' + LLVM assembly language. There is a difference between what the parser + accepts and what is considered 'well formed'. For example, the + following instruction is syntactically okay, but not well formed:

    + +
    +
    + %x = add i32 1, %x
    + 
    +
    + +

    ...because the definition of %x does not dominate all of + its uses. The LLVM infrastructure provides a verification pass that may + be used to verify that an LLVM module is well formed. This pass is + automatically run by the parser after parsing input assembly and by + the optimizer before it outputs bitcode. The violations pointed out + by the verifier pass indicate bugs in transformation passes or input to + the parser.

    +
    + + + + + + + +
    + +

    LLVM identifiers come in two basic types: global and local. Global + identifiers (functions, global variables) begin with the @ character. Local + identifiers (register names, types) begin with the % character. Additionally, + there are three different formats for identifiers, for different purposes:

    + +
      +
    1. Named values are represented as a string of characters with their prefix. + For example, %foo, @DivisionByZero, %a.really.long.identifier. The actual + regular expression used is '[%@][a-zA-Z$._][a-zA-Z$._0-9]*'. + Identifiers which require other characters in their names can be surrounded + with quotes. Special characters may be escaped using "\xx" where xx is the + ASCII code for the character in hexadecimal. In this way, any character can + be used in a name value, even quotes themselves. + +
    2. Unnamed values are represented as an unsigned numeric value with their + prefix. For example, %12, @2, %44.
    3. + +
    4. Constants, which are described in a section about + constants, below.
    5. +
    + +

    LLVM requires that values start with a prefix for two reasons: Compilers + don't need to worry about name clashes with reserved words, and the set of + reserved words may be expanded in the future without penalty. Additionally, + unnamed identifiers allow a compiler to quickly come up with a temporary + variable without having to avoid symbol table conflicts.

    + +

    Reserved words in LLVM are very similar to reserved words in other + languages. There are keywords for different opcodes + ('add', + 'bitcast', + 'ret', etc...), for primitive type names ('void', 'i32', etc...), + and others. These reserved words cannot conflict with variable names, because + none of them start with a prefix character ('%' or '@').

    + +

    Here is an example of LLVM code to multiply the integer variable + '%X' by 8:

    + +

    The easy way:

    + +
    +
    + %result = mul i32 %X, 8
    + 
    +
    + +

    After strength reduction:

    + +
    +
    + %result = shl i32 %X, i8 3
    + 
    +
    + +

    And the hard way:

    + +
    +
    + add i32 %X, %X           ; yields {i32}:%0
    + add i32 %0, %0           ; yields {i32}:%1
    + %result = add i32 %1, %1
    + 
    +
    + +

    This last way of multiplying %X by 8 illustrates several + important lexical features of LLVM:

    + +
      + +
    1. Comments are delimited with a ';' and go until the end of + line.
    2. + +
    3. Unnamed temporaries are created when the result of a computation is not + assigned to a named value.
    4. + +
    5. Unnamed temporaries are numbered sequentially
    6. + +
    + +

    ...and it also shows a convention that we follow in this document. When + demonstrating instructions, we will follow an instruction with a comment that + defines the type and name of value produced. Comments are shown in italic + text.

    + +
    + + + + + + + + +
    + +

    LLVM programs are composed of "Module"s, each of which is a + translation unit of the input programs. Each module consists of + functions, global variables, and symbol table entries. Modules may be + combined together with the LLVM linker, which merges function (and + global variable) definitions, resolves forward declarations, and merges + symbol table entries. Here is an example of the "hello world" module:

    + +
    +
    ; Declare the string constant as a global constant...
    + @.LC0 = internal constant [13 x i8] c"hello world\0A\00"          ; [13 x i8]*
    + 
    + ; External declaration of the puts function
    + declare i32 @puts(i8 *)                                            ; i32(i8 *)* 
    + 
    + ; Definition of main function
    + define i32 @main() {                                                 ; i32()* 
    +         ; Convert [13 x i8]* to i8  *...
    +         %cast210 = getelementptr [13 x i8]* @.LC0, i64 0, i64 0 ; i8 *
    + 
    +         ; Call puts function to write out the string to stdout...
    +         call i32 @puts(i8 * %cast210)                              ; i32
    +         ret i32 0
    }
    +
    +
    + +

    This example is made up of a global variable + named ".LC0", an external declaration of the "puts" + function, and a function definition + for "main".

    + +

    In general, a module is made up of a list of global values, + where both functions and global variables are global values. Global values are + represented by a pointer to a memory location (in this case, a pointer to an + array of char, and a pointer to a function), and have one of the following linkage types.

    + +
    + + + + +
    + +

    + All Global Variables and Functions have one of the following types of linkage: +

    + +
    + +
    private:
    + +
    Global values with private linkage are only directly accessible by + objects in the current module. In particular, linking code into a module with + an private global value may cause the private to be renamed as necessary to + avoid collisions. Because the symbol is private to the module, all + references can be updated. This doesn't show up in any symbol table in the + object file. +
    + +
    internal:
    + +
    Similar to private, but the value shows as a local symbol (STB_LOCAL in + the case of ELF) in the object file. This corresponds to the notion of the + 'static' keyword in C. +
    + +
    linkonce:
    + +
    Globals with "linkonce" linkage are merged with other globals of + the same name when linkage occurs. This is typically used to implement + inline functions, templates, or other code which must be generated in each + translation unit that uses it. Unreferenced linkonce globals are + allowed to be discarded. +
    + +
    common:
    + +
    "common" linkage is exactly the same as linkonce + linkage, except that unreferenced common globals may not be + discarded. This is used for globals that may be emitted in multiple + translation units, but that are not guaranteed to be emitted into every + translation unit that uses them. One example of this is tentative + definitions in C, such as "int X;" at global scope. +
    + +
    weak:
    + +
    "weak" linkage is the same as common linkage, except + that some targets may choose to emit different assembly sequences for them + for target-dependent reasons. This is used for globals that are declared + "weak" in C source code. +
    + +
    appending:
    + +
    "appending" linkage may only be applied to global variables of + pointer to array type. When two global variables with appending linkage are + linked together, the two global arrays are appended together. This is the + LLVM, typesafe, equivalent of having the system linker append together + "sections" with identical names when .o files are linked. +
    + +
    extern_weak:
    +
    The semantics of this linkage follow the ELF object file model: the + symbol is weak until linked, if not linked, the symbol becomes null instead + of being an undefined reference. +
    + +
    externally visible:
    + +
    If none of the above identifiers are used, the global is externally + visible, meaning that it participates in linkage and can be used to resolve + external symbol references. +
    +
    + +

    + The next two types of linkage are targeted for Microsoft Windows platform + only. They are designed to support importing (exporting) symbols from (to) + DLLs (Dynamic Link Libraries). +

    + +
    +
    dllimport:
    + +
    "dllimport" linkage causes the compiler to reference a function + or variable via a global pointer to a pointer that is set up by the DLL + exporting the symbol. On Microsoft Windows targets, the pointer name is + formed by combining __imp_ and the function or variable name. +
    + +
    dllexport:
    + +
    "dllexport" linkage causes the compiler to provide a global + pointer to a pointer in a DLL, so that it can be referenced with the + dllimport attribute. On Microsoft Windows targets, the pointer + name is formed by combining __imp_ and the function or variable + name. +
    + +
    + +

    For example, since the ".LC0" + variable is defined to be internal, if another module defined a ".LC0" + variable and was linked with this one, one of the two would be renamed, + preventing a collision. Since "main" and "puts" are + external (i.e., lacking any linkage declarations), they are accessible + outside of the current module.

    +

    It is illegal for a function declaration + to have any linkage type other than "externally visible", dllimport, + or extern_weak.

    +

    Aliases can have only external, internal and weak + linkages.

    +
    + + + + +
    + +

    LLVM functions, calls + and invokes can all have an optional calling convention + specified for the call. The calling convention of any pair of dynamic + caller/callee must match, or the behavior of the program is undefined. The + following calling conventions are supported by LLVM, and more may be added in + the future:

    + +
    +
    "ccc" - The C calling convention:
    + +
    This calling convention (the default if no other calling convention is + specified) matches the target C calling conventions. This calling convention + supports varargs function calls and tolerates some mismatch in the declared + prototype and implemented declaration of the function (as does normal C). +
    + +
    "fastcc" - The fast calling convention:
    + +
    This calling convention attempts to make calls as fast as possible + (e.g. by passing things in registers). This calling convention allows the + target to use whatever tricks it wants to produce fast code for the target, + without having to conform to an externally specified ABI (Application Binary + Interface). Implementations of this convention should allow arbitrary + tail call optimization to be + supported. This calling convention does not support varargs and requires the + prototype of all callees to exactly match the prototype of the function + definition. +
    + +
    "coldcc" - The cold calling convention:
    + +
    This calling convention attempts to make code in the caller as efficient + as possible under the assumption that the call is not commonly executed. As + such, these calls often preserve all registers so that the call does not break + any live ranges in the caller side. This calling convention does not support + varargs and requires the prototype of all callees to exactly match the + prototype of the function definition. +
    + +
    "cc <n>" - Numbered convention:
    + +
    Any calling convention may be specified by number, allowing + target-specific calling conventions to be used. Target specific calling + conventions start at 64. +
    +
    + +

    More calling conventions can be added/defined on an as-needed basis, to + support pascal conventions or any other well-known target-independent + convention.

    + +
    + + + + +
    + +

    + All Global Variables and Functions have one of the following visibility styles: +

    + +
    +
    "default" - Default style:
    + +
    On targets that use the ELF object file format, default visibility means + that the declaration is visible to other + modules and, in shared libraries, means that the declared entity may be + overridden. On Darwin, default visibility means that the declaration is + visible to other modules. Default visibility corresponds to "external + linkage" in the language. +
    + +
    "hidden" - Hidden style:
    + +
    Two declarations of an object with hidden visibility refer to the same + object if they are in the same shared object. Usually, hidden visibility + indicates that the symbol will not be placed into the dynamic symbol table, + so no other module (executable or shared library) can reference it + directly. +
    + +
    "protected" - Protected style:
    + +
    On ELF, protected visibility indicates that the symbol will be placed in + the dynamic symbol table, but that references within the defining module will + bind to the local symbol. That is, the symbol cannot be overridden by another + module. +
    +
    + +
    + + + + +
    + +

    LLVM IR allows you to specify name aliases for certain types. This can make + it easier to read the IR and make the IR more condensed (particularly when + recursive types are involved). An example of a name specification is: +

    + +
    +
    + %mytype = type { %mytype*, i32 }
    + 
    +
    + +

    You may give a name to any type except "void". Type name aliases may be used anywhere a type is + expected with the syntax "%mytype".

    + +

    Note that type names are aliases for the structural type that they indicate, + and that you can therefore specify multiple names for the same type. This often + leads to confusing behavior when dumping out a .ll file. Since LLVM IR uses + structural typing, the name is not part of the type. When printing out LLVM IR, + the printer will pick one name to render all types of a particular + shape. This means that if you have code where two different source types end up + having the same LLVM type, that the dumper will sometimes print the "wrong" or + unexpected type. This is an important design point and isn't going to + change.

    + +
    + + + + +
    + +

    Global variables define regions of memory allocated at compilation time + instead of run-time. Global variables may optionally be initialized, may have + an explicit section to be placed in, and may have an optional explicit alignment + specified. A variable may be defined as "thread_local", which means that it + will not be shared by threads (each thread will have a separated copy of the + variable). A variable may be defined as a global "constant," which indicates + that the contents of the variable will never be modified (enabling better + optimization, allowing the global data to be placed in the read-only section of + an executable, etc). Note that variables that need runtime initialization + cannot be marked "constant" as there is a store to the variable.

    + +

    + LLVM explicitly allows declarations of global variables to be marked + constant, even if the final definition of the global is not. This capability + can be used to enable slightly better optimization of the program, but requires + the language definition to guarantee that optimizations based on the + 'constantness' are valid for the translation units that do not include the + definition. +

    + +

    As SSA values, global variables define pointer values that are in + scope (i.e. they dominate) all basic blocks in the program. Global + variables always define a pointer to their "content" type because they + describe a region of memory, and all memory objects in LLVM are + accessed through pointers.

    + +

    A global variable may be declared to reside in a target-specifc numbered + address space. For targets that support them, address spaces may affect how + optimizations are performed and/or what target instructions are used to access + the variable. The default address space is zero. The address space qualifier + must precede any other attributes.

    + +

    LLVM allows an explicit section to be specified for globals. If the target + supports it, it will emit globals to the section specified.

    + +

    An explicit alignment may be specified for a global. If not present, or if + the alignment is set to zero, the alignment of the global is set by the target + to whatever it feels convenient. If an explicit alignment is specified, the + global is forced to have at least that much alignment. All alignments must be + a power of 2.

    + +

    For example, the following defines a global in a numbered address space with + an initializer, section, and alignment:

    + +
    +
    + @G = addrspace(5) constant float 1.0, section "foo", align 4
    + 
    +
    + +
    + + + +
    + Functions +
    + +
    + +

    LLVM function definitions consist of the "define" keyord, + an optional linkage type, an optional + visibility style, an optional + calling convention, a return type, an optional + parameter attribute for the return type, a function + name, a (possibly empty) argument list (each with optional + parameter attributes), optional + function attributes, an optional section, + an optional alignment, an optional garbage collector name, + an opening curly brace, a list of basic blocks, and a closing curly brace. + + LLVM function declarations consist of the "declare" keyword, an + optional linkage type, an optional + visibility style, an optional + calling convention, a return type, an optional + parameter attribute for the return type, a function + name, a possibly empty list of arguments, an optional alignment, and an optional + garbage collector name.

    + +

    A function definition contains a list of basic blocks, forming the CFG + (Control Flow Graph) for + the function. Each basic block may optionally start with a label (giving the + basic block a symbol table entry), contains a list of instructions, and ends + with a terminator instruction (such as a branch or + function return).

    + +

    The first basic block in a function is special in two ways: it is immediately + executed on entrance to the function, and it is not allowed to have predecessor + basic blocks (i.e. there can not be any branches to the entry block of a + function). Because the block can have no predecessors, it also cannot have any + PHI nodes.

    + +

    LLVM allows an explicit section to be specified for functions. If the target + supports it, it will emit functions to the section specified.

    + +

    An explicit alignment may be specified for a function. If not present, or if + the alignment is set to zero, the alignment of the function is set by the target + to whatever it feels convenient. If an explicit alignment is specified, the + function is forced to have at least that much alignment. All alignments must be + a power of 2.

    + +
    Syntax:
    + +
    + + define [linkage] [visibility] + [cconv] [ret attrs] + <ResultType> @<FunctionName> ([argument list]) + [fn Attrs] [section "name"] [align N] + [gc] { ... } + +
    + +
    + + + +
    + Aliases +
    +
    +

    Aliases act as "second name" for the aliasee value (which can be either + function, global variable, another alias or bitcast of global value). Aliases + may have an optional linkage type, and an + optional visibility style.

    + +
    Syntax:
    + +
    +
    + @<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
    + 
    +
    + +
    + + + + + +
    +

    The return type and each parameter of a function type may have a set of + parameter attributes associated with them. Parameter attributes are + used to communicate additional information about the result or parameters of + a function. Parameter attributes are considered to be part of the function, + not of the function type, so functions with different parameter attributes + can have the same function type.

    + +

    Parameter attributes are simple keywords that follow the type specified. If + multiple parameter attributes are needed, they are space separated. For + example:

    + +
    +
    + declare i32 @printf(i8* noalias , ...)
    + declare i32 @atoi(i8 zeroext)
    + declare signext i8 @returns_signed_char()
    + 
    +
    + +

    Note that any attributes for the function result (nounwind, + readonly) come immediately after the argument list.

    + +

    Currently, only the following parameter attributes are defined:

    +
    +
    zeroext
    +
    This indicates to the code generator that the parameter or return value + should be zero-extended to a 32-bit value by the caller (for a parameter) + or the callee (for a return value).
    + +
    signext
    +
    This indicates to the code generator that the parameter or return value + should be sign-extended to a 32-bit value by the caller (for a parameter) + or the callee (for a return value).
    + +
    inreg
    +
    This indicates that this parameter or return value should be treated + in a special target-dependent fashion during while emitting code for a + function call or return (usually, by putting it in a register as opposed + to memory, though some targets use it to distinguish between two different + kinds of registers). Use of this attribute is target-specific.
    + +
    byval
    +
    This indicates that the pointer parameter should really be passed by + value to the function. The attribute implies that a hidden copy of the + pointee is made between the caller and the callee, so the callee is unable + to modify the value in the callee. This attribute is only valid on LLVM + pointer arguments. It is generally used to pass structs and arrays by + value, but is also valid on pointers to scalars. The copy is considered to + belong to the caller not the callee (for example, + readonly functions should not write to + byval parameters). This is not a valid attribute for return + values.
    + +
    sret
    +
    This indicates that the pointer parameter specifies the address of a + structure that is the return value of the function in the source program. + This pointer must be guaranteed by the caller to be valid: loads and stores + to the structure may be assumed by the callee to not to trap. This may only + be applied to the first parameter. This is not a valid attribute for + return values.
    + +
    noalias
    +
    This indicates that the pointer does not alias any global or any other + parameter. The caller is responsible for ensuring that this is the + case. On a function return value, noalias additionally indicates + that the pointer does not alias any other pointers visible to the + caller. For further details, please see the discussion of the NoAlias + response in + alias + analysis.
    + +
    nocapture
    +
    This indicates that the callee does not make any copies of the pointer + that outlive the callee itself. This is not a valid attribute for return + values.
    + +
    nest
    +
    This indicates that the pointer parameter can be excised using the + trampoline intrinsics. This is not a valid + attribute for return values.
    +
    + +
    + + + + +
    +

    Each function may specify a garbage collector name, which is simply a + string.

    + +
    define void @f() gc "name" { ...
    + +

    The compiler declares the supported values of name. Specifying a + collector which will cause the compiler to alter its output in order to support + the named garbage collection algorithm.

    +
    + + + + +
    + +

    Function attributes are set to communicate additional information about + a function. Function attributes are considered to be part of the function, + not of the function type, so functions with different parameter attributes + can have the same function type.

    + +

    Function attributes are simple keywords that follow the type specified. If + multiple attributes are needed, they are space separated. For + example:

    + +
    +
    + define void @f() noinline { ... }
    + define void @f() alwaysinline { ... }
    + define void @f() alwaysinline optsize { ... }
    + define void @f() optsize
    + 
    +
    + +
    +
    alwaysinline
    +
    This attribute indicates that the inliner should attempt to inline this + function into callers whenever possible, ignoring any active inlining size + threshold for this caller.
    + +
    noinline
    +
    This attribute indicates that the inliner should never inline this function + in any situation. This attribute may not be used together with the + alwaysinline attribute.
    + +
    optsize
    +
    This attribute suggests that optimization passes and code generator passes + make choices that keep the code size of this function low, and otherwise do + optimizations specifically to reduce code size.
    + +
    noreturn
    +
    This function attribute indicates that the function never returns normally. + This produces undefined behavior at runtime if the function ever does + dynamically return.
    + +
    nounwind
    +
    This function attribute indicates that the function never returns with an + unwind or exceptional control flow. If the function does unwind, its runtime + behavior is undefined.
    + +
    readnone
    +
    This attribute indicates that the function computes its result (or the + exception it throws) based strictly on its arguments, without dereferencing any + pointer arguments or otherwise accessing any mutable state (e.g. memory, control + registers, etc) visible to caller functions. It does not write through any + pointer arguments (including byval arguments) and + never changes any state visible to callers.
    + +
    readonly
    +
    This attribute indicates that the function does not write through any + pointer arguments (including byval arguments) + or otherwise modify any state (e.g. memory, control registers, etc) visible to + caller functions. It may dereference pointer arguments and read state that may + be set in the caller. A readonly function always returns the same value (or + throws the same exception) when called with the same set of arguments and global + state.
    + +
    ssp
    +
    This attribute indicates that the function should emit a stack smashing + protector. It is in the form of a "canary"—a random value placed on the + stack before the local variables that's checked upon return from the function to + see if it has been overwritten. A heuristic is used to determine if a function + needs stack protectors or not. + +

    If a function that has an ssp attribute is inlined into a function + that doesn't have an ssp attribute, then the resulting function will + have an ssp attribute.

    + +
    sspreq
    +
    This attribute indicates that the function should always emit a + stack smashing protector. This overrides the ssp + function attribute. + +

    If a function that has an sspreq attribute is inlined into a + function that doesn't have an sspreq attribute or which has + an ssp attribute, then the resulting function will have + an sspreq attribute.

    +
    + +
    + + + + +
    +

    + Modules may contain "module-level inline asm" blocks, which corresponds to the + GCC "file scope inline asm" blocks. These blocks are internally concatenated by + LLVM and treated as a single unit, but may be separated in the .ll file if + desired. The syntax is very simple: +

    + +
    +
    + module asm "inline asm code goes here"
    + module asm "more can go here"
    + 
    +
    + +

    The strings can contain any character by escaping non-printable characters. + The escape sequence used is simply "\xx" where "xx" is the two digit hex code + for the number. +

    + +

    + The inline asm code is simply printed to the machine code .s file when + assembly code is generated. +

    +
    + + + + +
    +

    A module may specify a target specific data layout string that specifies how + data is to be laid out in memory. The syntax for the data layout is simply:

    +
        target datalayout = "layout specification"
    +

    The layout specification consists of a list of specifications + separated by the minus sign character ('-'). Each specification starts with a + letter and may include other information after the letter to define some + aspect of the data layout. The specifications accepted are as follows:

    +
    +
    E
    +
    Specifies that the target lays out data in big-endian form. That is, the + bits with the most significance have the lowest address location.
    +
    e
    +
    Specifies that the target lays out data in little-endian form. That is, + the bits with the least significance have the lowest address location.
    +
    p:size:abi:pref
    +
    This specifies the size of a pointer and its abi and + preferred alignments. All sizes are in bits. Specifying the pref + alignment is optional. If omitted, the preceding : should be omitted + too.
    +
    isize:abi:pref
    +
    This specifies the alignment for an integer type of a given bit + size. The value of size must be in the range [1,2^23).
    +
    vsize:abi:pref
    +
    This specifies the alignment for a vector type of a given bit + size.
    +
    fsize:abi:pref
    +
    This specifies the alignment for a floating point type of a given bit + size. The value of size must be either 32 (float) or 64 + (double).
    +
    asize:abi:pref
    +
    This specifies the alignment for an aggregate type of a given bit + size.
    +
    +

    When constructing the data layout for a given target, LLVM starts with a + default set of specifications which are then (possibly) overriden by the + specifications in the datalayout keyword. The default specifications + are given in this list:

    +
      +
    • E - big endian
    • +
    • p:32:64:64 - 32-bit pointers with 64-bit alignment
    • +
    • i1:8:8 - i1 is 8-bit (byte) aligned
    • +
    • i8:8:8 - i8 is 8-bit (byte) aligned
    • +
    • i16:16:16 - i16 is 16-bit aligned
    • +
    • i32:32:32 - i32 is 32-bit aligned
    • +
    • i64:32:64 - i64 has ABI alignment of 32-bits but preferred + alignment of 64-bits
    • +
    • f32:32:32 - float is 32-bit aligned
    • +
    • f64:64:64 - double is 64-bit aligned
    • +
    • v64:64:64 - 64-bit vector is 64-bit aligned
    • +
    • v128:128:128 - 128-bit vector is 128-bit aligned
    • +
    • a0:0:1 - aggregates are 8-bit aligned
    • +
    +

    When LLVM is determining the alignment for a given type, it uses the + following rules:

    +
      +
    1. If the type sought is an exact match for one of the specifications, that + specification is used.
    2. +
    3. If no match is found, and the type sought is an integer type, then the + smallest integer type that is larger than the bitwidth of the sought type is + used. If none of the specifications are larger than the bitwidth then the the + largest integer type is used. For example, given the default specifications + above, the i7 type will use the alignment of i8 (next largest) while both + i65 and i256 will use the alignment of i64 (largest specified).
    4. +
    5. If no match is found, and the type sought is a vector type, then the + largest vector type that is smaller than the sought vector type will be used + as a fall back. This happens because <128 x double> can be implemented + in terms of 64 <2 x double>, for example.
    6. +
    +
    + + + + + +
    + +

    The LLVM type system is one of the most important features of the + intermediate representation. Being typed enables a number of + optimizations to be performed on the intermediate representation directly, + without having to do + extra analyses on the side before the transformation. A strong type + system makes it easier to read the generated code and enables novel + analyses and transformations that are not feasible to perform on normal + three address code representations.

    + +
    + + + +
    +

    The types fall into a few useful + classifications:

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ClassificationTypes
    integeri1, i2, i3, ... i8, ... i16, ... i32, ... i64, ...
    floating pointfloat, double, x86_fp80, fp128, ppc_fp128
    first classinteger, + floating point, + pointer, + vector, + structure, + array, + label. +
    primitivelabel, + void, + floating point.
    derivedinteger, + array, + function, + pointer, + structure, + packed structure, + vector, + opaque. +
    + +

    The first class types are perhaps the + most important. Values of these types are the only ones which can be + produced by instructions, passed as arguments, or used as operands to + instructions.

    +
    + + + + +
    +

    The primitive types are the fundamental building blocks of the LLVM + system.

    + +
    + + + + +
    + + + + + + + + + +
    TypeDescription
    float32-bit floating point value
    double64-bit floating point value
    fp128128-bit floating point value (112-bit mantissa)
    x86_fp8080-bit floating point value (X87)
    ppc_fp128128-bit floating point value (two 64-bits)
    +
    + + + + +
    +
    Overview:
    +

    The void type does not represent any value and has no size.

    + +
    Syntax:
    + +
    +   void
    + 
    +
    + + + + +
    +
    Overview:
    +

    The label type represents code labels.

    + +
    Syntax:
    + +
    +   label
    + 
    +
    + + + + + +
    + +

    The real power in LLVM comes from the derived types in the system. + This is what allows a programmer to represent arrays, functions, + pointers, and other useful types. Note that these derived types may be + recursive: For example, it is possible to have a two dimensional array.

    + +
    + + + + +
    + +
    Overview:
    +

    The integer type is a very simple derived type that simply specifies an + arbitrary bit width for the integer type desired. Any bit width from 1 bit to + 2^23-1 (about 8 million) can be specified.

    + +
    Syntax:
    + +
    +   iN
    + 
    + +

    The number of bits the integer will occupy is specified by the N + value.

    + +
    Examples:
    + + + + + + + + + + + + + +
    i1a single-bit integer.
    i32a 32-bit integer.
    i1942652a really big integer of over 1 million bits.
    + +

    Note that the code generator does not yet support large integer types + to be used as function return types. The specific limit on how large a + return type the code generator can currently handle is target-dependent; + currently it's often 64 bits for 32-bit targets and 128 bits for 64-bit + targets.

    + +
    + + + + +
    + +
    Overview:
    + +

    The array type is a very simple derived type that arranges elements + sequentially in memory. The array type requires a size (number of + elements) and an underlying data type.

    + +
    Syntax:
    + +
    +   [<# elements> x <elementtype>]
    + 
    + +

    The number of elements is a constant integer value; elementtype may + be any type with a size.

    + +
    Examples:
    + + + + + + + + + + + + + +
    [40 x i32]Array of 40 32-bit integer values.
    [41 x i32]Array of 41 32-bit integer values.
    [4 x i8]Array of 4 8-bit integer values.
    +

    Here are some examples of multidimensional arrays:

    + + + + + + + + + + + + + +
    [3 x [4 x i32]]3x4 array of 32-bit integer values.
    [12 x [10 x float]]12x10 array of single precision floating point values.
    [2 x [3 x [4 x i16]]]2x3x4 array of 16-bit integer values.
    + +

    Note that 'variable sized arrays' can be implemented in LLVM with a zero + length array. Normally, accesses past the end of an array are undefined in + LLVM (e.g. it is illegal to access the 5th element of a 3 element array). + As a special case, however, zero length arrays are recognized to be variable + length. This allows implementation of 'pascal style arrays' with the LLVM + type "{ i32, [0 x float]}", for example.

    + +

    Note that the code generator does not yet support large aggregate types + to be used as function return types. The specific limit on how large an + aggregate return type the code generator can currently handle is + target-dependent, and also dependent on the aggregate element types.

    + +
    + + + +
    + +
    Overview:
    + +

    The function type can be thought of as a function signature. It + consists of a return type and a list of formal parameter types. The + return type of a function type is a scalar type, a void type, or a struct type. + If the return type is a struct type then all struct elements must be of first + class types, and the struct must have at least one element.

    + +
    Syntax:
    + +
    +   <returntype list> (<parameter list>)
    + 
    + +

    ...where '<parameter list>' is a comma-separated list of type + specifiers. Optionally, the parameter list may include a type ..., + which indicates that the function takes a variable number of arguments. + Variable argument functions can access their arguments with the variable argument handling intrinsic functions. + '<returntype list>' is a comma-separated list of + first class type specifiers.

    + +
    Examples:
    + + + + + + + + + + + + + + +
    i32 (i32)function taking an i32, returning an i32 +
    float (i16 signext, i32 *) * + Pointer to a function that takes + an i16 that should be sign extended and a + pointer to i32, returning + float. +
    i32 (i8*, ...)A vararg function that takes at least one + pointer to i8 (char in C), + which returns an integer. This is the signature for printf in + LLVM. +
    {i32, i32} (i32)A function taking an i32, returning two + i32 values as an aggregate of type { i32, i32 } +
    + +
    + + +
    +
    Overview:
    +

    The structure type is used to represent a collection of data members + together in memory. The packing of the field types is defined to match + the ABI of the underlying processor. The elements of a structure may + be any type that has a size.

    +

    Structures are accessed using 'load + and 'store' by getting a pointer to a + field with the 'getelementptr' + instruction.

    +
    Syntax:
    +
      { <type list> }
    +
    Examples:
    + + + + + + + + +
    { i32, i32, i32 }A triple of three i32 values
    { float, i32 (i32) * }A pair, where the first element is a float and the + second element is a pointer to a + function that takes an i32, returning + an i32.
    + +

    Note that the code generator does not yet support large aggregate types + to be used as function return types. The specific limit on how large an + aggregate return type the code generator can currently handle is + target-dependent, and also dependent on the aggregate element types.

    + +
    + + + +
    +
    Overview:
    +

    The packed structure type is used to represent a collection of data members + together in memory. There is no padding between fields. Further, the alignment + of a packed structure is 1 byte. The elements of a packed structure may + be any type that has a size.

    +

    Structures are accessed using 'load + and 'store' by getting a pointer to a + field with the 'getelementptr' + instruction.

    +
    Syntax:
    +
      < { <type list> } > 
    +
    Examples:
    + + + + + + + + +
    < { i32, i32, i32 } >A triple of three i32 values
    + < { float, i32 (i32)* } >A pair, where the first element is a float and the + second element is a pointer to a + function that takes an i32, returning + an i32.
    +
    + + + +
    +
    Overview:
    +

    As in many languages, the pointer type represents a pointer or + reference to another object, which must live in memory. Pointer types may have + an optional address space attribute defining the target-specific numbered + address space where the pointed-to object resides. The default address space is + zero.

    +
    Syntax:
    +
      <type> *
    +
    Examples:
    + + + + + + + + + + + + + +
    [4 x i32]*A pointer to array of four i32 values.
    i32 (i32 *) * A pointer to a function that takes an i32*, returning an + i32.
    i32 addrspace(5)*A pointer to an i32 value + that resides in address space #5.
    +
    + + + +
    + +
    Overview:
    + +

    A vector type is a simple derived type that represents a vector + of elements. Vector types are used when multiple primitive data + are operated in parallel using a single instruction (SIMD). + A vector type requires a size (number of + elements) and an underlying primitive data type. Vectors must have a power + of two length (1, 2, 4, 8, 16 ...). Vector types are + considered first class.

    + +
    Syntax:
    + +
    +   < <# elements> x <elementtype> >
    + 
    + +

    The number of elements is a constant integer value; elementtype may + be any integer or floating point type.

    + +
    Examples:
    + + + + + + + + + + + + + + +
    <4 x i32>Vector of 4 32-bit integer values.
    <8 x float>Vector of 8 32-bit floating-point values.
    <2 x i64>Vector of 2 64-bit integer values.
    + +

    Note that the code generator does not yet support large vector types + to be used as function return types. The specific limit on how large a + vector return type codegen can currently handle is target-dependent; + currently it's often a few times longer than a hardware vector register.

    + +
    + + + +
    + +
    Overview:
    + +

    Opaque types are used to represent unknown types in the system. This + corresponds (for example) to the C notion of a forward declared structure type. + In LLVM, opaque types can eventually be resolved to any type (not just a + structure type).

    + +
    Syntax:
    + +
    +   opaque
    + 
    + +
    Examples:
    + + + + + + +
    opaqueAn opaque type.
    +
    + + + + +
    +
    Overview:
    +

    + An "up reference" allows you to refer to a lexically enclosing type without + requiring it to have a name. For instance, a structure declaration may contain a + pointer to any of the types it is lexically a member of. Example of up + references (with their equivalent as named type declarations) include:

    + +
    +    { \2 * }                %x = type { %t* }
    +    { \2 }*                 %y = type { %y }*
    +    \1*                     %z = type %z*
    + 
    + +

    + An up reference is needed by the asmprinter for printing out cyclic types when + there is no declared name for a type in the cycle. Because the asmprinter does + not want to print out an infinite type string, it needs a syntax to handle + recursive types that have no names (all names are optional in llvm IR). +

    + +
    Syntax:
    +
    +    \<level>
    + 
    + +

    + The level is the count of the lexical type that is being referred to. +

    + +
    Examples:
    + + + + + + + + + + +
    \1*Self-referential pointer.
    { { \3*, i8 }, i32 }Recursive structure where the upref refers to the out-most + structure.
    +
    + + + + + + +
    + +

    LLVM has several different basic types of constants. This section describes + them all and their syntax.

    + +
    + + + + +
    + +
    +
    Boolean constants
    + +
    The two strings 'true' and 'false' are both valid + constants of the i1 type. +
    + +
    Integer constants
    + +
    Standard integers (such as '4') are constants of the integer type. Negative numbers may be used with + integer types. +
    + +
    Floating point constants
    + +
    Floating point constants use standard decimal notation (e.g. 123.421), + exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal + notation (see below). The assembler requires the exact decimal value of + a floating-point constant. For example, the assembler accepts 1.25 but + rejects 1.3 because 1.3 is a repeating decimal in binary. Floating point + constants must have a floating point type.
    + +
    Null pointer constants
    + +
    The identifier 'null' is recognized as a null pointer constant + and must be of pointer type.
    + +
    + +

    The one non-intuitive notation for constants is the optional hexadecimal form + of floating point constants. For example, the form 'double + 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double + 4.5e+15'. The only time hexadecimal floating point constants are required + (and the only time that they are generated by the disassembler) is when a + floating point constant must be emitted but it cannot be represented as a + decimal floating point number. For example, NaN's, infinities, and other + special values are represented in their IEEE hexadecimal format so that + assembly and disassembly do not cause any bits to change in the constants.

    + +
    + + + + +
    +

    Aggregate constants arise from aggregation of simple constants + and smaller aggregate constants.

    + +
    +
    Structure constants
    + +
    Structure constants are represented with notation similar to structure + type definitions (a comma separated list of elements, surrounded by braces + ({})). For example: "{ i32 4, float 17.0, i32* @G }", + where "@G" is declared as "@G = external global i32". Structure constants + must have structure type, and the number and + types of elements must match those specified by the type. +
    + +
    Array constants
    + +
    Array constants are represented with notation similar to array type + definitions (a comma separated list of elements, surrounded by square brackets + ([])). For example: "[ i32 42, i32 11, i32 74 ]". Array + constants must have array type, and the number and + types of elements must match those specified by the type. +
    + +
    Vector constants
    + +
    Vector constants are represented with notation similar to vector type + definitions (a comma separated list of elements, surrounded by + less-than/greater-than's (<>)). For example: "< i32 42, + i32 11, i32 74, i32 100 >". Vector constants must have vector type, and the number and types of elements must + match those specified by the type. +
    + +
    Zero initialization
    + +
    The string 'zeroinitializer' can be used to zero initialize a + value to zero of any type, including scalar and aggregate types. + This is often used to avoid having to print large zero initializers (e.g. for + large arrays) and is always exactly equivalent to using explicit zero + initializers. +
    +
    + +
    + + + + +
    + +

    The addresses of global variables and functions are always implicitly valid (link-time) + constants. These constants are explicitly referenced when the identifier for the global is used and always have pointer type. For example, the following is a legal LLVM + file:

    + +
    +
    + @X = global i32 17
    + @Y = global i32 42
    + @Z = global [2 x i32*] [ i32* @X, i32* @Y ]
    + 
    +
    + +
    + + + +
    +

    The string 'undef' is recognized as a type-less constant that has + no specific value. Undefined values may be of any type and be used anywhere + a constant is permitted.

    + +

    Undefined values indicate to the compiler that the program is well defined + no matter what value is used, giving the compiler more freedom to optimize. +

    +
    + + + + +
    + +

    Constant expressions are used to allow expressions involving other constants + to be used as constants. Constant expressions may be of any first class type and may involve any LLVM operation + that does not have side effects (e.g. load and call are not supported). The + following is the syntax for constant expressions:

    + +
    +
    trunc ( CST to TYPE )
    +
    Truncate a constant to another type. The bit size of CST must be larger + than the bit size of TYPE. Both types must be integers.
    + +
    zext ( CST to TYPE )
    +
    Zero extend a constant to another type. The bit size of CST must be + smaller or equal to the bit size of TYPE. Both types must be integers.
    + +
    sext ( CST to TYPE )
    +
    Sign extend a constant to another type. The bit size of CST must be + smaller or equal to the bit size of TYPE. Both types must be integers.
    + +
    fptrunc ( CST to TYPE )
    +
    Truncate a floating point constant to another floating point type. The + size of CST must be larger than the size of TYPE. Both types must be + floating point.
    + +
    fpext ( CST to TYPE )
    +
    Floating point extend a constant to another type. The size of CST must be + smaller or equal to the size of TYPE. Both types must be floating point.
    + +
    fptoui ( CST to TYPE )
    +
    Convert a floating point constant to the corresponding unsigned integer + constant. TYPE must be a scalar or vector integer type. CST must be of scalar + or vector floating point type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the integer type, + the results are undefined.
    + +
    fptosi ( CST to TYPE )
    +
    Convert a floating point constant to the corresponding signed integer + constant. TYPE must be a scalar or vector integer type. CST must be of scalar + or vector floating point type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the integer type, + the results are undefined.
    + +
    uitofp ( CST to TYPE )
    +
    Convert an unsigned integer constant to the corresponding floating point + constant. TYPE must be a scalar or vector floating point type. CST must be of + scalar or vector integer type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the floating point + type, the results are undefined.
    + +
    sitofp ( CST to TYPE )
    +
    Convert a signed integer constant to the corresponding floating point + constant. TYPE must be a scalar or vector floating point type. CST must be of + scalar or vector integer type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the floating point + type, the results are undefined.
    + +
    ptrtoint ( CST to TYPE )
    +
    Convert a pointer typed constant to the corresponding integer constant + TYPE must be an integer type. CST must be of pointer type. The CST value is + zero extended, truncated, or unchanged to make it fit in TYPE.
    + +
    inttoptr ( CST to TYPE )
    +
    Convert a integer constant to a pointer constant. TYPE must be a + pointer type. CST must be of integer type. The CST value is zero extended, + truncated, or unchanged to make it fit in a pointer size. This one is + really dangerous!
    + +
    bitcast ( CST to TYPE )
    +
    Convert a constant, CST, to another TYPE. The size of CST and TYPE must be + identical (same number of bits). The conversion is done as if the CST value + was stored to memory and read back as TYPE. In other words, no bits change + with this operator, just the type. This can be used for conversion of + vector types to any other type, as long as they have the same bit width. For + pointers it is only valid to cast to another pointer type. It is not valid + to bitcast to or from an aggregate type. +
    + +
    getelementptr ( CSTPTR, IDX0, IDX1, ... )
    + +
    Perform the getelementptr operation on + constants. As with the getelementptr + instruction, the index list may have zero or more indexes, which are required + to make sense for the type of "CSTPTR".
    + +
    select ( COND, VAL1, VAL2 )
    + +
    Perform the select operation on + constants.
    + +
    icmp COND ( VAL1, VAL2 )
    +
    Performs the icmp operation on constants.
    + +
    fcmp COND ( VAL1, VAL2 )
    +
    Performs the fcmp operation on constants.
    + +
    extractelement ( VAL, IDX )
    + +
    Perform the extractelement + operation on constants.
    + +
    insertelement ( VAL, ELT, IDX )
    + +
    Perform the insertelement + operation on constants.
    + + +
    shufflevector ( VEC1, VEC2, IDXMASK )
    + +
    Perform the shufflevector + operation on constants.
    + +
    OPCODE ( LHS, RHS )
    + +
    Perform the specified operation of the LHS and RHS constants. OPCODE may + be any of the binary or bitwise + binary operations. The constraints on operands are the same as those for + the corresponding instruction (e.g. no bitwise operations on floating point + values are allowed).
    +
    +
    + + + + + + + + +
    + +

    + LLVM supports inline assembler expressions (as opposed to + Module-Level Inline Assembly) through the use of a special value. This + value represents the inline assembler as a string (containing the instructions + to emit), a list of operand constraints (stored as a string), and a flag that + indicates whether or not the inline asm expression has side effects. An example + inline assembler expression is: +

    + +
    +
    + i32 (i32) asm "bswap $0", "=r,r"
    + 
    +
    + +

    + Inline assembler expressions may only be used as the callee operand of + a call instruction. Thus, typically we have: +

    + +
    +
    + %X = call i32 asm "bswap $0", "=r,r"(i32 %Y)
    + 
    +
    + +

    + Inline asms with side effects not visible in the constraint list must be marked + as having side effects. This is done through the use of the + 'sideeffect' keyword, like so: +

    + +
    +
    + call void asm sideeffect "eieio", ""()
    + 
    +
    + +

    TODO: The format of the asm and constraints string still need to be + documented here. Constraints on what can be done (e.g. duplication, moving, etc + need to be documented). This is probably best done by reference to another + document that covers inline asm from a holistic perspective. +

    + +
    + + + + + +
    + +

    The LLVM instruction set consists of several different + classifications of instructions: terminator + instructions, binary instructions, + bitwise binary instructions, memory instructions, and other + instructions.

    + +
    + + + + +
    + +

    As mentioned previously, every + basic block in a program ends with a "Terminator" instruction, which + indicates which block should be executed after the current block is + finished. These terminator instructions typically yield a 'void' + value: they produce control flow, not values (the one exception being + the 'invoke' instruction).

    +

    There are six different terminator instructions: the 'ret' instruction, the 'br' + instruction, the 'switch' instruction, + the 'invoke' instruction, the 'unwind' instruction, and the 'unreachable' instruction.

    + +
    + + + +
    +
    Syntax:
    +
    +   ret <type> <value>       ; Return a value from a non-void function
    +   ret void                 ; Return from void function
    + 
    + +
    Overview:
    + +

    The 'ret' instruction is used to return control flow (and + optionally a value) from a function back to the caller.

    +

    There are two forms of the 'ret' instruction: one that + returns a value and then causes control flow, and one that just causes + control flow to occur.

    + +
    Arguments:
    + +

    The 'ret' instruction optionally accepts a single argument, + the return value. The type of the return value must be a + 'first class' type.

    + +

    A function is not well formed if + it it has a non-void return type and contains a 'ret' + instruction with no return value or a return value with a type that + does not match its type, or if it has a void return type and contains + a 'ret' instruction with a return value.

    + +
    Semantics:
    + +

    When the 'ret' instruction is executed, control flow + returns back to the calling function's context. If the caller is a "call" instruction, execution continues at + the instruction after the call. If the caller was an "invoke" instruction, execution continues + at the beginning of the "normal" destination block. If the instruction + returns a value, that value shall set the call or invoke instruction's + return value.

    + +
    Example:
    + +
    +   ret i32 5                       ; Return an integer value of 5
    +   ret void                        ; Return from a void function
    +   ret { i32, i8 } { i32 4, i8 2 } ; Return an aggregate of values 4 and 2
    + 
    + +

    Note that the code generator does not yet fully support large + return values. The specific sizes that are currently supported are + dependent on the target. For integers, on 32-bit targets the limit + is often 64 bits, and on 64-bit targets the limit is often 128 bits. + For aggregate types, the current limits are dependent on the element + types; for example targets are often limited to 2 total integer + elements and 2 total floating-point elements.

    + +
    + + +
    +
    Syntax:
    +
      br i1 <cond>, label <iftrue>, label <iffalse>
    br label <dest> ; Unconditional branch +
    +
    Overview:
    +

    The 'br' instruction is used to cause control flow to + transfer to a different basic block in the current function. There are + two forms of this instruction, corresponding to a conditional branch + and an unconditional branch.

    +
    Arguments:
    +

    The conditional branch form of the 'br' instruction takes a + single 'i1' value and two 'label' values. The + unconditional form of the 'br' instruction takes a single + 'label' value as a target.

    +
    Semantics:
    +

    Upon execution of a conditional 'br' instruction, the 'i1' + argument is evaluated. If the value is true, control flows + to the 'iftrue' label argument. If "cond" is false, + control flows to the 'iffalse' label argument.

    +
    Example:
    +
    Test:
    %cond = icmp eq, i32 %a, %b
    br i1 %cond, label %IfEqual, label %IfUnequal
    IfEqual:
    ret i32 1
    IfUnequal:
    ret i32 0
    +
    + + + +
    +
    Syntax:
    + +
    +   switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
    + 
    + +
    Overview:
    + +

    The 'switch' instruction is used to transfer control flow to one of + several different places. It is a generalization of the 'br' + instruction, allowing a branch to occur to one of many possible + destinations.

    + + +
    Arguments:
    + +

    The 'switch' instruction uses three parameters: an integer + comparison value 'value', a default 'label' destination, and + an array of pairs of comparison value constants and 'label's. The + table is not allowed to contain duplicate constant entries.

    + +
    Semantics:
    + +

    The switch instruction specifies a table of values and + destinations. When the 'switch' instruction is executed, this + table is searched for the given value. If the value is found, control flow is + transfered to the corresponding destination; otherwise, control flow is + transfered to the default destination.

    + +
    Implementation:
    + +

    Depending on properties of the target machine and the particular + switch instruction, this instruction may be code generated in different + ways. For example, it could be generated as a series of chained conditional + branches or with a lookup table.

    + +
    Example:
    + +
    +  ; Emulate a conditional br instruction
    +  %Val = zext i1 %value to i32
    +  switch i32 %Val, label %truedest [ i32 0, label %falsedest ]
    + 
    +  ; Emulate an unconditional br instruction
    +  switch i32 0, label %dest [ ]
    + 
    +  ; Implement a jump table:
    +  switch i32 %val, label %otherwise [ i32 0, label %onzero
    +                                      i32 1, label %onone
    +                                      i32 2, label %ontwo ]
    + 
    +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = invoke [cconv] [ret attrs] <ptr to function ty> <function ptr val>(<function args>) [fn attrs]
    +                 to label <normal label> unwind label <exception label>
    + 
    + +
    Overview:
    + +

    The 'invoke' instruction causes control to transfer to a specified + function, with the possibility of control flow transfer to either the + 'normal' label or the + 'exception' label. If the callee function returns with the + "ret" instruction, control flow will return to the + "normal" label. If the callee (or any indirect callees) returns with the "unwind" instruction, control is interrupted and + continued at the dynamically nearest "exception" label.

    + +
    Arguments:
    + +

    This instruction requires several arguments:

    + +
      +
    1. + The optional "cconv" marker indicates which calling + convention the call should use. If none is specified, the call defaults + to using C calling conventions. +
    2. + +
    3. The optional Parameter Attributes list for + return values. Only 'zeroext', 'signext', + and 'inreg' attributes are valid here.
    4. + +
    5. 'ptr to function ty': shall be the signature of the pointer to + function value being invoked. In most cases, this is a direct function + invocation, but indirect invokes are just as possible, branching off + an arbitrary pointer to function value. +
    6. + +
    7. 'function ptr val': An LLVM value containing a pointer to a + function to be invoked.
    8. + +
    9. 'function args': argument list whose types match the function + signature argument types. If the function signature indicates the function + accepts a variable number of arguments, the extra arguments can be + specified.
    10. + +
    11. 'normal label': the label reached when the called function + executes a 'ret' instruction.
    12. + +
    13. 'exception label': the label reached when a callee returns with + the unwind instruction.
    14. + +
    15. The optional function attributes list. Only + 'noreturn', 'nounwind', 'readonly' and + 'readnone' attributes are valid here.
    16. +
    + +
    Semantics:
    + +

    This instruction is designed to operate as a standard 'call' instruction in most regards. The primary + difference is that it establishes an association with a label, which is used by + the runtime library to unwind the stack.

    + +

    This instruction is used in languages with destructors to ensure that proper + cleanup is performed in the case of either a longjmp or a thrown + exception. Additionally, this is important for implementation of + 'catch' clauses in high-level languages that support them.

    + +
    Example:
    +
    +   %retval = invoke i32 @Test(i32 15) to label %Continue
    +               unwind label %TestCleanup              ; {i32}:retval set
    +   %retval = invoke coldcc i32 %Testfnptr(i32 15) to label %Continue
    +               unwind label %TestCleanup              ; {i32}:retval set
    + 
    +
    + + + + + + +
    + +
    Syntax:
    +
    +   unwind
    + 
    + +
    Overview:
    + +

    The 'unwind' instruction unwinds the stack, continuing control flow + at the first callee in the dynamic call stack which used an invoke instruction to perform the call. This is + primarily used to implement exception handling.

    + +
    Semantics:
    + +

    The 'unwind' instruction causes execution of the current function to + immediately halt. The dynamic call stack is then searched for the first invoke instruction on the call stack. Once found, + execution continues at the "exceptional" destination block specified by the + invoke instruction. If there is no invoke instruction in the + dynamic call chain, undefined behavior results.

    +
    + + + + + +
    + +
    Syntax:
    +
    +   unreachable
    + 
    + +
    Overview:
    + +

    The 'unreachable' instruction has no defined semantics. This + instruction is used to inform the optimizer that a particular portion of the + code is not reachable. This can be used to indicate that the code after a + no-return function cannot be reached, and other facts.

    + +
    Semantics:
    + +

    The 'unreachable' instruction has no defined semantics.

    +
    + + + + + +
    +

    Binary operators are used to do most of the computation in a + program. They require two operands of the same type, execute an operation on them, and + produce a single value. The operands might represent + multiple data, as is the case with the vector data type. + The result value has the same type as its operands.

    +

    There are several different binary operators:

    +
    + + + +
    + +
    Syntax:
    + +
    +   <result> = add <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    + +

    The 'add' instruction returns the sum of its two operands.

    + +
    Arguments:
    + +

    The two arguments to the 'add' instruction must be integer, floating point, or + vector values. Both arguments must have identical + types.

    + +
    Semantics:
    + +

    The value produced is the integer or floating point sum of the two + operands.

    + +

    If an integer sum has unsigned overflow, the result returned is the + mathematical result modulo 2n, where n is the bit width of + the result.

    + +

    Because LLVM integers use a two's complement representation, this + instruction is appropriate for both signed and unsigned integers.

    + +
    Example:
    + +
    +   <result> = add i32 4, %var          ; yields {i32}:result = 4 + %var
    + 
    +
    + + + +
    + +
    Syntax:
    + +
    +   <result> = sub <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    + +

    The 'sub' instruction returns the difference of its two + operands.

    + +

    Note that the 'sub' instruction is used to represent the + 'neg' instruction present in most other intermediate + representations.

    + +
    Arguments:
    + +

    The two arguments to the 'sub' instruction must be integer, floating point, + or vector values. Both arguments must have identical + types.

    + +
    Semantics:
    + +

    The value produced is the integer or floating point difference of + the two operands.

    + +

    If an integer difference has unsigned overflow, the result returned is the + mathematical result modulo 2n, where n is the bit width of + the result.

    + +

    Because LLVM integers use a two's complement representation, this + instruction is appropriate for both signed and unsigned integers.

    + +
    Example:
    +
    +   <result> = sub i32 4, %var          ; yields {i32}:result = 4 - %var
    +   <result> = sub i32 0, %val          ; yields {i32}:result = -%var
    + 
    +
    + + + + +
    + +
    Syntax:
    +
      <result> = mul <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    +
    Overview:
    +

    The 'mul' instruction returns the product of its two + operands.

    + +
    Arguments:
    + +

    The two arguments to the 'mul' instruction must be integer, floating point, + or vector values. Both arguments must have identical + types.

    + +
    Semantics:
    + +

    The value produced is the integer or floating point product of the + two operands.

    + +

    If the result of an integer multiplication has unsigned overflow, + the result returned is the mathematical result modulo + 2n, where n is the bit width of the result.

    +

    Because LLVM integers use a two's complement representation, and the + result is the same width as the operands, this instruction returns the + correct result for both signed and unsigned integers. If a full product + (e.g. i32xi32->i64) is needed, the operands + should be sign-extended or zero-extended as appropriate to the + width of the full product.

    +
    Example:
    +
      <result> = mul i32 4, %var          ; yields {i32}:result = 4 * %var
    + 
    +
    + + + +
    +
    Syntax:
    +
      <result> = udiv <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    +
    Overview:
    +

    The 'udiv' instruction returns the quotient of its two + operands.

    + +
    Arguments:
    + +

    The two arguments to the 'udiv' instruction must be + integer or vector of integer + values. Both arguments must have identical types.

    + +
    Semantics:
    + +

    The value produced is the unsigned integer quotient of the two operands.

    +

    Note that unsigned integer division and signed integer division are distinct + operations; for signed integer division, use 'sdiv'.

    +

    Division by zero leads to undefined behavior.

    +
    Example:
    +
      <result> = udiv i32 4, %var          ; yields {i32}:result = 4 / %var
    + 
    +
    + + +
    +
    Syntax:
    +
    +   <result> = sdiv <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    + +

    The 'sdiv' instruction returns the quotient of its two + operands.

    + +
    Arguments:
    + +

    The two arguments to the 'sdiv' instruction must be + integer or vector of integer + values. Both arguments must have identical types.

    + +
    Semantics:
    +

    The value produced is the signed integer quotient of the two operands rounded towards zero.

    +

    Note that signed integer division and unsigned integer division are distinct + operations; for unsigned integer division, use 'udiv'.

    +

    Division by zero leads to undefined behavior. Overflow also leads to + undefined behavior; this is a rare case, but can occur, for example, + by doing a 32-bit division of -2147483648 by -1.

    +
    Example:
    +
      <result> = sdiv i32 4, %var          ; yields {i32}:result = 4 / %var
    + 
    +
    + + +
    +
    Syntax:
    +
    +   <result> = fdiv <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    +
    Overview:
    + +

    The 'fdiv' instruction returns the quotient of its two + operands.

    + +
    Arguments:
    + +

    The two arguments to the 'fdiv' instruction must be + floating point or vector + of floating point values. Both arguments must have identical types.

    + +
    Semantics:
    + +

    The value produced is the floating point quotient of the two operands.

    + +
    Example:
    + +
    +   <result> = fdiv float 4.0, %var          ; yields {float}:result = 4.0 / %var
    + 
    +
    + + + +
    +
    Syntax:
    +
      <result> = urem <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    +
    Overview:
    +

    The 'urem' instruction returns the remainder from the + unsigned division of its two arguments.

    +
    Arguments:
    +

    The two arguments to the 'urem' instruction must be + integer or vector of integer + values. Both arguments must have identical types.

    +
    Semantics:
    +

    This instruction returns the unsigned integer remainder of a division. + This instruction always performs an unsigned division to get the remainder.

    +

    Note that unsigned integer remainder and signed integer remainder are + distinct operations; for signed integer remainder, use 'srem'.

    +

    Taking the remainder of a division by zero leads to undefined behavior.

    +
    Example:
    +
      <result> = urem i32 4, %var          ; yields {i32}:result = 4 % %var
    + 
    + +
    + + + +
    + +
    Syntax:
    + +
    +   <result> = srem <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    + +

    The 'srem' instruction returns the remainder from the + signed division of its two operands. This instruction can also take + vector versions of the values in which case + the elements must be integers.

    + +
    Arguments:
    + +

    The two arguments to the 'srem' instruction must be + integer or vector of integer + values. Both arguments must have identical types.

    + +
    Semantics:
    + +

    This instruction returns the remainder of a division (where the result + has the same sign as the dividend, op1), not the modulo + operator (where the result has the same sign as the divisor, op2) of + a value. For more information about the difference, see The + Math Forum. For a table of how this is implemented in various languages, + please see + Wikipedia: modulo operation.

    +

    Note that signed integer remainder and unsigned integer remainder are + distinct operations; for unsigned integer remainder, use 'urem'.

    +

    Taking the remainder of a division by zero leads to undefined behavior. + Overflow also leads to undefined behavior; this is a rare case, but can occur, + for example, by taking the remainder of a 32-bit division of -2147483648 by -1. + (The remainder doesn't actually overflow, but this rule lets srem be + implemented using instructions that return both the result of the division + and the remainder.)

    +
    Example:
    +
      <result> = srem i32 4, %var          ; yields {i32}:result = 4 % %var
    + 
    + +
    + + + +
    + +
    Syntax:
    +
      <result> = frem <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    +
    Overview:
    +

    The 'frem' instruction returns the remainder from the + division of its two operands.

    +
    Arguments:
    +

    The two arguments to the 'frem' instruction must be + floating point or vector + of floating point values. Both arguments must have identical types.

    + +
    Semantics:
    + +

    This instruction returns the remainder of a division. + The remainder has the same sign as the dividend.

    + +
    Example:
    + +
    +   <result> = frem float 4.0, %var          ; yields {float}:result = 4.0 % %var
    + 
    +
    + + + +
    +

    Bitwise binary operators are used to do various forms of + bit-twiddling in a program. They are generally very efficient + instructions and can commonly be strength reduced from other + instructions. They require two operands of the same type, execute an operation on them, + and produce a single value. The resulting value is the same type as its operands.

    +
    + + + +
    +
    Syntax:
    +
      <result> = shl <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    + +

    The 'shl' instruction returns the first operand shifted to + the left a specified number of bits.

    + +
    Arguments:
    + +

    Both arguments to the 'shl' instruction must be the same integer or vector of integer + type. 'op2' is treated as an unsigned value.

    + +
    Semantics:
    + +

    The value produced is op1 * 2op2 mod 2n, + where n is the width of the result. If op2 is (statically or dynamically) negative or + equal to or larger than the number of bits in op1, the result is undefined. + If the arguments are vectors, each vector element of op1 is shifted by the + corresponding shift amount in op2.

    + +
    Example:
    +   <result> = shl i32 4, %var   ; yields {i32}: 4 << %var
    +   <result> = shl i32 4, 2      ; yields {i32}: 16
    +   <result> = shl i32 1, 10     ; yields {i32}: 1024
    +   <result> = shl i32 1, 32     ; undefined
    +   <result> = shl <2 x i32> < i32 1, i32 1>, < i32 1, i32 2>   ; yields: result=<2 x i32> < i32 2, i32 4>
    + 
    +
    + + +
    +
    Syntax:
    +
      <result> = lshr <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    +

    The 'lshr' instruction (logical shift right) returns the first + operand shifted to the right a specified number of bits with zero fill.

    + +
    Arguments:
    +

    Both arguments to the 'lshr' instruction must be the same + integer or vector of integer + type. 'op2' is treated as an unsigned value.

    + +
    Semantics:
    + +

    This instruction always performs a logical shift right operation. The most + significant bits of the result will be filled with zero bits after the + shift. If op2 is (statically or dynamically) equal to or larger than + the number of bits in op1, the result is undefined. If the arguments are + vectors, each vector element of op1 is shifted by the corresponding shift + amount in op2.

    + +
    Example:
    +
    +   <result> = lshr i32 4, 1   ; yields {i32}:result = 2
    +   <result> = lshr i32 4, 2   ; yields {i32}:result = 1
    +   <result> = lshr i8  4, 3   ; yields {i8}:result = 0
    +   <result> = lshr i8 -2, 1   ; yields {i8}:result = 0x7FFFFFFF 
    +   <result> = lshr i32 1, 32  ; undefined
    +   <result> = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2>   ; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1>
    + 
    +
    + + + +
    + +
    Syntax:
    +
      <result> = ashr <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    +

    The 'ashr' instruction (arithmetic shift right) returns the first + operand shifted to the right a specified number of bits with sign extension.

    + +
    Arguments:
    +

    Both arguments to the 'ashr' instruction must be the same + integer or vector of integer + type. 'op2' is treated as an unsigned value.

    + +
    Semantics:
    +

    This instruction always performs an arithmetic shift right operation, + The most significant bits of the result will be filled with the sign bit + of op1. If op2 is (statically or dynamically) equal to or + larger than the number of bits in op1, the result is undefined. If the + arguments are vectors, each vector element of op1 is shifted by the + corresponding shift amount in op2.

    + +
    Example:
    +
    +   <result> = ashr i32 4, 1   ; yields {i32}:result = 2
    +   <result> = ashr i32 4, 2   ; yields {i32}:result = 1
    +   <result> = ashr i8  4, 3   ; yields {i8}:result = 0
    +   <result> = ashr i8 -2, 1   ; yields {i8}:result = -1
    +   <result> = ashr i32 1, 32  ; undefined
    +   <result> = ashr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 3>   ; yields: result=<2 x i32> < i32 -1, i32 0>
    + 
    +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = and <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    + +
    Overview:
    + +

    The 'and' instruction returns the bitwise logical and of + its two operands.

    + +
    Arguments:
    + +

    The two arguments to the 'and' instruction must be + integer or vector of integer + values. Both arguments must have identical types.

    + +
    Semantics:
    +

    The truth table used for the 'and' instruction is:

    +

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    In0In1Out
    000
    010
    100
    111
    +
    +
    Example:
    +
    +   <result> = and i32 4, %var         ; yields {i32}:result = 4 & %var
    +   <result> = and i32 15, 40          ; yields {i32}:result = 8
    +   <result> = and i32 4, 8            ; yields {i32}:result = 0
    + 
    +
    + + +
    +
    Syntax:
    +
      <result> = or <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    +
    Overview:
    +

    The 'or' instruction returns the bitwise logical inclusive + or of its two operands.

    +
    Arguments:
    + +

    The two arguments to the 'or' instruction must be + integer or vector of integer + values. Both arguments must have identical types.

    +
    Semantics:
    +

    The truth table used for the 'or' instruction is:

    +

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    In0In1Out
    000
    011
    101
    111
    +
    +
    Example:
    +
      <result> = or i32 4, %var         ; yields {i32}:result = 4 | %var
    +   <result> = or i32 15, 40          ; yields {i32}:result = 47
    +   <result> = or i32 4, 8            ; yields {i32}:result = 12
    + 
    +
    + + +
    +
    Syntax:
    +
      <result> = xor <ty> <op1>, <op2>   ; yields {ty}:result
    + 
    +
    Overview:
    +

    The 'xor' instruction returns the bitwise logical exclusive + or of its two operands. The xor is used to implement the + "one's complement" operation, which is the "~" operator in C.

    +
    Arguments:
    +

    The two arguments to the 'xor' instruction must be + integer or vector of integer + values. Both arguments must have identical types.

    + +
    Semantics:
    + +

    The truth table used for the 'xor' instruction is:

    +

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    In0In1Out
    000
    011
    101
    110
    +
    +

    +
    Example:
    +
      <result> = xor i32 4, %var         ; yields {i32}:result = 4 ^ %var
    +   <result> = xor i32 15, 40          ; yields {i32}:result = 39
    +   <result> = xor i32 4, 8            ; yields {i32}:result = 12
    +   <result> = xor i32 %V, -1          ; yields {i32}:result = ~%V
    + 
    +
    + + + + +
    + +

    LLVM supports several instructions to represent vector operations in a + target-independent manner. These instructions cover the element-access and + vector-specific operations needed to process vectors effectively. While LLVM + does directly support these vector operations, many sophisticated algorithms + will want to use target-specific intrinsics to take full advantage of a specific + target.

    + +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = extractelement <n x <ty>> <val>, i32 <idx>    ; yields <ty>
    + 
    + +
    Overview:
    + +

    + The 'extractelement' instruction extracts a single scalar + element from a vector at a specified index. +

    + + +
    Arguments:
    + +

    + The first operand of an 'extractelement' instruction is a + value of vector type. The second operand is + an index indicating the position from which to extract the element. + The index may be a variable.

    + +
    Semantics:
    + +

    + The result is a scalar of the same type as the element type of + val. Its value is the value at position idx of + val. If idx exceeds the length of val, the + results are undefined. +

    + +
    Example:
    + +
    +   %result = extractelement <4 x i32> %vec, i32 0    ; yields i32
    + 
    +
    + + + + + +
    + +
    Syntax:
    + +
    +   <result> = insertelement <n x <ty>> <val>, <ty> <elt>, i32 <idx>    ; yields <n x <ty>>
    + 
    + +
    Overview:
    + +

    + The 'insertelement' instruction inserts a scalar + element into a vector at a specified index. +

    + + +
    Arguments:
    + +

    + The first operand of an 'insertelement' instruction is a + value of vector type. The second operand is a + scalar value whose type must equal the element type of the first + operand. The third operand is an index indicating the position at + which to insert the value. The index may be a variable.

    + +
    Semantics:
    + +

    + The result is a vector of the same type as val. Its + element values are those of val except at position + idx, where it gets the value elt. If idx + exceeds the length of val, the results are undefined. +

    + +
    Example:
    + +
    +   %result = insertelement <4 x i32> %vec, i32 1, i32 0    ; yields <4 x i32>
    + 
    +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask>    ; yields <m x <ty>>
    + 
    + +
    Overview:
    + +

    + The 'shufflevector' instruction constructs a permutation of elements + from two input vectors, returning a vector with the same element type as + the input and length that is the same as the shuffle mask. +

    + +
    Arguments:
    + +

    + The first two operands of a 'shufflevector' instruction are vectors + with types that match each other. The third argument is a shuffle mask whose + element type is always 'i32'. The result of the instruction is a vector whose + length is the same as the shuffle mask and whose element type is the same as + the element type of the first two operands. +

    + +

    + The shuffle mask operand is required to be a constant vector with either + constant integer or undef values. +

    + +
    Semantics:
    + +

    + The elements of the two input vectors are numbered from left to right across + both of the vectors. The shuffle mask operand specifies, for each element of + the result vector, which element of the two input vectors the result element + gets. The element selector may be undef (meaning "don't care") and the second + operand may be undef if performing a shuffle from only one vector. +

    + +
    Example:
    + +
    +   %result = shufflevector <4 x i32> %v1, <4 x i32> %v2, 
    +                           <4 x i32> <i32 0, i32 4, i32 1, i32 5>  ; yields <4 x i32>
    +   %result = shufflevector <4 x i32> %v1, <4 x i32> undef, 
    +                           <4 x i32> <i32 0, i32 1, i32 2, i32 3>  ; yields <4 x i32> - Identity shuffle.
    +   %result = shufflevector <8 x i32> %v1, <8 x i32> undef, 
    +                           <4 x i32> <i32 0, i32 1, i32 2, i32 3>  ; yields <4 x i32>
    +   %result = shufflevector <4 x i32> %v1, <4 x i32> %v2, 
    +                           <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 >  ; yields <8 x i32>
    + 
    +
    + + + + + +
    + +

    LLVM supports several instructions for working with aggregate values. +

    + +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}*
    + 
    + +
    Overview:
    + +

    + The 'extractvalue' instruction extracts the value of a struct field + or array element from an aggregate value. +

    + + +
    Arguments:
    + +

    + The first operand of an 'extractvalue' instruction is a + value of struct or array + type. The operands are constant indices to specify which value to extract + in a similar manner as indices in a + 'getelementptr' instruction. +

    + +
    Semantics:
    + +

    + The result is the value at the position in the aggregate specified by + the index operands. +

    + +
    Example:
    + +
    +   %result = extractvalue {i32, float} %agg, 0    ; yields i32
    + 
    +
    + + + + + +
    + +
    Syntax:
    + +
    +   <result> = insertvalue <aggregate type> <val>, <ty> <val>, <idx>    ; yields <n x <ty>>
    + 
    + +
    Overview:
    + +

    + The 'insertvalue' instruction inserts a value + into a struct field or array element in an aggregate. +

    + + +
    Arguments:
    + +

    + The first operand of an 'insertvalue' instruction is a + value of struct or array type. + The second operand is a first-class value to insert. + The following operands are constant indices + indicating the position at which to insert the value in a similar manner as + indices in a + 'getelementptr' instruction. + The value to insert must have the same type as the value identified + by the indices. +

    + +
    Semantics:
    + +

    + The result is an aggregate of the same type as val. Its + value is that of val except that the value at the position + specified by the indices is that of elt. +

    + +
    Example:
    + +
    +   %result = insertvalue {i32, float} %agg, i32 1, 0    ; yields {i32, float}
    + 
    +
    + + + + + +
    + +

    A key design point of an SSA-based representation is how it + represents memory. In LLVM, no memory locations are in SSA form, which + makes things very simple. This section describes how to read, write, + allocate, and free memory in LLVM.

    + +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = malloc <type>[, i32 <NumElements>][, align <alignment>]     ; yields {type*}:result
    + 
    + +
    Overview:
    + +

    The 'malloc' instruction allocates memory from the system + heap and returns a pointer to it. The object is always allocated in the generic + address space (address space zero).

    + +
    Arguments:
    + +

    The 'malloc' instruction allocates + sizeof(<type>)*NumElements + bytes of memory from the operating system and returns a pointer of the + appropriate type to the program. If "NumElements" is specified, it is the + number of elements allocated, otherwise "NumElements" is defaulted to be one. + If a constant alignment is specified, the value result of the allocation is guaranteed to + be aligned to at least that boundary. If not specified, or if zero, the target can + choose to align the allocation on any convenient boundary.

    + +

    'type' must be a sized type.

    + +
    Semantics:
    + +

    Memory is allocated using the system "malloc" function, and + a pointer is returned. The result of a zero byte allocation is undefined. The + result is null if there is insufficient memory available.

    + +
    Example:
    + +
    +   %array  = malloc [4 x i8]                     ; yields {[%4 x i8]*}:array
    + 
    +   %size   = add i32 2, 2                        ; yields {i32}:size = i32 4
    +   %array1 = malloc i8, i32 4                    ; yields {i8*}:array1
    +   %array2 = malloc [12 x i8], i32 %size         ; yields {[12 x i8]*}:array2
    +   %array3 = malloc i32, i32 4, align 1024       ; yields {i32*}:array3
    +   %array4 = malloc i32, align 1024              ; yields {i32*}:array4
    + 
    + +

    Note that the code generator does not yet respect the + alignment value.

    + +
    + + + + +
    + +
    Syntax:
    + +
    +   free <type> <value>                           ; yields {void}
    + 
    + +
    Overview:
    + +

    The 'free' instruction returns memory back to the unused + memory heap to be reallocated in the future.

    + +
    Arguments:
    + +

    'value' shall be a pointer value that points to a value + that was allocated with the 'malloc' + instruction.

    + +
    Semantics:
    + +

    Access to the memory pointed to by the pointer is no longer defined + after this instruction executes. If the pointer is null, the operation + is a noop.

    + +
    Example:
    + +
    +   %array  = malloc [4 x i8]                     ; yields {[4 x i8]*}:array
    +             free   [4 x i8]* %array
    + 
    +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = alloca <type>[, i32 <NumElements>][, align <alignment>]     ; yields {type*}:result
    + 
    + +
    Overview:
    + +

    The 'alloca' instruction allocates memory on the stack frame of the + currently executing function, to be automatically released when this function + returns to its caller. The object is always allocated in the generic address + space (address space zero).

    + +
    Arguments:
    + +

    The 'alloca' instruction allocates sizeof(<type>)*NumElements + bytes of memory on the runtime stack, returning a pointer of the + appropriate type to the program. If "NumElements" is specified, it is the + number of elements allocated, otherwise "NumElements" is defaulted to be one. + If a constant alignment is specified, the value result of the allocation is guaranteed + to be aligned to at least that boundary. If not specified, or if zero, the target + can choose to align the allocation on any convenient boundary.

    + +

    'type' may be any sized type.

    + +
    Semantics:
    + +

    Memory is allocated; a pointer is returned. The operation is undefiend if + there is insufficient stack space for the allocation. 'alloca'd + memory is automatically released when the function returns. The 'alloca' + instruction is commonly used to represent automatic variables that must + have an address available. When the function returns (either with the ret or unwind + instructions), the memory is reclaimed. Allocating zero bytes + is legal, but the result is undefined.

    + +
    Example:
    + +
    +   %ptr = alloca i32                             ; yields {i32*}:ptr
    +   %ptr = alloca i32, i32 4                      ; yields {i32*}:ptr
    +   %ptr = alloca i32, i32 4, align 1024          ; yields {i32*}:ptr
    +   %ptr = alloca i32, align 1024                 ; yields {i32*}:ptr
    + 
    +
    + + + +
    +
    Syntax:
    +
      <result> = load <ty>* <pointer>[, align <alignment>]
    <result> = volatile load <ty>* <pointer>[, align <alignment>]
    +
    Overview:
    +

    The 'load' instruction is used to read from memory.

    +
    Arguments:
    +

    The argument to the 'load' instruction specifies the memory + address from which to load. The pointer must point to a first class type. If the load is + marked as volatile, then the optimizer is not allowed to modify + the number or order of execution of this load with other + volatile load and store + instructions.

    +

    + The optional constant "align" argument specifies the alignment of the operation + (that is, the alignment of the memory address). A value of 0 or an + omitted "align" argument means that the operation has the preferential + alignment for the target. It is the responsibility of the code emitter + to ensure that the alignment information is correct. Overestimating + the alignment results in an undefined behavior. Underestimating the + alignment may produce less efficient code. An alignment of 1 is always + safe. +

    +
    Semantics:
    +

    The location of memory pointed to is loaded.

    +
    Examples:
    +
      %ptr = alloca i32                               ; yields {i32*}:ptr
    +   store i32 3, i32* %ptr                          ; yields {void}
    +   %val = load i32* %ptr                           ; yields {i32}:val = i32 3
    + 
    +
    + + +
    +
    Syntax:
    +
      store <ty> <value>, <ty>* <pointer>[, align <alignment>]                   ; yields {void}
    +   volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>]          ; yields {void}
    + 
    +
    Overview:
    +

    The 'store' instruction is used to write to memory.

    +
    Arguments:
    +

    There are two arguments to the 'store' instruction: a value + to store and an address at which to store it. The type of the '<pointer>' + operand must be a pointer to the first class type + of the '<value>' + operand. If the store is marked as volatile, then the + optimizer is not allowed to modify the number or order of execution of + this store with other volatile load and store instructions.

    +

    + The optional constant "align" argument specifies the alignment of the operation + (that is, the alignment of the memory address). A value of 0 or an + omitted "align" argument means that the operation has the preferential + alignment for the target. It is the responsibility of the code emitter + to ensure that the alignment information is correct. Overestimating + the alignment results in an undefined behavior. Underestimating the + alignment may produce less efficient code. An alignment of 1 is always + safe. +

    +
    Semantics:
    +

    The contents of memory are updated to contain '<value>' + at the location specified by the '<pointer>' operand.

    +
    Example:
    +
      %ptr = alloca i32                               ; yields {i32*}:ptr
    +   store i32 3, i32* %ptr                          ; yields {void}
    +   %val = load i32* %ptr                           ; yields {i32}:val = i32 3
    + 
    +
    + + + + +
    +
    Syntax:
    +
    +   <result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}*
    + 
    + +
    Overview:
    + +

    + The 'getelementptr' instruction is used to get the address of a + subelement of an aggregate data structure. It performs address calculation only + and does not access memory.

    + +
    Arguments:
    + +

    The first argument is always a pointer, and forms the basis of the + calculation. The remaining arguments are indices, that indicate which of the + elements of the aggregate object are indexed. The interpretation of each index + is dependent on the type being indexed into. The first index always indexes the + pointer value given as the first argument, the second index indexes a value of + the type pointed to (not necessarily the value directly pointed to, since the + first index can be non-zero), etc. The first type indexed into must be a pointer + value, subsequent types can be arrays, vectors and structs. Note that subsequent + types being indexed into can never be pointers, since that would require loading + the pointer before continuing calculation.

    + +

    The type of each index argument depends on the type it is indexing into. + When indexing into a (packed) structure, only i32 integer + constants are allowed. When indexing into an array, pointer or vector, + only integers of 32 or 64 bits are allowed (also non-constants). 32-bit values + will be sign extended to 64-bits if required.

    + +

    For example, let's consider a C code fragment and how it gets + compiled to LLVM:

    + +
    +
    + struct RT {
    +   char A;
    +   int B[10][20];
    +   char C;
    + };
    + struct ST {
    +   int X;
    +   double Y;
    +   struct RT Z;
    + };
    + 
    + int *foo(struct ST *s) {
    +   return &s[1].Z.B[5][13];
    + }
    + 
    +
    + +

    The LLVM code generated by the GCC frontend is:

    + +
    +
    + %RT = type { i8 , [10 x [20 x i32]], i8  }
    + %ST = type { i32, double, %RT }
    + 
    + define i32* %foo(%ST* %s) {
    + entry:
    +   %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
    +   ret i32* %reg
    + }
    + 
    +
    + +
    Semantics:
    + +

    In the example above, the first index is indexing into the '%ST*' + type, which is a pointer, yielding a '%ST' = '{ i32, double, %RT + }' type, a structure. The second index indexes into the third element of + the structure, yielding a '%RT' = '{ i8 , [10 x [20 x i32]], + i8 }' type, another structure. The third index indexes into the second + element of the structure, yielding a '[10 x [20 x i32]]' type, an + array. The two dimensions of the array are subscripted into, yielding an + 'i32' type. The 'getelementptr' instruction returns a pointer + to this element, thus computing a value of 'i32*' type.

    + +

    Note that it is perfectly legal to index partially through a + structure, returning a pointer to an inner element. Because of this, + the LLVM code for the given testcase is equivalent to:

    + +
    +   define i32* %foo(%ST* %s) {
    +     %t1 = getelementptr %ST* %s, i32 1                        ; yields %ST*:%t1
    +     %t2 = getelementptr %ST* %t1, i32 0, i32 2                ; yields %RT*:%t2
    +     %t3 = getelementptr %RT* %t2, i32 0, i32 1                ; yields [10 x [20 x i32]]*:%t3
    +     %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5  ; yields [20 x i32]*:%t4
    +     %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13        ; yields i32*:%t5
    +     ret i32* %t5
    +   }
    + 
    + +

    Note that it is undefined to access an array out of bounds: array and + pointer indexes must always be within the defined bounds of the array type. + The one exception for this rule is zero length arrays. These arrays are + defined to be accessible as variable length arrays, which requires access + beyond the zero'th element.

    + +

    The getelementptr instruction is often confusing. For some more insight + into how it works, see the getelementptr + FAQ.

    + +
    Example:
    + +
    +     ; yields [12 x i8]*:aptr
    +     %aptr = getelementptr {i32, [12 x i8]}* %saptr, i64 0, i32 1
    +     ; yields i8*:vptr
    +     %vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
    +     ; yields i8*:eptr
    +     %eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1
    + 
    +
    + + + +
    +

    The instructions in this category are the conversion instructions (casting) + which all take a single operand and a type. They perform various bit conversions + on the operand.

    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = trunc <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    + The 'trunc' instruction truncates its operand to the type ty2. +

    + +
    Arguments:
    +

    + The 'trunc' instruction takes a value to trunc, which must + be an integer type, and a type that specifies the size + and type of the result, which must be an integer + type. The bit size of value must be larger than the bit size of + ty2. Equal sized types are not allowed.

    + +
    Semantics:
    +

    + The 'trunc' instruction truncates the high order bits in value + and converts the remaining bits to ty2. Since the source size must be + larger than the destination size, trunc cannot be a no-op cast. + It will always truncate bits.

    + +
    Example:
    +
    +   %X = trunc i32 257 to i8              ; yields i8:1
    +   %Y = trunc i32 123 to i1              ; yields i1:true
    +   %Y = trunc i32 122 to i1              ; yields i1:false
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = zext <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'zext' instruction zero extends its operand to type + ty2.

    + + +
    Arguments:
    +

    The 'zext' instruction takes a value to cast, which must be of + integer type, and a type to cast it to, which must + also be of integer type. The bit size of the + value must be smaller than the bit size of the destination type, + ty2.

    + +
    Semantics:
    +

    The zext fills the high order bits of the value with zero + bits until it reaches the size of the destination type, ty2.

    + +

    When zero extending from i1, the result will always be either 0 or 1.

    + +
    Example:
    +
    +   %X = zext i32 257 to i64              ; yields i64:257
    +   %Y = zext i1 true to i32              ; yields i32:1
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = sext <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'sext' sign extends value to the type ty2.

    + +
    Arguments:
    +

    + The 'sext' instruction takes a value to cast, which must be of + integer type, and a type to cast it to, which must + also be of integer type. The bit size of the + value must be smaller than the bit size of the destination type, + ty2.

    + +
    Semantics:
    +

    + The 'sext' instruction performs a sign extension by copying the sign + bit (highest order bit) of the value until it reaches the bit size of + the type ty2.

    + +

    When sign extending from i1, the extension always results in -1 or 0.

    + +
    Example:
    +
    +   %X = sext i8  -1 to i16              ; yields i16   :65535
    +   %Y = sext i1 true to i32             ; yields i32:-1
    + 
    +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = fptrunc <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'fptrunc' instruction truncates value to type + ty2.

    + + +
    Arguments:
    +

    The 'fptrunc' instruction takes a floating + point value to cast and a floating point type to + cast it to. The size of value must be larger than the size of + ty2. This implies that fptrunc cannot be used to make a + no-op cast.

    + +
    Semantics:
    +

    The 'fptrunc' instruction truncates a value from a larger + floating point type to a smaller + floating point type. If the value cannot fit within + the destination type, ty2, then the results are undefined.

    + +
    Example:
    +
    +   %X = fptrunc double 123.0 to float         ; yields float:123.0
    +   %Y = fptrunc double 1.0E+300 to float      ; yields undefined
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = fpext <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'fpext' extends a floating point value to a larger + floating point value.

    + +
    Arguments:
    +

    The 'fpext' instruction takes a + floating point value to cast, + and a floating point type to cast it to. The source + type must be smaller than the destination type.

    + +
    Semantics:
    +

    The 'fpext' instruction extends the value from a smaller + floating point type to a larger + floating point type. The fpext cannot be + used to make a no-op cast because it always changes bits. Use + bitcast to make a no-op cast for a floating point cast.

    + +
    Example:
    +
    +   %X = fpext float 3.1415 to double        ; yields double:3.1415
    +   %Y = fpext float 1.0 to float            ; yields float:1.0 (no-op)
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = fptoui <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'fptoui' converts a floating point value to its + unsigned integer equivalent of type ty2. +

    + +
    Arguments:
    +

    The 'fptoui' instruction takes a value to cast, which must be a + scalar or vector floating point value, and a type + to cast it to ty2, which must be an integer + type. If ty is a vector floating point type, ty2 must be a + vector integer type with the same number of elements as ty

    + +
    Semantics:
    +

    The 'fptoui' instruction converts its + floating point operand into the nearest (rounding + towards zero) unsigned integer value. If the value cannot fit in ty2, + the results are undefined.

    + +
    Example:
    +
    +   %X = fptoui double 123.0 to i32      ; yields i32:123
    +   %Y = fptoui float 1.0E+300 to i1     ; yields undefined:1
    +   %X = fptoui float 1.04E+17 to i8     ; yields undefined:1
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = fptosi <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'fptosi' instruction converts + floating point value to type ty2. +

    + +
    Arguments:
    +

    The 'fptosi' instruction takes a value to cast, which must be a + scalar or vector floating point value, and a type + to cast it to ty2, which must be an integer + type. If ty is a vector floating point type, ty2 must be a + vector integer type with the same number of elements as ty

    + +
    Semantics:
    +

    The 'fptosi' instruction converts its + floating point operand into the nearest (rounding + towards zero) signed integer value. If the value cannot fit in ty2, + the results are undefined.

    + +
    Example:
    +
    +   %X = fptosi double -123.0 to i32      ; yields i32:-123
    +   %Y = fptosi float 1.0E-247 to i1      ; yields undefined:1
    +   %X = fptosi float 1.04E+17 to i8      ; yields undefined:1
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = uitofp <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'uitofp' instruction regards value as an unsigned + integer and converts that value to the ty2 type.

    + +
    Arguments:
    +

    The 'uitofp' instruction takes a value to cast, which must be a + scalar or vector integer value, and a type to cast it + to ty2, which must be an floating point + type. If ty is a vector integer type, ty2 must be a vector + floating point type with the same number of elements as ty

    + +
    Semantics:
    +

    The 'uitofp' instruction interprets its operand as an unsigned + integer quantity and converts it to the corresponding floating point value. If + the value cannot fit in the floating point value, the results are undefined.

    + +
    Example:
    +
    +   %X = uitofp i32 257 to float         ; yields float:257.0
    +   %Y = uitofp i8 -1 to double          ; yields double:255.0
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = sitofp <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'sitofp' instruction regards value as a signed + integer and converts that value to the ty2 type.

    + +
    Arguments:
    +

    The 'sitofp' instruction takes a value to cast, which must be a + scalar or vector integer value, and a type to cast it + to ty2, which must be an floating point + type. If ty is a vector integer type, ty2 must be a vector + floating point type with the same number of elements as ty

    + +
    Semantics:
    +

    The 'sitofp' instruction interprets its operand as a signed + integer quantity and converts it to the corresponding floating point value. If + the value cannot fit in the floating point value, the results are undefined.

    + +
    Example:
    +
    +   %X = sitofp i32 257 to float         ; yields float:257.0
    +   %Y = sitofp i8 -1 to double          ; yields double:-1.0
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = ptrtoint <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'ptrtoint' instruction converts the pointer value to + the integer type ty2.

    + +
    Arguments:
    +

    The 'ptrtoint' instruction takes a value to cast, which + must be a pointer value, and a type to cast it to + ty2, which must be an integer type.

    + +
    Semantics:
    +

    The 'ptrtoint' instruction converts value to integer type + ty2 by interpreting the pointer value as an integer and either + truncating or zero extending that value to the size of the integer type. If + value is smaller than ty2 then a zero extension is done. If + value is larger than ty2 then a truncation is done. If they + are the same size, then nothing is done (no-op cast) other than a type + change.

    + +
    Example:
    +
    +   %X = ptrtoint i32* %X to i8           ; yields truncation on 32-bit architecture
    +   %Y = ptrtoint i32* %x to i64          ; yields zero extension on 32-bit architecture
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = inttoptr <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    +

    The 'inttoptr' instruction converts an integer value to + a pointer type, ty2.

    + +
    Arguments:
    +

    The 'inttoptr' instruction takes an integer + value to cast, and a type to cast it to, which must be a + pointer type.

    + +
    Semantics:
    +

    The 'inttoptr' instruction converts value to type + ty2 by applying either a zero extension or a truncation depending on + the size of the integer value. If value is larger than the + size of a pointer then a truncation is done. If value is smaller than + the size of a pointer then a zero extension is done. If they are the same size, + nothing is done (no-op cast).

    + +
    Example:
    +
    +   %X = inttoptr i32 255 to i32*          ; yields zero extension on 64-bit architecture
    +   %X = inttoptr i32 255 to i32*          ; yields no-op on 32-bit architecture
    +   %Y = inttoptr i64 0 to i32*            ; yields truncation on 32-bit architecture
    + 
    +
    + + + +
    + +
    Syntax:
    +
    +   <result> = bitcast <ty> <value> to <ty2>             ; yields ty2
    + 
    + +
    Overview:
    + +

    The 'bitcast' instruction converts value to type + ty2 without changing any bits.

    + +
    Arguments:
    + +

    The 'bitcast' instruction takes a value to cast, which must be + a non-aggregate first class value, and a type to cast it to, which must also be + a non-aggregate first class type. The bit sizes of + value + and the destination type, ty2, must be identical. If the source + type is a pointer, the destination type must also be a pointer. This + instruction supports bitwise conversion of vectors to integers and to vectors + of other types (as long as they have the same size).

    + +
    Semantics:
    +

    The 'bitcast' instruction converts value to type + ty2. It is always a no-op cast because no bits change with + this conversion. The conversion is done as if the value had been + stored to memory and read back as type ty2. Pointer types may only be + converted to other pointer types with this instruction. To convert pointers to + other types, use the inttoptr or + ptrtoint instructions first.

    + +
    Example:
    +
    +   %X = bitcast i8 255 to i8              ; yields i8 :-1
    +   %Y = bitcast i32* %x to sint*          ; yields sint*:%x
    +   %Z = bitcast <2 x int> %V to i64;      ; yields i64: %V   
    + 
    +
    + + + +
    +

    The instructions in this category are the "miscellaneous" + instructions, which defy better classification.

    +
    + + + +
    +
    Syntax:
    +
      <result> = icmp <cond> <ty> <op1>, <op2>   ; yields {i1} or {<N x i1>}:result
    + 
    +
    Overview:
    +

    The 'icmp' instruction returns a boolean value or + a vector of boolean values based on comparison + of its two integer, integer vector, or pointer operands.

    +
    Arguments:
    +

    The 'icmp' instruction takes three operands. The first operand is + the condition code indicating the kind of comparison to perform. It is not + a value, just a keyword. The possible condition code are: +

    +
      +
    1. eq: equal
    2. +
    3. ne: not equal
    4. +
    5. ugt: unsigned greater than
    6. +
    7. uge: unsigned greater or equal
    8. +
    9. ult: unsigned less than
    10. +
    11. ule: unsigned less or equal
    12. +
    13. sgt: signed greater than
    14. +
    15. sge: signed greater or equal
    16. +
    17. slt: signed less than
    18. +
    19. sle: signed less or equal
    20. +
    +

    The remaining two arguments must be integer or + pointer + or integer vector typed. + They must also be identical types.

    +
    Semantics:
    +

    The 'icmp' compares op1 and op2 according to + the condition code given as cond. The comparison performed always + yields either an i1 or vector of i1 result, as follows: +

    +
      +
    1. eq: yields true if the operands are equal, + false otherwise. No sign interpretation is necessary or performed. +
    2. +
    3. ne: yields true if the operands are unequal, + false otherwise. No sign interpretation is necessary or performed.
    4. +
    5. ugt: interprets the operands as unsigned values and yields + true if op1 is greater than op2.
    6. +
    7. uge: interprets the operands as unsigned values and yields + true if op1 is greater than or equal to op2.
    8. +
    9. ult: interprets the operands as unsigned values and yields + true if op1 is less than op2.
    10. +
    11. ule: interprets the operands as unsigned values and yields + true if op1 is less than or equal to op2.
    12. +
    13. sgt: interprets the operands as signed values and yields + true if op1 is greater than op2.
    14. +
    15. sge: interprets the operands as signed values and yields + true if op1 is greater than or equal to op2.
    16. +
    17. slt: interprets the operands as signed values and yields + true if op1 is less than op2.
    18. +
    19. sle: interprets the operands as signed values and yields + true if op1 is less than or equal to op2.
    20. +
    +

    If the operands are pointer typed, the pointer + values are compared as if they were integers.

    +

    If the operands are integer vectors, then they are compared + element by element. The result is an i1 vector with + the same number of elements as the values being compared. + Otherwise, the result is an i1. +

    + +
    Example:
    +
      <result> = icmp eq i32 4, 5          ; yields: result=false
    +   <result> = icmp ne float* %X, %X     ; yields: result=false
    +   <result> = icmp ult i16  4, 5        ; yields: result=true
    +   <result> = icmp sgt i16  4, 5        ; yields: result=false
    +   <result> = icmp ule i16 -4, 5        ; yields: result=false
    +   <result> = icmp sge i16  4, 5        ; yields: result=false
    + 
    + +

    Note that the code generator does not yet support vector types with + the icmp instruction.

    + +
    + + + +
    +
    Syntax:
    +
      <result> = fcmp <cond> <ty> <op1>, <op2>     ; yields {i1} or {<N x i1>}:result
    + 
    +
    Overview:
    +

    The 'fcmp' instruction returns a boolean value + or vector of boolean values based on comparison + of its operands.

    +

    + If the operands are floating point scalars, then the result + type is a boolean (i1). +

    +

    If the operands are floating point vectors, then the result type + is a vector of boolean with the same number of elements as the + operands being compared.

    +
    Arguments:
    +

    The 'fcmp' instruction takes three operands. The first operand is + the condition code indicating the kind of comparison to perform. It is not + a value, just a keyword. The possible condition code are:

    +
      +
    1. false: no comparison, always returns false
    2. +
    3. oeq: ordered and equal
    4. +
    5. ogt: ordered and greater than
    6. +
    7. oge: ordered and greater than or equal
    8. +
    9. olt: ordered and less than
    10. +
    11. ole: ordered and less than or equal
    12. +
    13. one: ordered and not equal
    14. +
    15. ord: ordered (no nans)
    16. +
    17. ueq: unordered or equal
    18. +
    19. ugt: unordered or greater than
    20. +
    21. uge: unordered or greater than or equal
    22. +
    23. ult: unordered or less than
    24. +
    25. ule: unordered or less than or equal
    26. +
    27. une: unordered or not equal
    28. +
    29. uno: unordered (either nans)
    30. +
    31. true: no comparison, always returns true
    32. +
    +

    Ordered means that neither operand is a QNAN while + unordered means that either operand may be a QNAN.

    +

    Each of val1 and val2 arguments must be + either a floating point type + or a vector of floating point type. + They must have identical types.

    +
    Semantics:
    +

    The 'fcmp' instruction compares op1 and op2 + according to the condition code given as cond. + If the operands are vectors, then the vectors are compared + element by element. + Each comparison performed + always yields an i1 result, as follows:

    +
      +
    1. false: always yields false, regardless of operands.
    2. +
    3. oeq: yields true if both operands are not a QNAN and + op1 is equal to op2.
    4. +
    5. ogt: yields true if both operands are not a QNAN and + op1 is greather than op2.
    6. +
    7. oge: yields true if both operands are not a QNAN and + op1 is greater than or equal to op2.
    8. +
    9. olt: yields true if both operands are not a QNAN and + op1 is less than op2.
    10. +
    11. ole: yields true if both operands are not a QNAN and + op1 is less than or equal to op2.
    12. +
    13. one: yields true if both operands are not a QNAN and + op1 is not equal to op2.
    14. +
    15. ord: yields true if both operands are not a QNAN.
    16. +
    17. ueq: yields true if either operand is a QNAN or + op1 is equal to op2.
    18. +
    19. ugt: yields true if either operand is a QNAN or + op1 is greater than op2.
    20. +
    21. uge: yields true if either operand is a QNAN or + op1 is greater than or equal to op2.
    22. +
    23. ult: yields true if either operand is a QNAN or + op1 is less than op2.
    24. +
    25. ule: yields true if either operand is a QNAN or + op1 is less than or equal to op2.
    26. +
    27. une: yields true if either operand is a QNAN or + op1 is not equal to op2.
    28. +
    29. uno: yields true if either operand is a QNAN.
    30. +
    31. true: always yields true, regardless of operands.
    32. +
    + +
    Example:
    +
      <result> = fcmp oeq float 4.0, 5.0    ; yields: result=false
    +   <result> = fcmp one float 4.0, 5.0    ; yields: result=true
    +   <result> = fcmp olt float 4.0, 5.0    ; yields: result=true
    +   <result> = fcmp ueq double 1.0, 2.0   ; yields: result=false
    + 
    + +

    Note that the code generator does not yet support vector types with + the fcmp instruction.

    + +
    + + + + +
    + +
    Syntax:
    + +
      <result> = phi <ty> [ <val0>, <label0>], ...
    +
    Overview:
    +

    The 'phi' instruction is used to implement the φ node in + the SSA graph representing the function.

    +
    Arguments:
    + +

    The type of the incoming values is specified with the first type + field. After this, the 'phi' instruction takes a list of pairs + as arguments, with one pair for each predecessor basic block of the + current block. Only values of first class + type may be used as the value arguments to the PHI node. Only labels + may be used as the label arguments.

    + +

    There must be no non-phi instructions between the start of a basic + block and the PHI instructions: i.e. PHI instructions must be first in + a basic block.

    + +
    Semantics:
    + +

    At runtime, the 'phi' instruction logically takes on the value + specified by the pair corresponding to the predecessor basic block that executed + just prior to the current block.

    + +
    Example:
    +
    + Loop:       ; Infinite loop that counts from 0 on up...
    +   %indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
    +   %nextindvar = add i32 %indvar, 1
    +   br label %Loop
    + 
    +
    + + + + +
    + +
    Syntax:
    + +
    +   <result> = select selty <cond>, <ty> <val1>, <ty> <val2>             ; yields ty
    + 
    +   selty is either i1 or {<N x i1>}
    + 
    + +
    Overview:
    + +

    + The 'select' instruction is used to choose one value based on a + condition, without branching. +

    + + +
    Arguments:
    + +

    + The 'select' instruction requires an 'i1' value or + a vector of 'i1' values indicating the + condition, and two values of the same first class + type. If the val1/val2 are vectors and + the condition is a scalar, then entire vectors are selected, not + individual elements. +

    + +
    Semantics:
    + +

    + If the condition is an i1 and it evaluates to 1, the instruction returns the first + value argument; otherwise, it returns the second value argument. +

    +

    + If the condition is a vector of i1, then the value arguments must + be vectors of the same size, and the selection is done element + by element. +

    + +
    Example:
    + +
    +   %X = select i1 true, i8 17, i8 42          ; yields i8:17
    + 
    + +

    Note that the code generator does not yet support conditions + with vector type.

    + +
    + + + + + +
    + +
    Syntax:
    +
    +   <result> = [tail] call [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
    + 
    + +
    Overview:
    + +

    The 'call' instruction represents a simple function call.

    + +
    Arguments:
    + +

    This instruction requires several arguments:

    + +
      +
    1. +

      The optional "tail" marker indicates whether the callee function accesses + any allocas or varargs in the caller. If the "tail" marker is present, the + function call is eligible for tail call optimization. Note that calls may + be marked "tail" even if they do not occur before a ret instruction.

      +
    2. +
    3. +

      The optional "cconv" marker indicates which calling + convention the call should use. If none is specified, the call defaults + to using C calling conventions.

      +
    4. + +
    5. +

      The optional Parameter Attributes list for + return values. Only 'zeroext', 'signext', + and 'inreg' attributes are valid here.

      +
    6. + +
    7. +

      'ty': the type of the call instruction itself which is also + the type of the return value. Functions that return no value are marked + void.

      +
    8. +
    9. +

      'fnty': shall be the signature of the pointer to function + value being invoked. The argument types must match the types implied by + this signature. This type can be omitted if the function is not varargs + and if the function type does not return a pointer to a function.

      +
    10. +
    11. +

      'fnptrval': An LLVM value containing a pointer to a function to + be invoked. In most cases, this is a direct function invocation, but + indirect calls are just as possible, calling an arbitrary pointer + to function value.

      +
    12. +
    13. +

      'function args': argument list whose types match the + function signature argument types. All arguments must be of + first class type. If the function signature + indicates the function accepts a variable number of arguments, the extra + arguments can be specified.

      +
    14. +
    15. +

      The optional function attributes list. Only + 'noreturn', 'nounwind', 'readonly' and + 'readnone' attributes are valid here.

      +
    16. +
    + +
    Semantics:
    + +

    The 'call' instruction is used to cause control flow to + transfer to a specified function, with its incoming arguments bound to + the specified values. Upon a 'ret' + instruction in the called function, control flow continues with the + instruction after the function call, and the return value of the + function is bound to the result argument.

    + +
    Example:
    + +
    +   %retval = call i32 @test(i32 %argc)
    +   call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42)      ; yields i32
    +   %X = tail call i32 @foo()                                    ; yields i32
    +   %Y = tail call fastcc i32 @foo()  ; yields i32
    +   call void %foo(i8 97 signext)
    + 
    +   %struct.A = type { i32, i8 }
    +   %r = call %struct.A @foo()                        ; yields { 32, i8 }
    +   %gr = extractvalue %struct.A %r, 0                ; yields i32
    +   %gr1 = extractvalue %struct.A %r, 1               ; yields i8
    +   %Z = call void @foo() noreturn                    ; indicates that %foo never returns normally
    +   %ZZ = call zeroext i32 @bar()                     ; Return value is %zero extended
    + 
    + +
    + + + + +
    + +
    Syntax:
    + +
    +   <resultval> = va_arg <va_list*> <arglist>, <argty>
    + 
    + +
    Overview:
    + +

    The 'va_arg' instruction is used to access arguments passed through + the "variable argument" area of a function call. It is used to implement the + va_arg macro in C.

    + +
    Arguments:
    + +

    This instruction takes a va_list* value and the type of + the argument. It returns a value of the specified argument type and + increments the va_list to point to the next argument. The + actual type of va_list is target specific.

    + +
    Semantics:
    + +

    The 'va_arg' instruction loads an argument of the specified + type from the specified va_list and causes the + va_list to point to the next argument. For more information, + see the variable argument handling Intrinsic + Functions.

    + +

    It is legal for this instruction to be called in a function which does not + take a variable number of arguments, for example, the vfprintf + function.

    + +

    va_arg is an LLVM instruction instead of an intrinsic function because it takes a type as an + argument.

    + +
    Example:
    + +

    See the variable argument processing section.

    + +

    Note that the code generator does not yet fully support va_arg + on many targets. Also, it does not currently support va_arg with + aggregate types on any target.

    + +
    + + + + + +
    + +

    LLVM supports the notion of an "intrinsic function". These functions have + well known names and semantics and are required to follow certain restrictions. + Overall, these intrinsics represent an extension mechanism for the LLVM + language that does not require changing all of the transformations in LLVM when + adding to the language (or the bitcode reader/writer, the parser, etc...).

    + +

    Intrinsic function names must all start with an "llvm." prefix. This + prefix is reserved in LLVM for intrinsic names; thus, function names may not + begin with this prefix. Intrinsic functions must always be external functions: + you cannot define the body of intrinsic functions. Intrinsic functions may + only be used in call or invoke instructions: it is illegal to take the address + of an intrinsic function. Additionally, because intrinsic functions are part + of the LLVM language, it is required if any are added that they be documented + here.

    + +

    Some intrinsic functions can be overloaded, i.e., the intrinsic represents + a family of functions that perform the same operation but on different data + types. Because LLVM can represent over 8 million different integer types, + overloading is used commonly to allow an intrinsic function to operate on any + integer type. One or more of the argument types or the result type can be + overloaded to accept any integer type. Argument types may also be defined as + exactly matching a previous argument's type or the result type. This allows an + intrinsic function which accepts multiple arguments, but needs all of them to + be of the same type, to only be overloaded with respect to a single argument or + the result.

    + +

    Overloaded intrinsics will have the names of its overloaded argument types + encoded into its function name, each preceded by a period. Only those types + which are overloaded result in a name suffix. Arguments whose type is matched + against another type do not. For example, the llvm.ctpop function can + take an integer of any width and returns an integer of exactly the same integer + width. This leads to a family of functions such as + i8 @llvm.ctpop.i8(i8 %val) and i29 @llvm.ctpop.i29(i29 %val). + Only one type, the return type, is overloaded, and only one type suffix is + required. Because the argument's type is matched against the return type, it + does not require its own name suffix.

    + +

    To learn how to add an intrinsic function, please see the + Extending LLVM Guide. +

    + +
    + + + + +
    + +

    Variable argument support is defined in LLVM with the va_arg instruction and these three + intrinsic functions. These functions are related to the similarly + named macros defined in the <stdarg.h> header file.

    + +

    All of these functions operate on arguments that use a + target-specific value type "va_list". The LLVM assembly + language reference manual does not define what this type is, so all + transformations should be prepared to handle these functions regardless of + the type used.

    + +

    This example shows how the va_arg + instruction and the variable argument handling intrinsic functions are + used.

    + +
    +
    + define i32 @test(i32 %X, ...) {
    +   ; Initialize variable argument processing
    +   %ap = alloca i8*
    +   %ap2 = bitcast i8** %ap to i8*
    +   call void @llvm.va_start(i8* %ap2)
    + 
    +   ; Read a single integer argument
    +   %tmp = va_arg i8** %ap, i32
    + 
    +   ; Demonstrate usage of llvm.va_copy and llvm.va_end
    +   %aq = alloca i8*
    +   %aq2 = bitcast i8** %aq to i8*
    +   call void @llvm.va_copy(i8* %aq2, i8* %ap2)
    +   call void @llvm.va_end(i8* %aq2)
    + 
    +   ; Stop processing of arguments.
    +   call void @llvm.va_end(i8* %ap2)
    +   ret i32 %tmp
    + }
    + 
    + declare void @llvm.va_start(i8*)
    + declare void @llvm.va_copy(i8*, i8*)
    + declare void @llvm.va_end(i8*)
    + 
    +
    + +
    + + + + + +
    +
    Syntax:
    +
      declare void %llvm.va_start(i8* <arglist>)
    +
    Overview:
    +

    The 'llvm.va_start' intrinsic initializes + *<arglist> for subsequent use by va_arg.

    + +
    Arguments:
    + +

    The argument is a pointer to a va_list element to initialize.

    + +
    Semantics:
    + +

    The 'llvm.va_start' intrinsic works just like the va_start + macro available in C. In a target-dependent way, it initializes the + va_list element to which the argument points, so that the next call to + va_arg will produce the first variable argument passed to the function. + Unlike the C va_start macro, this intrinsic does not need to know the + last argument of the function as the compiler can figure that out.

    + +
    + + + + +
    +
    Syntax:
    +
      declare void @llvm.va_end(i8* <arglist>)
    +
    Overview:
    + +

    The 'llvm.va_end' intrinsic destroys *<arglist>, + which has been initialized previously with llvm.va_start + or llvm.va_copy.

    + +
    Arguments:
    + +

    The argument is a pointer to a va_list to destroy.

    + +
    Semantics:
    + +

    The 'llvm.va_end' intrinsic works just like the va_end + macro available in C. In a target-dependent way, it destroys the + va_list element to which the argument points. Calls to llvm.va_start and + llvm.va_copy must be matched exactly with calls to + llvm.va_end.

    + +
    + + + + +
    + +
    Syntax:
    + +
    +   declare void @llvm.va_copy(i8* <destarglist>, i8* <srcarglist>)
    + 
    + +
    Overview:
    + +

    The 'llvm.va_copy' intrinsic copies the current argument position + from the source argument list to the destination argument list.

    + +
    Arguments:
    + +

    The first argument is a pointer to a va_list element to initialize. + The second argument is a pointer to a va_list element to copy from.

    + + +
    Semantics:
    + +

    The 'llvm.va_copy' intrinsic works just like the va_copy + macro available in C. In a target-dependent way, it copies the source + va_list element into the destination va_list element. This + intrinsic is necessary because the + llvm.va_start intrinsic may be arbitrarily complex and require, for + example, memory allocation.

    + +
    + + + + +
    + +

    + LLVM support for Accurate Garbage + Collection (GC) requires the implementation and generation of these + intrinsics. + These intrinsics allow identification of GC roots on the + stack, as well as garbage collector implementations that require read and write barriers. + Front-ends for type-safe garbage collected languages should generate these + intrinsics to make use of the LLVM garbage collectors. For more details, see Accurate Garbage Collection with LLVM. +

    + +

    The garbage collection intrinsics only operate on objects in the generic + address space (address space zero).

    + +
    + + + + +
    + +
    Syntax:
    + +
    +   declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
    + 
    + +
    Overview:
    + +

    The 'llvm.gcroot' intrinsic declares the existence of a GC root to + the code generator, and allows some metadata to be associated with it.

    + +
    Arguments:
    + +

    The first argument specifies the address of a stack object that contains the + root pointer. The second pointer (which must be either a constant or a global + value address) contains the meta-data to be associated with the root.

    + +
    Semantics:
    + +

    At runtime, a call to this intrinsic stores a null pointer into the "ptrloc" + location. At compile-time, the code generator generates information to allow + the runtime to find the pointer at GC safe points. The 'llvm.gcroot' + intrinsic may only be used in a function which specifies a GC + algorithm.

    + +
    + + + + + +
    + +
    Syntax:
    + +
    +   declare i8* @llvm.gcread(i8* %ObjPtr, i8** %Ptr)
    + 
    + +
    Overview:
    + +

    The 'llvm.gcread' intrinsic identifies reads of references from heap + locations, allowing garbage collector implementations that require read + barriers.

    + +
    Arguments:
    + +

    The second argument is the address to read from, which should be an address + allocated from the garbage collector. The first object is a pointer to the + start of the referenced object, if needed by the language runtime (otherwise + null).

    + +
    Semantics:
    + +

    The 'llvm.gcread' intrinsic has the same semantics as a load + instruction, but may be replaced with substantially more complex code by the + garbage collector runtime, as needed. The 'llvm.gcread' intrinsic + may only be used in a function which specifies a GC + algorithm.

    + +
    + + + + + +
    + +
    Syntax:
    + +
    +   declare void @llvm.gcwrite(i8* %P1, i8* %Obj, i8** %P2)
    + 
    + +
    Overview:
    + +

    The 'llvm.gcwrite' intrinsic identifies writes of references to heap + locations, allowing garbage collector implementations that require write + barriers (such as generational or reference counting collectors).

    + +
    Arguments:
    + +

    The first argument is the reference to store, the second is the start of the + object to store it to, and the third is the address of the field of Obj to + store to. If the runtime does not require a pointer to the object, Obj may be + null.

    + +
    Semantics:
    + +

    The 'llvm.gcwrite' intrinsic has the same semantics as a store + instruction, but may be replaced with substantially more complex code by the + garbage collector runtime, as needed. The 'llvm.gcwrite' intrinsic + may only be used in a function which specifies a GC + algorithm.

    + +
    + + + + + + +
    +

    + These intrinsics are provided by LLVM to expose special features that may only + be implemented with code generator support. +

    + +
    + + + + +
    + +
    Syntax:
    +
    +   declare i8  *@llvm.returnaddress(i32 <level>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.returnaddress' intrinsic attempts to compute a + target-specific value indicating the return address of the current function + or one of its callers. +

    + +
    Arguments:
    + +

    + The argument to this intrinsic indicates which function to return the address + for. Zero indicates the calling function, one indicates its caller, etc. The + argument is required to be a constant integer value. +

    + +
    Semantics:
    + +

    + The 'llvm.returnaddress' intrinsic either returns a pointer indicating + the return address of the specified call frame, or zero if it cannot be + identified. The value returned by this intrinsic is likely to be incorrect or 0 + for arguments other than zero, so it should only be used for debugging purposes. +

    + +

    + Note that calling this intrinsic does not prevent function inlining or other + aggressive transformations, so the value returned may not be that of the obvious + source-language caller. +

    +
    + + + + + +
    + +
    Syntax:
    +
    +   declare i8 *@llvm.frameaddress(i32 <level>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.frameaddress' intrinsic attempts to return the + target-specific frame pointer value for the specified stack frame. +

    + +
    Arguments:
    + +

    + The argument to this intrinsic indicates which function to return the frame + pointer for. Zero indicates the calling function, one indicates its caller, + etc. The argument is required to be a constant integer value. +

    + +
    Semantics:
    + +

    + The 'llvm.frameaddress' intrinsic either returns a pointer indicating + the frame address of the specified call frame, or zero if it cannot be + identified. The value returned by this intrinsic is likely to be incorrect or 0 + for arguments other than zero, so it should only be used for debugging purposes. +

    + +

    + Note that calling this intrinsic does not prevent function inlining or other + aggressive transformations, so the value returned may not be that of the obvious + source-language caller. +

    +
    + + + + +
    + +
    Syntax:
    +
    +   declare i8 *@llvm.stacksave()
    + 
    + +
    Overview:
    + +

    + The 'llvm.stacksave' intrinsic is used to remember the current state of + the function stack, for use with + llvm.stackrestore. This is useful for implementing language + features like scoped automatic variable sized arrays in C99. +

    + +
    Semantics:
    + +

    + This intrinsic returns a opaque pointer value that can be passed to llvm.stackrestore. When an + llvm.stackrestore intrinsic is executed with a value saved from + llvm.stacksave, it effectively restores the state of the stack to the + state it was in when the llvm.stacksave intrinsic executed. In + practice, this pops any alloca blocks from the stack + that were allocated after the llvm.stacksave was executed. +

    + +
    + + + + +
    + +
    Syntax:
    +
    +   declare void @llvm.stackrestore(i8 * %ptr)
    + 
    + +
    Overview:
    + +

    + The 'llvm.stackrestore' intrinsic is used to restore the state of + the function stack to the state it was in when the corresponding llvm.stacksave intrinsic executed. This is + useful for implementing language features like scoped automatic variable sized + arrays in C99. +

    + +
    Semantics:
    + +

    + See the description for llvm.stacksave. +

    + +
    + + + + + +
    + +
    Syntax:
    +
    +   declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>)
    + 
    + +
    Overview:
    + + +

    + The 'llvm.prefetch' intrinsic is a hint to the code generator to insert + a prefetch instruction if supported; otherwise, it is a noop. Prefetches have + no + effect on the behavior of the program but can change its performance + characteristics. +

    + +
    Arguments:
    + +

    + address is the address to be prefetched, rw is the specifier + determining if the fetch should be for a read (0) or write (1), and + locality is a temporal locality specifier ranging from (0) - no + locality, to (3) - extremely local keep in cache. The rw and + locality arguments must be constant integers. +

    + +
    Semantics:
    + +

    + This intrinsic does not modify the behavior of the program. In particular, + prefetches cannot trap and do not produce a value. On targets that support this + intrinsic, the prefetch can provide hints to the processor cache for better + performance. +

    + +
    + + + + +
    + +
    Syntax:
    +
    +   declare void @llvm.pcmarker(i32 <id>)
    + 
    + +
    Overview:
    + + +

    + The 'llvm.pcmarker' intrinsic is a method to export a Program Counter + (PC) in a region of + code to simulators and other tools. The method is target specific, but it is + expected that the marker will use exported symbols to transmit the PC of the + marker. + The marker makes no guarantees that it will remain with any specific instruction + after optimizations. It is possible that the presence of a marker will inhibit + optimizations. The intended use is to be inserted after optimizations to allow + correlations of simulation runs. +

    + +
    Arguments:
    + +

    + id is a numerical id identifying the marker. +

    + +
    Semantics:
    + +

    + This intrinsic does not modify the behavior of the program. Backends that do not + support this intrinisic may ignore it. +

    + +
    + + + + +
    + +
    Syntax:
    +
    +   declare i64 @llvm.readcyclecounter( )
    + 
    + +
    Overview:
    + + +

    + The 'llvm.readcyclecounter' intrinsic provides access to the cycle + counter register (or similar low latency, high accuracy clocks) on those targets + that support it. On X86, it should map to RDTSC. On Alpha, it should map to RPCC. + As the backing counters overflow quickly (on the order of 9 seconds on alpha), this + should only be used for small timings. +

    + +
    Semantics:
    + +

    + When directly supported, reading the cycle counter should not modify any memory. + Implementations are allowed to either return a application specific value or a + system wide value. On backends without support, this is lowered to a constant 0. +

    + +
    + + + + +
    +

    + LLVM provides intrinsics for a few important standard C library functions. + These intrinsics allow source-language front-ends to pass information about the + alignment of the pointer arguments to the code generator, providing opportunity + for more efficient code generation. +

    + +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.memcpy on any integer bit + width. Not all targets support all bit widths however.

    +
    +   declare void @llvm.memcpy.i8(i8 * <dest>, i8 * <src>,
    +                                 i8 <len>, i32 <align>)
    +   declare void @llvm.memcpy.i16(i8 * <dest>, i8 * <src>,
    +                                 i16 <len>, i32 <align>)
    +   declare void @llvm.memcpy.i32(i8 * <dest>, i8 * <src>,
    +                                 i32 <len>, i32 <align>)
    +   declare void @llvm.memcpy.i64(i8 * <dest>, i8 * <src>,
    +                                 i64 <len>, i32 <align>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.memcpy.*' intrinsics copy a block of memory from the source + location to the destination location. +

    + +

    + Note that, unlike the standard libc function, the llvm.memcpy.* + intrinsics do not return a value, and takes an extra alignment argument. +

    + +
    Arguments:
    + +

    + The first argument is a pointer to the destination, the second is a pointer to + the source. The third argument is an integer argument + specifying the number of bytes to copy, and the fourth argument is the alignment + of the source and destination locations. +

    + +

    + If the call to this intrinisic has an alignment value that is not 0 or 1, then + the caller guarantees that both the source and destination pointers are aligned + to that boundary. +

    + +
    Semantics:
    + +

    + The 'llvm.memcpy.*' intrinsics copy a block of memory from the source + location to the destination location, which are not allowed to overlap. It + copies "len" bytes of memory over. If the argument is known to be aligned to + some boundary, this can be specified as the fourth argument, otherwise it should + be set to 0 or 1. +

    +
    + + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.memmove on any integer bit + width. Not all targets support all bit widths however.

    +
    +   declare void @llvm.memmove.i8(i8 * <dest>, i8 * <src>,
    +                                  i8 <len>, i32 <align>)
    +   declare void @llvm.memmove.i16(i8 * <dest>, i8 * <src>,
    +                                  i16 <len>, i32 <align>)
    +   declare void @llvm.memmove.i32(i8 * <dest>, i8 * <src>,
    +                                  i32 <len>, i32 <align>)
    +   declare void @llvm.memmove.i64(i8 * <dest>, i8 * <src>,
    +                                  i64 <len>, i32 <align>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.memmove.*' intrinsics move a block of memory from the source + location to the destination location. It is similar to the + 'llvm.memcpy' intrinsic but allows the two memory locations to overlap. +

    + +

    + Note that, unlike the standard libc function, the llvm.memmove.* + intrinsics do not return a value, and takes an extra alignment argument. +

    + +
    Arguments:
    + +

    + The first argument is a pointer to the destination, the second is a pointer to + the source. The third argument is an integer argument + specifying the number of bytes to copy, and the fourth argument is the alignment + of the source and destination locations. +

    + +

    + If the call to this intrinisic has an alignment value that is not 0 or 1, then + the caller guarantees that the source and destination pointers are aligned to + that boundary. +

    + +
    Semantics:
    + +

    + The 'llvm.memmove.*' intrinsics copy a block of memory from the source + location to the destination location, which may overlap. It + copies "len" bytes of memory over. If the argument is known to be aligned to + some boundary, this can be specified as the fourth argument, otherwise it should + be set to 0 or 1. +

    +
    + + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.memset on any integer bit + width. Not all targets support all bit widths however.

    +
    +   declare void @llvm.memset.i8(i8 * <dest>, i8 <val>,
    +                                 i8 <len>, i32 <align>)
    +   declare void @llvm.memset.i16(i8 * <dest>, i8 <val>,
    +                                 i16 <len>, i32 <align>)
    +   declare void @llvm.memset.i32(i8 * <dest>, i8 <val>,
    +                                 i32 <len>, i32 <align>)
    +   declare void @llvm.memset.i64(i8 * <dest>, i8 <val>,
    +                                 i64 <len>, i32 <align>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.memset.*' intrinsics fill a block of memory with a particular + byte value. +

    + +

    + Note that, unlike the standard libc function, the llvm.memset intrinsic + does not return a value, and takes an extra alignment argument. +

    + +
    Arguments:
    + +

    + The first argument is a pointer to the destination to fill, the second is the + byte value to fill it with, the third argument is an integer + argument specifying the number of bytes to fill, and the fourth argument is the + known alignment of destination location. +

    + +

    + If the call to this intrinisic has an alignment value that is not 0 or 1, then + the caller guarantees that the destination pointer is aligned to that boundary. +

    + +
    Semantics:
    + +

    + The 'llvm.memset.*' intrinsics fill "len" bytes of memory starting at + the + destination location. If the argument is known to be aligned to some boundary, + this can be specified as the fourth argument, otherwise it should be set to 0 or + 1. +

    +
    + + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.sqrt on any + floating point or vector of floating point type. Not all targets support all + types however.

    +
    +   declare float     @llvm.sqrt.f32(float %Val)
    +   declare double    @llvm.sqrt.f64(double %Val)
    +   declare x86_fp80  @llvm.sqrt.f80(x86_fp80 %Val)
    +   declare fp128     @llvm.sqrt.f128(fp128 %Val)
    +   declare ppc_fp128 @llvm.sqrt.ppcf128(ppc_fp128 %Val)
    + 
    + +
    Overview:
    + +

    + The 'llvm.sqrt' intrinsics return the sqrt of the specified operand, + returning the same value as the libm 'sqrt' functions would. Unlike + sqrt in libm, however, llvm.sqrt has undefined behavior for + negative numbers other than -0.0 (which allows for better optimization, because + there is no need to worry about errno being set). llvm.sqrt(-0.0) is + defined to return -0.0 like IEEE sqrt. +

    + +
    Arguments:
    + +

    + The argument and return value are floating point numbers of the same type. +

    + +
    Semantics:
    + +

    + This function returns the sqrt of the specified operand if it is a nonnegative + floating point number. +

    +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.powi on any + floating point or vector of floating point type. Not all targets support all + types however.

    +
    +   declare float     @llvm.powi.f32(float  %Val, i32 %power)
    +   declare double    @llvm.powi.f64(double %Val, i32 %power)
    +   declare x86_fp80  @llvm.powi.f80(x86_fp80  %Val, i32 %power)
    +   declare fp128     @llvm.powi.f128(fp128 %Val, i32 %power)
    +   declare ppc_fp128 @llvm.powi.ppcf128(ppc_fp128  %Val, i32 %power)
    + 
    + +
    Overview:
    + +

    + The 'llvm.powi.*' intrinsics return the first operand raised to the + specified (positive or negative) power. The order of evaluation of + multiplications is not defined. When a vector of floating point type is + used, the second argument remains a scalar integer value. +

    + +
    Arguments:
    + +

    + The second argument is an integer power, and the first is a value to raise to + that power. +

    + +
    Semantics:
    + +

    + This function returns the first value raised to the second power with an + unspecified sequence of rounding operations.

    +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.sin on any + floating point or vector of floating point type. Not all targets support all + types however.

    +
    +   declare float     @llvm.sin.f32(float  %Val)
    +   declare double    @llvm.sin.f64(double %Val)
    +   declare x86_fp80  @llvm.sin.f80(x86_fp80  %Val)
    +   declare fp128     @llvm.sin.f128(fp128 %Val)
    +   declare ppc_fp128 @llvm.sin.ppcf128(ppc_fp128  %Val)
    + 
    + +
    Overview:
    + +

    + The 'llvm.sin.*' intrinsics return the sine of the operand. +

    + +
    Arguments:
    + +

    + The argument and return value are floating point numbers of the same type. +

    + +
    Semantics:
    + +

    + This function returns the sine of the specified operand, returning the + same values as the libm sin functions would, and handles error + conditions in the same way.

    +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.cos on any + floating point or vector of floating point type. Not all targets support all + types however.

    +
    +   declare float     @llvm.cos.f32(float  %Val)
    +   declare double    @llvm.cos.f64(double %Val)
    +   declare x86_fp80  @llvm.cos.f80(x86_fp80  %Val)
    +   declare fp128     @llvm.cos.f128(fp128 %Val)
    +   declare ppc_fp128 @llvm.cos.ppcf128(ppc_fp128  %Val)
    + 
    + +
    Overview:
    + +

    + The 'llvm.cos.*' intrinsics return the cosine of the operand. +

    + +
    Arguments:
    + +

    + The argument and return value are floating point numbers of the same type. +

    + +
    Semantics:
    + +

    + This function returns the cosine of the specified operand, returning the + same values as the libm cos functions would, and handles error + conditions in the same way.

    +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.pow on any + floating point or vector of floating point type. Not all targets support all + types however.

    +
    +   declare float     @llvm.pow.f32(float  %Val, float %Power)
    +   declare double    @llvm.pow.f64(double %Val, double %Power)
    +   declare x86_fp80  @llvm.pow.f80(x86_fp80  %Val, x86_fp80 %Power)
    +   declare fp128     @llvm.pow.f128(fp128 %Val, fp128 %Power)
    +   declare ppc_fp128 @llvm.pow.ppcf128(ppc_fp128  %Val, ppc_fp128 Power)
    + 
    + +
    Overview:
    + +

    + The 'llvm.pow.*' intrinsics return the first operand raised to the + specified (positive or negative) power. +

    + +
    Arguments:
    + +

    + The second argument is a floating point power, and the first is a value to + raise to that power. +

    + +
    Semantics:
    + +

    + This function returns the first value raised to the second power, + returning the + same values as the libm pow functions would, and handles error + conditions in the same way.

    +
    + + + + + +
    +

    + LLVM provides intrinsics for a few important bit manipulation operations. + These allow efficient code generation for some algorithms. +

    + +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic function. You can use bswap on any integer + type that is an even number of bytes (i.e. BitWidth % 16 == 0).

    +
    +   declare i16 @llvm.bswap.i16(i16 <id>)
    +   declare i32 @llvm.bswap.i32(i32 <id>)
    +   declare i64 @llvm.bswap.i64(i64 <id>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.bswap' family of intrinsics is used to byte swap integer + values with an even number of bytes (positive multiple of 16 bits). These are + useful for performing operations on data that is not in the target's native + byte order. +

    + +
    Semantics:
    + +

    + The llvm.bswap.i16 intrinsic returns an i16 value that has the high + and low byte of the input i16 swapped. Similarly, the llvm.bswap.i32 + intrinsic returns an i32 value that has the four bytes of the input i32 + swapped, so that if the input bytes are numbered 0, 1, 2, 3 then the returned + i32 will have its bytes in 3, 2, 1, 0 order. The llvm.bswap.i48, + llvm.bswap.i64 and other intrinsics extend this concept to + additional even-byte lengths (6 bytes, 8 bytes and more, respectively). +

    + +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit + width. Not all targets support all bit widths however.

    +
    +   declare i8 @llvm.ctpop.i8 (i8  <src>)
    +   declare i16 @llvm.ctpop.i16(i16 <src>)
    +   declare i32 @llvm.ctpop.i32(i32 <src>)
    +   declare i64 @llvm.ctpop.i64(i64 <src>)
    +   declare i256 @llvm.ctpop.i256(i256 <src>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.ctpop' family of intrinsics counts the number of bits set in a + value. +

    + +
    Arguments:
    + +

    + The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type. +

    + +
    Semantics:
    + +

    + The 'llvm.ctpop' intrinsic counts the 1's in a variable. +

    +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.ctlz on any + integer bit width. Not all targets support all bit widths however.

    +
    +   declare i8 @llvm.ctlz.i8 (i8  <src>)
    +   declare i16 @llvm.ctlz.i16(i16 <src>)
    +   declare i32 @llvm.ctlz.i32(i32 <src>)
    +   declare i64 @llvm.ctlz.i64(i64 <src>)
    +   declare i256 @llvm.ctlz.i256(i256 <src>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.ctlz' family of intrinsic functions counts the number of + leading zeros in a variable. +

    + +
    Arguments:
    + +

    + The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type. +

    + +
    Semantics:
    + +

    + The 'llvm.ctlz' intrinsic counts the leading (most significant) zeros + in a variable. If the src == 0 then the result is the size in bits of the type + of src. For example, llvm.ctlz(i32 2) = 30. +

    +
    + + + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.cttz on any + integer bit width. Not all targets support all bit widths however.

    +
    +   declare i8 @llvm.cttz.i8 (i8  <src>)
    +   declare i16 @llvm.cttz.i16(i16 <src>)
    +   declare i32 @llvm.cttz.i32(i32 <src>)
    +   declare i64 @llvm.cttz.i64(i64 <src>)
    +   declare i256 @llvm.cttz.i256(i256 <src>)
    + 
    + +
    Overview:
    + +

    + The 'llvm.cttz' family of intrinsic functions counts the number of + trailing zeros. +

    + +
    Arguments:
    + +

    + The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type. +

    + +
    Semantics:
    + +

    + The 'llvm.cttz' intrinsic counts the trailing (least significant) zeros + in a variable. If the src == 0 then the result is the size in bits of the type + of src. For example, llvm.cttz(2) = 1. +

    +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.part.select + on any integer bit width.

    +
    +   declare i17 @llvm.part.select.i17 (i17 %val, i32 %loBit, i32 %hiBit)
    +   declare i29 @llvm.part.select.i29 (i29 %val, i32 %loBit, i32 %hiBit)
    + 
    + +
    Overview:
    +

    The 'llvm.part.select' family of intrinsic functions selects a + range of bits from an integer value and returns them in the same bit width as + the original value.

    + +
    Arguments:
    +

    The first argument, %val and the result may be integer types of + any bit width but they must have the same bit width. The second and third + arguments must be i32 type since they specify only a bit index.

    + +
    Semantics:
    +

    The operation of the 'llvm.part.select' intrinsic has two modes + of operation: forwards and reverse. If %loBit is greater than + %hiBits then the intrinsic operates in reverse mode. Otherwise it + operates in forward mode.

    +

    In forward mode, this intrinsic is the equivalent of shifting %val + right by %loBit bits and then ANDing it with a mask with + only the %hiBit - %loBit bits set, as follows:

    +
      +
    1. The %val is shifted right (LSHR) by the number of bits specified + by %loBits. This normalizes the value to the low order bits.
    2. +
    3. The %loBits value is subtracted from the %hiBits value + to determine the number of bits to retain.
    4. +
    5. A mask of the retained bits is created by shifting a -1 value.
    6. +
    7. The mask is ANDed with %val to produce the result.
    8. +
    +

    In reverse mode, a similar computation is made except that the bits are + returned in the reverse order. So, for example, if X has the value + i16 0x0ACF (101011001111) and we apply + part.select(i16 X, 8, 3) to it, we get back the value + i16 0x0026 (000000100110).

    +
    + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use llvm.part.set + on any integer bit width.

    +
    +   declare i17 @llvm.part.set.i17.i9 (i17 %val, i9 %repl, i32 %lo, i32 %hi)
    +   declare i29 @llvm.part.set.i29.i9 (i29 %val, i9 %repl, i32 %lo, i32 %hi)
    + 
    + +
    Overview:
    +

    The 'llvm.part.set' family of intrinsic functions replaces a range + of bits in an integer value with another integer value. It returns the integer + with the replaced bits.

    + +
    Arguments:
    +

    The first argument, %val and the result may be integer types of + any bit width but they must have the same bit width. %val is the value + whose bits will be replaced. The second argument, %repl may be an + integer of any bit width. The third and fourth arguments must be i32 + type since they specify only a bit index.

    + +
    Semantics:
    +

    The operation of the 'llvm.part.set' intrinsic has two modes + of operation: forwards and reverse. If %lo is greater than + %hi then the intrinsic operates in reverse mode. Otherwise it + operates in forward mode.

    +

    For both modes, the %repl value is prepared for use by either + truncating it down to the size of the replacement area or zero extending it + up to that size.

    +

    In forward mode, the bits between %lo and %hi (inclusive) + are replaced with corresponding bits from %repl. That is the 0th bit + in %repl replaces the %loth bit in %val and etc. up + to the %hith bit.

    +

    In reverse mode, a similar computation is made except that the bits are + reversed. That is, the 0th bit in %repl replaces the + %hi bit in %val and etc. down to the %loth bit.

    +
    Examples:
    +
    +   llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
    +   llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
    +   llvm.part.set(0xFFFF, 1, 7, 4) -> 0xFF8F
    +   llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
    +   llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
    + 
    +
    + + + + +
    +

    + The LLVM debugger intrinsics (which all start with llvm.dbg. prefix), + are described in the LLVM Source Level + Debugging document. +

    +
    + + + + + +
    +

    The LLVM exception handling intrinsics (which all start with + llvm.eh. prefix), are described in the LLVM Exception + Handling document.

    +
    + + + + +
    +

    + This intrinsic makes it possible to excise one parameter, marked with + the nest attribute, from a function. The result is a callable + function pointer lacking the nest parameter - the caller does not need + to provide a value for it. Instead, the value to use is stored in + advance in a "trampoline", a block of memory usually allocated + on the stack, which also contains code to splice the nest value into the + argument list. This is used to implement the GCC nested function address + extension. +

    +

    + For example, if the function is + i32 f(i8* nest %c, i32 %x, i32 %y) then the resulting function + pointer has signature i32 (i32, i32)*. It can be created as follows:

    +
    +   %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
    +   %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
    +   %p = call i8* @llvm.init.trampoline( i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval )
    +   %fp = bitcast i8* %p to i32 (i32, i32)*
    + 
    +

    The call %val = call i32 %fp( i32 %x, i32 %y ) is then equivalent + to %val = call i32 %f( i8* %nval, i32 %x, i32 %y ).

    +
    + + + +
    +
    Syntax:
    +
    + declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>)
    + 
    +
    Overview:
    +

    + This fills the memory pointed to by tramp with code + and returns a function pointer suitable for executing it. +

    +
    Arguments:
    +

    + The llvm.init.trampoline intrinsic takes three arguments, all + pointers. The tramp argument must point to a sufficiently large + and sufficiently aligned block of memory; this memory is written to by the + intrinsic. Note that the size and the alignment are target-specific - LLVM + currently provides no portable way of determining them, so a front-end that + generates this intrinsic needs to have some target-specific knowledge. + The func argument must hold a function bitcast to an i8*. +

    +
    Semantics:
    +

    + The block of memory pointed to by tramp is filled with target + dependent code, turning it into a function. A pointer to this function is + returned, but needs to be bitcast to an + appropriate function pointer type + before being called. The new function's signature is the same as that of + func with any arguments marked with the nest attribute + removed. At most one such nest argument is allowed, and it must be + of pointer type. Calling the new function is equivalent to calling + func with the same argument list, but with nval used for the + missing nest argument. If, after calling + llvm.init.trampoline, the memory pointed to by tramp is + modified, then the effect of any later call to the returned function pointer is + undefined. +

    +
    + + + + +
    +

    + These intrinsic functions expand the "universal IR" of LLVM to represent + hardware constructs for atomic operations and memory synchronization. This + provides an interface to the hardware, not an interface to the programmer. It + is aimed at a low enough level to allow any programming models or APIs + (Application Programming Interfaces) which + need atomic behaviors to map cleanly onto it. It is also modeled primarily on + hardware behavior. Just as hardware provides a "universal IR" for source + languages, it also provides a starting point for developing a "universal" + atomic operation and synchronization IR. +

    +

    + These do not form an API such as high-level threading libraries, + software transaction memory systems, atomic primitives, and intrinsic + functions as found in BSD, GNU libc, atomic_ops, APR, and other system and + application libraries. The hardware interface provided by LLVM should allow + a clean implementation of all of these APIs and parallel programming models. + No one model or paradigm should be selected above others unless the hardware + itself ubiquitously does so. + +

    +
    + + + +
    +
    Syntax:
    +
    + declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, 
    + i1 <device> )
    + 
    + 
    +
    Overview:
    +

    + The llvm.memory.barrier intrinsic guarantees ordering between + specific pairs of memory access types. +

    +
    Arguments:
    +

    + The llvm.memory.barrier intrinsic requires five boolean arguments. + The first four arguments enables a specific barrier as listed below. The fith + argument specifies that the barrier applies to io or device or uncached memory. + +

    +
      +
    • ll: load-load barrier
    • +
    • ls: load-store barrier
    • +
    • sl: store-load barrier
    • +
    • ss: store-store barrier
    • +
    • device: barrier applies to device and uncached memory also.
    • +
    +
    Semantics:
    +

    + This intrinsic causes the system to enforce some ordering constraints upon + the loads and stores of the program. This barrier does not indicate + when any events will occur, it only enforces an order in + which they occur. For any of the specified pairs of load and store operations + (f.ex. load-load, or store-load), all of the first operations preceding the + barrier will complete before any of the second operations succeeding the + barrier begin. Specifically the semantics for each pairing is as follows: +

    +
      +
    • ll: All loads before the barrier must complete before any load + after the barrier begins.
    • + +
    • ls: All loads before the barrier must complete before any + store after the barrier begins.
    • +
    • ss: All stores before the barrier must complete before any + store after the barrier begins.
    • +
    • sl: All stores before the barrier must complete before any + load after the barrier begins.
    • +
    +

    + These semantics are applied with a logical "and" behavior when more than one + is enabled in a single memory barrier intrinsic. +

    +

    + Backends may implement stronger barriers than those requested when they do not + support as fine grained a barrier as requested. Some architectures do not + need all types of barriers and on such architectures, these become noops. +

    +
    Example:
    +
    + %ptr      = malloc i32
    +             store i32 4, %ptr
    + 
    + %result1  = load i32* %ptr      ; yields {i32}:result1 = 4
    +             call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
    +                                 ; guarantee the above finishes
    +             store i32 8, %ptr   ; before this begins
    + 
    +
    + + + +
    +
    Syntax:
    +

    + This is an overloaded intrinsic. You can use llvm.atomic.cmp.swap on + any integer bit width and for different address spaces. Not all targets + support all bit widths however.

    + +
    + declare i8 @llvm.atomic.cmp.swap.i8.p0i8( i8* <ptr>, i8 <cmp>, i8 <val> )
    + declare i16 @llvm.atomic.cmp.swap.i16.p0i16( i16* <ptr>, i16 <cmp>, i16 <val> )
    + declare i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* <ptr>, i32 <cmp>, i32 <val> )
    + declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>, i64 <val> )
    + 
    + 
    +
    Overview:
    +

    + This loads a value in memory and compares it to a given value. If they are + equal, it stores a new value into the memory. +

    +
    Arguments:
    +

    + The llvm.atomic.cmp.swap intrinsic takes three arguments. The result as + well as both cmp and val must be integer values with the + same bit width. The ptr argument must be a pointer to a value of + this integer type. While any bit width integer may be used, targets may only + lower representations they support in hardware. + +

    +
    Semantics:
    +

    + This entire intrinsic must be executed atomically. It first loads the value + in memory pointed to by ptr and compares it with the value + cmp. If they are equal, val is stored into the memory. The + loaded value is yielded in all cases. This provides the equivalent of an + atomic compare-and-swap operation within the SSA framework. +

    +
    Examples:
    + +
    + %ptr      = malloc i32
    +             store i32 4, %ptr
    + 
    + %val1     = add i32 4, 4
    + %result1  = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 4, %val1 )
    +                                           ; yields {i32}:result1 = 4
    + %stored1  = icmp eq i32 %result1, 4       ; yields {i1}:stored1 = true
    + %memval1  = load i32* %ptr                ; yields {i32}:memval1 = 8
    + 
    + %val2     = add i32 1, 1
    + %result2  = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 5, %val2 )
    +                                           ; yields {i32}:result2 = 8
    + %stored2  = icmp eq i32 %result2, 5       ; yields {i1}:stored2 = false
    + 
    + %memval2  = load i32* %ptr                ; yields {i32}:memval2 = 8
    + 
    +
    + + + +
    +
    Syntax:
    + +

    + This is an overloaded intrinsic. You can use llvm.atomic.swap on any + integer bit width. Not all targets support all bit widths however.

    +
    + declare i8 @llvm.atomic.swap.i8.p0i8( i8* <ptr>, i8 <val> )
    + declare i16 @llvm.atomic.swap.i16.p0i16( i16* <ptr>, i16 <val> )
    + declare i32 @llvm.atomic.swap.i32.p0i32( i32* <ptr>, i32 <val> )
    + declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> )
    + 
    + 
    +
    Overview:
    +

    + This intrinsic loads the value stored in memory at ptr and yields + the value from memory. It then stores the value in val in the memory + at ptr. +

    +
    Arguments:
    + +

    + The llvm.atomic.swap intrinsic takes two arguments. Both the + val argument and the result must be integers of the same bit width. + The first argument, ptr, must be a pointer to a value of this + integer type. The targets may only lower integer representations they + support. +

    +
    Semantics:
    +

    + This intrinsic loads the value pointed to by ptr, yields it, and + stores val back into ptr atomically. This provides the + equivalent of an atomic swap operation within the SSA framework. + +

    +
    Examples:
    +
    + %ptr      = malloc i32
    +             store i32 4, %ptr
    + 
    + %val1     = add i32 4, 4
    + %result1  = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val1 )
    +                                         ; yields {i32}:result1 = 4
    + %stored1  = icmp eq i32 %result1, 4     ; yields {i1}:stored1 = true
    + %memval1  = load i32* %ptr              ; yields {i32}:memval1 = 8
    + 
    + %val2     = add i32 1, 1
    + %result2  = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val2 )
    +                                         ; yields {i32}:result2 = 8
    + 
    + %stored2  = icmp eq i32 %result2, 8     ; yields {i1}:stored2 = true
    + %memval2  = load i32* %ptr              ; yields {i32}:memval2 = 2
    + 
    +
    + + + +
    +
    Syntax:
    +

    + This is an overloaded intrinsic. You can use llvm.atomic.load.add on any + integer bit width. Not all targets support all bit widths however.

    +
    + declare i8 @llvm.atomic.load.add.i8..p0i8( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.add.i16..p0i16( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.add.i32..p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> )
    + 
    + 
    +
    Overview:
    +

    + This intrinsic adds delta to the value stored in memory at + ptr. It yields the original value at ptr. +

    +
    Arguments:
    +

    + + The intrinsic takes two arguments, the first a pointer to an integer value + and the second an integer value. The result is also an integer value. These + integer types can have any bit width, but they must all have the same bit + width. The targets may only lower integer representations they support. +

    +
    Semantics:
    +

    + This intrinsic does a series of operations atomically. It first loads the + value stored at ptr. It then adds delta, stores the result + to ptr. It yields the original value stored at ptr. +

    + +
    Examples:
    +
    + %ptr      = malloc i32
    +         store i32 4, %ptr
    + %result1  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 )
    +                                 ; yields {i32}:result1 = 4
    + %result2  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 )
    +                                 ; yields {i32}:result2 = 8
    + %result3  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 5 )
    +                                 ; yields {i32}:result3 = 10
    + %memval1  = load i32* %ptr      ; yields {i32}:memval1 = 15
    + 
    +
    + + + +
    +
    Syntax:
    +

    + This is an overloaded intrinsic. You can use llvm.atomic.load.sub on + any integer bit width and for different address spaces. Not all targets + support all bit widths however.

    +
    + declare i8 @llvm.atomic.load.sub.i8.p0i32( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.sub.i16.p0i32( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.sub.i32.p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> )
    + 
    + 
    +
    Overview:
    +

    + This intrinsic subtracts delta to the value stored in memory at + ptr. It yields the original value at ptr. +

    +
    Arguments:
    +

    + + The intrinsic takes two arguments, the first a pointer to an integer value + and the second an integer value. The result is also an integer value. These + integer types can have any bit width, but they must all have the same bit + width. The targets may only lower integer representations they support. +

    +
    Semantics:
    +

    + This intrinsic does a series of operations atomically. It first loads the + value stored at ptr. It then subtracts delta, stores the + result to ptr. It yields the original value stored at ptr. +

    + +
    Examples:
    +
    + %ptr      = malloc i32
    +         store i32 8, %ptr
    + %result1  = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 )
    +                                 ; yields {i32}:result1 = 8
    + %result2  = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 )
    +                                 ; yields {i32}:result2 = 4
    + %result3  = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 5 )
    +                                 ; yields {i32}:result3 = 2
    + %memval1  = load i32* %ptr      ; yields {i32}:memval1 = -3
    + 
    +
    + + + +
    +
    Syntax:
    +

    + These are overloaded intrinsics. You can use llvm.atomic.load_and, + llvm.atomic.load_nand, llvm.atomic.load_or, and + llvm.atomic.load_xor on any integer bit width and for different + address spaces. Not all targets support all bit widths however.

    +
    + declare i8 @llvm.atomic.load.and.i8.p0i8( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.and.i16.p0i16( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.and.i32.p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.and.i64.p0i64( i64* <ptr>, i64 <delta> )
    + 
    + 
    + +
    + declare i8 @llvm.atomic.load.or.i8.p0i8( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.or.i16.p0i16( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.or.i32.p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.or.i64.p0i64( i64* <ptr>, i64 <delta> )
    + 
    + 
    + +
    + declare i8 @llvm.atomic.load.nand.i8.p0i32( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.nand.i16.p0i32( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.nand.i32.p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.nand.i64.p0i32( i64* <ptr>, i64 <delta> )
    + 
    + 
    + +
    + declare i8 @llvm.atomic.load.xor.i8.p0i32( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.xor.i16.p0i32( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.xor.i32.p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.xor.i64.p0i32( i64* <ptr>, i64 <delta> )
    + 
    + 
    +
    Overview:
    +

    + These intrinsics bitwise the operation (and, nand, or, xor) delta to + the value stored in memory at ptr. It yields the original value + at ptr. +

    +
    Arguments:
    +

    + + These intrinsics take two arguments, the first a pointer to an integer value + and the second an integer value. The result is also an integer value. These + integer types can have any bit width, but they must all have the same bit + width. The targets may only lower integer representations they support. +

    +
    Semantics:
    +

    + These intrinsics does a series of operations atomically. They first load the + value stored at ptr. They then do the bitwise operation + delta, store the result to ptr. They yield the original + value stored at ptr. +

    + +
    Examples:
    +
    + %ptr      = malloc i32
    +         store i32 0x0F0F, %ptr
    + %result0  = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF )
    +                                 ; yields {i32}:result0 = 0x0F0F
    + %result1  = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF )
    +                                 ; yields {i32}:result1 = 0xFFFFFFF0
    + %result2  = call i32 @llvm.atomic.load.or.i32.p0i32( i32* %ptr, i32 0F )
    +                                 ; yields {i32}:result2 = 0xF0
    + %result3  = call i32 @llvm.atomic.load.xor.i32.p0i32( i32* %ptr, i32 0F )
    +                                 ; yields {i32}:result3 = FF
    + %memval1  = load i32* %ptr      ; yields {i32}:memval1 = F0
    + 
    +
    + + + + +
    +
    Syntax:
    +

    + These are overloaded intrinsics. You can use llvm.atomic.load_max, + llvm.atomic.load_min, llvm.atomic.load_umax, and + llvm.atomic.load_umin on any integer bit width and for different + address spaces. Not all targets + support all bit widths however.

    +
    + declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> )
    + 
    + 
    + +
    + declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.min.i64..p0i64( i64* <ptr>, i64 <delta> )
    + 
    + 
    + +
    + declare i8 @llvm.atomic.load.umax.i8.p0i8( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.umax.i16.p0i16( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.umax.i32.p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.umax.i64.p0i64( i64* <ptr>, i64 <delta> )
    + 
    + 
    + +
    + declare i8 @llvm.atomic.load.umin.i8..p0i8( i8* <ptr>, i8 <delta> )
    + declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* <ptr>, i16 <delta> )
    + declare i32 @llvm.atomic.load.umin.i32..p0i32( i32* <ptr>, i32 <delta> )
    + declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* <ptr>, i64 <delta> )
    + 
    + 
    +
    Overview:
    +

    + These intrinsics takes the signed or unsigned minimum or maximum of + delta and the value stored in memory at ptr. It yields the + original value at ptr. +

    +
    Arguments:
    +

    + + These intrinsics take two arguments, the first a pointer to an integer value + and the second an integer value. The result is also an integer value. These + integer types can have any bit width, but they must all have the same bit + width. The targets may only lower integer representations they support. +

    +
    Semantics:
    +

    + These intrinsics does a series of operations atomically. They first load the + value stored at ptr. They then do the signed or unsigned min or max + delta and the value, store the result to ptr. They yield + the original value stored at ptr. +

    + +
    Examples:
    +
    + %ptr      = malloc i32
    +         store i32 7, %ptr
    + %result0  = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 )
    +                                 ; yields {i32}:result0 = 7
    + %result1  = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 )
    +                                 ; yields {i32}:result1 = -2
    + %result2  = call i32 @llvm.atomic.load.umin.i32.p0i32( i32* %ptr, i32 10 )
    +                                 ; yields {i32}:result2 = 8
    + %result3  = call i32 @llvm.atomic.load.umax.i32.p0i32( i32* %ptr, i32 30 )
    +                                 ; yields {i32}:result3 = 8
    + %memval1  = load i32* %ptr      ; yields {i32}:memval1 = 30
    + 
    +
    + + + + +
    +

    This class of intrinsics is designed to be generic and has + no specific purpose.

    +
    + + + + +
    + +
    Syntax:
    +
    +   declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32  <int> )
    + 
    + +
    Overview:
    + +

    + The 'llvm.var.annotation' intrinsic +

    + +
    Arguments:
    + +

    + The first argument is a pointer to a value, the second is a pointer to a + global string, the third is a pointer to a global string which is the source + file name, and the last argument is the line number. +

    + +
    Semantics:
    + +

    + This intrinsic allows annotation of local variables with arbitrary strings. + This can be useful for special purpose optimizations that want to look for these + annotations. These have no other defined use, they are ignored by code + generation and optimization. +

    +
    + + + + +
    + +
    Syntax:
    +

    This is an overloaded intrinsic. You can use 'llvm.annotation' on + any integer bit width. +

    +
    +   declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32  <int> )
    +   declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32  <int> )
    +   declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32  <int> )
    +   declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32  <int> )
    +   declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32  <int> )
    + 
    + +
    Overview:
    + +

    + The 'llvm.annotation' intrinsic. +

    + +
    Arguments:
    + +

    + The first argument is an integer value (result of some expression), + the second is a pointer to a global string, the third is a pointer to a global + string which is the source file name, and the last argument is the line number. + It returns the value of the first argument. +

    + +
    Semantics:
    + +

    + This intrinsic allows annotations to be put on arbitrary expressions + with arbitrary strings. This can be useful for special purpose optimizations + that want to look for these annotations. These have no other defined use, they + are ignored by code generation and optimization. +

    +
    + + + + +
    + +
    Syntax:
    +
    +   declare void @llvm.trap()
    + 
    + +
    Overview:
    + +

    + The 'llvm.trap' intrinsic +

    + +
    Arguments:
    + +

    + None +

    + +
    Semantics:
    + +

    + This intrinsics is lowered to the target dependent trap instruction. If the + target does not have a trap instruction, this intrinsic will be lowered to the + call of the abort() function. +

    +
    + + + +
    +
    Syntax:
    +
    + declare void @llvm.stackprotector( i8* <guard>, i8** <slot> )
    + 
    + 
    +
    Overview:
    +

    + The llvm.stackprotector intrinsic takes the guard and stores + it onto the stack at slot. The stack slot is adjusted to ensure that + it is placed on the stack before local variables. +

    +
    Arguments:
    +

    + The llvm.stackprotector intrinsic requires two pointer arguments. The + first argument is the value loaded from the stack guard + @__stack_chk_guard. The second variable is an alloca that + has enough space to hold the value of the guard. +

    +
    Semantics:
    +

    + This intrinsic causes the prologue/epilogue inserter to force the position of + the AllocaInst stack slot to be before local variables on the + stack. This is to ensure that if a local variable on the stack is overwritten, + it will destroy the value of the guard. When the function exits, the guard on + the stack is checked against the original guard. If they're different, then + the program aborts by calling the __stack_chk_fail() function. +

    +
    + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Chris Lattner
    + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/Lexicon.html diff -c /dev/null llvm-www/releases/2.5/docs/Lexicon.html:1.1 *** /dev/null Mon Mar 2 23:19:09 2009 --- llvm-www/releases/2.5/docs/Lexicon.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,263 ---- + + + + + The LLVM Lexicon + + + + + +
    The LLVM Lexicon
    +

    NOTE: This document is a work in progress!

    + +
    Table Of Contents
    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    - A -
    ADCE
    - B -
    BURS
    - C -
    CSE
    - D -
    DAGDerived PointerDSADSE
    - G -
    GC
    - I -
    IPAIPOISel
    - L -
    LCSSALICMLoad-VN
    - O -
    Object Pointer
    - P -
    PRE
    - R -
    RAUWReassociationRoot
    - S -
    Safe PointSCCSCCPSDISelSRoAStack Map
    +
    + + +
    Definitions
    + + + +
    +
    +
    ADCE
    +
    Aggressive Dead Code Elimination
    +
    +
    + + +
    +
    +
    BURS
    +
    Bottom Up Rewriting System—A method of instruction selection for + code generation. An example is the BURG tool.
    +
    +
    + + +
    +
    +
    CSE
    +
    Common Subexpression Elimination. An optimization that removes common + subexpression compuation. For example (a+b)*(a+b) has two + subexpressions that are the same: (a+b). This optimization would + perform the addition only once and then perform the multiply (but only if + it's compulationally correct/safe). +
    +
    + + +
    +
    +
    DAG
    +
    Directed Acyclic Graph
    +
    Derived Pointer
    +
    A pointer to the interior of an object, such that a garbage collector + is unable to use the pointer for reachability analysis. While a derived + pointer is live, the corresponding object pointer must be kept in a root, + otherwise the collector might free the referenced object. With copying + collectors, derived pointers pose an additional hazard that they may be + invalidated at any safe point. This term is used in + opposition to object pointer.
    +
    DSA
    +
    Data Structure Analysis
    +
    DSE
    +
    Dead Store Elimination
    +
    +
    + + +
    +
    +
    GC
    +
    Garbage Collection. The practice of using reachability analysis instead + of explicit memory management to reclaim unused memory.
    +
    +
    + + +
    +
    +
    Heap
    +
    In garbage collection, the region of memory which is managed using + reachability analysis.
    +
    +
    + + +
    +
    +
    IPA
    +
    Inter-Procedural Analysis. Refers to any variety of code analysis that + occurs between procedures, functions or compilation units (modules).
    +
    IPO
    +
    Inter-Procedural Optimization. Refers to any variety of code + optimization that occurs between procedures, functions or compilation units + (modules).
    +
    ISel
    +
    Instruction Selection.
    +
    +
    + + +
    +
    +
    LCSSA
    +
    Loop-Closed Static Single Assignment Form
    +
    LICM
    +
    Loop Invariant Code Motion
    +
    Load-VN
    +
    Load Value Numbering
    +
    +
    + + + +
    +
    +
    Object Pointer
    +
    A pointer to an object such that the garbage collector is able to trace + references contained within the object. This term is used in opposition to + derived pointer.
    +
    +
    + + + +
    +
    +
    PRE
    +
    Partial Redundancy Elimination
    +
    +
    + + + +
    +
    +
    RAUW
    An abbreviation for Replace + All Uses With. The functions User::replaceUsesOfWith(), + Value::replaceAllUsesWith(), and Constant::replaceUsesOfWithOnConstant() + implement the replacement of one Value with another by iterating over its + def/use chain and fixing up all of the pointers to point to the new value. + See also def/use chains. +
    +
    Reassociation
    Rearranging + associative expressions to promote better redundancy elimination and other + optimization. For example, changing (A+B-A) into (B+A-A), permitting it to + be optimized into (B+0) then (B).
    +
    Root
    In garbage collection, a + pointer variable lying outside of the heap from which + the collector begins its reachability analysis. In the context of code + generation, "root" almost always refers to a "stack root" -- a local or + temporary variable within an executing function.
    +
    +
    + + + +
    +
    +
    Safe Point
    +
    In garbage collection, it is necessary to identify stack + roots so that reachability analysis may proceed. It may be infeasible to + provide this information for every instruction, so instead the information + may is calculated only at designated safe points. With a copying collector, + derived pointers must not be retained across + safe points and object pointers must be + reloaded from stack roots.
    +
    SDISel
    +
    Selection DAG Instruction Selection.
    +
    SCC
    +
    Strongly Connected Component
    +
    SCCP
    +
    Sparse Conditional Constant Propagation
    +
    SRoA
    +
    Scalar Replacement of Aggregates
    +
    SSA
    +
    Static Single Assignment
    +
    Stack Map
    +
    In garbage collection, metadata emitted by the code generator which + identifies roots within the stack frame of an executing + function.
    +
    +
    + +
    +
    Valid CSSValid HTML 4.01The LLVM Team
    + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/LinkTimeOptimization.html diff -c /dev/null llvm-www/releases/2.5/docs/LinkTimeOptimization.html:1.1 *** /dev/null Mon Mar 2 23:19:09 2009 --- llvm-www/releases/2.5/docs/LinkTimeOptimization.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,390 ---- + + + + LLVM Link Time Optimization: Design and Implementation + + + +
    + LLVM Link Time Optimization: Design and Implementation +
    + + + +
    +

    Written by Devang Patel and Nick Kledzik

    +
    + + + + + +
    +

    + LLVM features powerful intermodular optimizations which can be used at link + time. Link Time Optimization (LTO) is another name for intermodular optimization + when performed during the link stage. This document describes the interface + and design between the LTO optimizer and the linker.

    +
    + + + + + +
    +

    + The LLVM Link Time Optimizer provides complete transparency, while doing + intermodular optimization, in the compiler tool chain. Its main goal is to let + the developer take advantage of intermodular optimizations without making any + significant changes to the developer's makefiles or build system. This is + achieved through tight integration with the linker. In this model, the linker + treates LLVM bitcode files like native object files and allows mixing and + matching among them. The linker uses libLTO, a shared + object, to handle LLVM bitcode files. This tight integration between + the linker and LLVM optimizer helps to do optimizations that are not possible + in other models. The linker input allows the optimizer to avoid relying on + conservative escape analysis. +

    +
    + + + + +
    +

    The following example illustrates the advantages of LTO's integrated + approach and clean interface. This example requires a system linker which + supports LTO through the interface described in this document. Here, + llvm-gcc transparently invokes system linker.

    +
      +
    • Input source file a.c is compiled into LLVM bitcode form. +
    • Input source file main.c is compiled into native object code. +
    +
    + --- a.h ---
    + extern int foo1(void);
    + extern void foo2(void);
    + extern void foo4(void);
    + --- a.c ---
    + #include "a.h"
    + 
    + static signed int i = 0;
    + 
    + void foo2(void) {
    +  i = -1;
    + }
    + 
    + static int foo3() {
    + foo4();
    + return 10;
    + }
    + 
    + int foo1(void) {
    + int data = 0;
    + 
    + if (i < 0) { data = foo3(); }
    + 
    + data = data + 42;
    + return data;
    + }
    + 
    + --- main.c ---
    + #include <stdio.h>
    + #include "a.h"
    + 
    + void foo4(void) {
    +  printf ("Hi\n");
    + }
    + 
    + int main() {
    +  return foo1();
    + }
    + 
    + --- command lines ---
    + $ llvm-gcc --emit-llvm -c a.c -o a.o  # <-- a.o is LLVM bitcode file
    + $ llvm-gcc -c main.c -o main.o # <-- main.o is native object file
    + $ llvm-gcc a.o main.o -o main # <-- standard link command without any modifications
    + 
    +

    In this example, the linker recognizes that foo2() is an + externally visible symbol defined in LLVM bitcode file. The linker completes + its usual symbol resolution + pass and finds that foo2() is not used anywhere. This information + is used by the LLVM optimizer and it removes foo2(). As soon as + foo2() is removed, the optimizer recognizes that condition + i < 0 is always false, which means foo3() is never + used. Hence, the optimizer removes foo3(), also. And this in turn, + enables linker to remove foo4(). This example illustrates the + advantage of tight integration with the linker. Here, the optimizer can not + remove foo3() without the linker's input. +

    +
    + + + + +
    +
    +
    Compiler driver invokes link time optimizer separately.
    +
    In this model the link time optimizer is not able to take advantage of + information collected during the linker's normal symbol resolution phase. + In the above example, the optimizer can not remove foo2() without + the linker's input because it is externally visible. This in turn prohibits + the optimizer from removing foo3().
    +
    Use separate tool to collect symbol information from all object + files.
    +
    In this model, a new, separate, tool or library replicates the linker's + capability to collect information for link time optimization. Not only is + this code duplication difficult to justify, but it also has several other + disadvantages. For example, the linking semantics and the features + provided by the linker on various platform are not unique. This means, + this new tool needs to support all such features and platforms in one + super tool or a separate tool per platform is required. This increases + maintance cost for link time optimizer significantly, which is not + necessary. This approach also requires staying synchronized with linker + developements on various platforms, which is not the main focus of the link + time optimizer. Finally, this approach increases end user's build time due + to the duplication of work done by this separate tool and the linker itself. +
    +
    +
    + + + + +
    +

    The linker collects information about symbol defininitions and uses in + various link objects which is more accurate than any information collected + by other tools during typical build cycles. The linker collects this + information by looking at the definitions and uses of symbols in native .o + files and using symbol visibility information. The linker also uses + user-supplied information, such as a list of exported symbols. LLVM + optimizer collects control flow information, data flow information and knows + much more about program structure from the optimizer's point of view. + Our goal is to take advantage of tight intergration between the linker and + the optimizer by sharing this information during various linking phases. +

    +
    + + + + +
    +

    The linker first reads all object files in natural order and collects + symbol information. This includes native object files as well as LLVM bitcode + files. To minimize the cost to the linker in the case that all .o files + are native object files, the linker only calls lto_module_create() + when a supplied object file is found to not be a native object file. If + lto_module_create() returns that the file is an LLVM bitcode file, + the linker + then iterates over the module using lto_module_get_symbol_name() and + lto_module_get_symbol_attribute() to get all symbols defined and + referenced. + This information is added to the linker's global symbol table. +

    +

    The lto* functions are all implemented in a shared object libLTO. This + allows the LLVM LTO code to be updated independently of the linker tool. + On platforms that support it, the shared object is lazily loaded. +

    +
    + + + + +
    +

    In this stage, the linker resolves symbols using global symbol table. + It may report undefined symbol errors, read archive members, replace + weak symbols, etc. The linker is able to do this seamlessly even though it + does not know the exact content of input LLVM bitcode files. If dead code + stripping is enabled then the linker collects the list of live symbols. +

    +
    + + + +
    +

    After symbol resolution, the linker tells the LTO shared object which + symbols are needed by native object files. In the example above, the linker + reports that only foo1() is used by native object files using + lto_codegen_add_must_preserve_symbol(). Next the linker invokes + the LLVM optimizer and code generators using lto_codegen_compile() + which returns a native object file creating by merging the LLVM bitcode files + and applying various optimization passes. +

    +
    + + + + +
    +

    In this phase, the linker reads optimized a native object file and + updates the internal global symbol table to reflect any changes. The linker + also collects information about any changes in use of external symbols by + LLVM bitcode files. In the examle above, the linker notes that + foo4() is not used any more. If dead code stripping is enabled then + the linker refreshes the live symbol information appropriately and performs + dead code stripping.

    +

    After this phase, the linker continues linking as if it never saw LLVM + bitcode files.

    +
    + + +
    + libLTO +
    + +
    +

    libLTO is a shared object that is part of the LLVM tools, and + is intended for use by a linker. libLTO provides an abstract C + interface to use the LLVM interprocedural optimizer without exposing details + of LLVM's internals. The intention is to keep the interface as stable as + possible even when the LLVM optimizer continues to evolve. It should even + be possible for a completely different compilation technology to provide + a different libLTO that works with their object files and the standard + linker tool.

    +
    + + + + +
    + +

    A non-native object file is handled via an lto_module_t. + The following functions allow the linker to check if a file (on disk + or in a memory buffer) is a file which libLTO can process:

    + +
    + lto_module_is_object_file(const char*)
    + lto_module_is_object_file_for_target(const char*, const char*)
    + lto_module_is_object_file_in_memory(const void*, size_t)
    + lto_module_is_object_file_in_memory_for_target(const void*, size_t, const char*)
    + 
    + +

    If the object file can be processed by libLTO, the linker creates a + lto_module_t by using one of

    + +
    + lto_module_create(const char*)
    + lto_module_create_from_memory(const void*, size_t)
    + 
    + +

    and when done, the handle is released via

    + +
    + lto_module_dispose(lto_module_t)
    + 
    + +

    The linker can introspect the non-native object file by getting the number of + symbols and getting the name and attributes of each symbol via:

    + +
    + lto_module_get_num_symbols(lto_module_t)
    + lto_module_get_symbol_name(lto_module_t, unsigned int)
    + lto_module_get_symbol_attribute(lto_module_t, unsigned int)
    + 
    + +

    The attributes of a symbol include the alignment, visibility, and kind.

    +
    + + + + +
    + +

    Once the linker has loaded each non-native object files into an + lto_module_t, it can request libLTO to process them all and + generate a native object file. This is done in a couple of steps. + First, a code generator is created with:

    + +
    lto_codegen_create()
    + +

    Then, each non-native object file is added to the code generator with:

    + +
    + lto_codegen_add_module(lto_code_gen_t, lto_module_t)
    + 
    + +

    The linker then has the option of setting some codegen options. Whether or + not to generate DWARF debug info is set with:

    + +
    lto_codegen_set_debug_model(lto_code_gen_t)
    + +

    Which kind of position independence is set with:

    + +
    lto_codegen_set_pic_model(lto_code_gen_t) 
    + +

    And each symbol that is referenced by a native object file or otherwise must + not be optimized away is set with:

    + +
    + lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)
    + 
    + +

    After all these settings are done, the linker requests that a native object + file be created from the modules with the settings using:

    + +
    lto_codegen_compile(lto_code_gen_t, size*)
    + +

    which returns a pointer to a buffer containing the generated native + object file. The linker then parses that and links it with the rest + of the native object files.

    + +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Devang Patel and Nick Kledzik
    + LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + + Index: llvm-www/releases/2.5/docs/Makefile diff -c /dev/null llvm-www/releases/2.5/docs/Makefile:1.1 *** /dev/null Mon Mar 2 23:19:09 2009 --- llvm-www/releases/2.5/docs/Makefile Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,125 ---- + ##===- docs/Makefile ---------------------------------------*- Makefile -*-===## + # + # The LLVM Compiler Infrastructure + # + # This file is distributed under the University of Illinois Open Source + # License. See LICENSE.TXT for details. + # + ##===----------------------------------------------------------------------===## + + LEVEL := .. + DIRS := CommandGuide tutorial + + ifdef BUILD_FOR_WEBSITE + PROJ_OBJ_DIR = . + DOXYGEN = doxygen + + $(PROJ_OBJ_DIR)/doxygen.cfg: doxygen.cfg.in + cat $< | sed \ + -e 's/@abs_top_srcdir@/../g' \ + -e 's/@DOT@/dot/g' \ + -e 's/@PACKAGE_VERSION@/mainline/' \ + -e 's/@abs_top_builddir@/../g' > $@ + endif + + include $(LEVEL)/Makefile.common + + HTML := $(wildcard $(PROJ_SRC_DIR)/*.html) \ + $(wildcard $(PROJ_SRC_DIR)/*.css) + IMAGES := $(wildcard $(PROJ_SRC_DIR)/img/*.*) + DOXYFILES := doxygen.cfg.in doxygen.css doxygen.footer doxygen.header \ + doxygen.intro + EXTRA_DIST := $(HTML) $(DOXYFILES) llvm.css CommandGuide img + + .PHONY: install-html install-doxygen doxygen install-ocamldoc ocamldoc generated + + install_targets := install-html + ifeq ($(ENABLE_DOXYGEN),1) + install_targets += install-doxygen + endif + ifneq (,$(filter ocaml,$(BINDINGS_TO_BUILD))) + install_targets += install-ocamldoc + endif + install-local:: $(install_targets) + + # Live documentation is generated for the web site using this target: + # 'make generated BUILD_FOR_WEBSITE=1' + generated:: doxygen ocamldoc + + install-html: $(PROJ_OBJ_DIR)/html.tar.gz + $(Echo) Installing HTML documentation + $(Verb) $(MKDIR) $(PROJ_docsdir)/html + $(Verb) $(MKDIR) $(PROJ_docsdir)/html/img + $(Verb) $(DataInstall) $(HTML) $(PROJ_docsdir)/html + $(Verb) $(DataInstall) $(IMAGES) $(PROJ_docsdir)/html/img + $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/html.tar.gz $(PROJ_docsdir) + + $(PROJ_OBJ_DIR)/html.tar.gz: $(HTML) + $(Echo) Packaging HTML documentation + $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/html.tar + $(Verb) cd $(PROJ_SRC_DIR) && \ + $(TAR) cf $(PROJ_OBJ_DIR)/html.tar *.html + $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/html.tar + + install-doxygen: doxygen + $(Echo) Installing doxygen documentation + $(Verb) $(MKDIR) $(PROJ_docsdir)/html/doxygen + $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_docsdir) + $(Verb) cd $(PROJ_OBJ_DIR)/doxygen && \ + $(FIND) . -type f -exec \ + $(DataInstall) {} $(PROJ_docsdir)/html/doxygen \; + + doxygen: regendoc $(PROJ_OBJ_DIR)/doxygen.tar.gz + + regendoc: + $(Echo) Building doxygen documentation + $(Verb) if test -e $(PROJ_OBJ_DIR)/doxygen ; then \ + $(RM) -rf $(PROJ_OBJ_DIR)/doxygen ; \ + fi + $(Verb) $(DOXYGEN) $(PROJ_OBJ_DIR)/doxygen.cfg + + $(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg + $(Echo) Packaging doxygen documentation + $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/doxygen.tar + $(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/doxygen.tar doxygen + $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/doxygen.tar + $(Verb) $(CP) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_OBJ_DIR)/doxygen/html/ + + userloc: $(LLVM_SRC_ROOT)/docs/userloc.html + + $(LLVM_SRC_ROOT)/docs/userloc.html: + $(Echo) Making User LOC Table + $(Verb) cd $(LLVM_SRC_ROOT) ; ./utils/userloc.pl -details -recurse \ + -html lib include tools runtime utils examples autoconf test > docs/userloc.html + + install-ocamldoc: ocamldoc + $(Echo) Installing ocamldoc documentation + $(Verb) $(MKDIR) $(PROJ_docsdir)/ocamldoc/html + $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/ocamldoc.tar.gz $(PROJ_docsdir) + $(Verb) cd $(PROJ_OBJ_DIR)/ocamldoc && \ + $(FIND) . -type f -exec \ + $(DataInstall) {} $(PROJ_docsdir)/ocamldoc/html \; + + ocamldoc: regen-ocamldoc $(PROJ_OBJ_DIR)/ocamldoc.tar.gz + + regen-ocamldoc: + $(Echo) Building ocamldoc documentation + $(Verb) if test -e $(PROJ_OBJ_DIR)/ocamldoc ; then \ + $(RM) -rf $(PROJ_OBJ_DIR)/ocamldoc ; \ + fi + $(Verb) $(MAKE) -C $(LEVEL)/bindings/ocaml ocamldoc + $(Verb) $(MKDIR) $(PROJ_OBJ_DIR)/ocamldoc/html + $(Verb) \ + $(OCAMLDOC) -d $(PROJ_OBJ_DIR)/ocamldoc/html -sort -colorize-code -html \ + `$(FIND) $(LEVEL)/bindings/ocaml -name "*.odoc" -exec echo -load '{}' ';'` + + $(PROJ_OBJ_DIR)/ocamldoc.tar.gz: + $(Echo) Packaging ocamldoc documentation + $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/ocamldoc.tar + $(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/ocamldoc.tar ocamldoc + $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/ocamldoc.tar + $(Verb) $(CP) $(PROJ_OBJ_DIR)/ocamldoc.tar.gz $(PROJ_OBJ_DIR)/ocamldoc/html/ + + uninstall-local:: + $(Echo) Uninstalling Documentation + $(Verb) $(RM) -rf $(PROJ_docsdir) Index: llvm-www/releases/2.5/docs/MakefileGuide.html diff -c /dev/null llvm-www/releases/2.5/docs/MakefileGuide.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/MakefileGuide.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,1033 ---- + + + + + LLVM Makefile Guide + + + + +
    LLVM Makefile Guide
    + +
      +
    1. Introduction
    2. +
    3. General Concepts +
        +
      1. Projects
      2. +
      3. Variable Values
      4. +
      5. Including Makefiles +
          +
        1. Makefile
        2. +
        3. Makefile.common
        4. +
        5. Makefile.config
        6. +
        7. Makefile.rules
        8. +
        +
      6. +
      7. Comments
      8. +
      +
    4. +
    5. Tutorial +
        +
      1. Libraries +
          +
        1. Bitcode Modules
        2. +
        3. Loadable Modules
        4. +
        +
      2. +
      3. Tools +
          +
        1. JIT Tools
        2. +
        +
      4. +
      5. Projects
      6. +
      +
    6. +
    7. Targets Supported +
        +
      1. all
      2. +
      3. all-local
      4. +
      5. check
      6. +
      7. check-local
      8. +
      9. clean
      10. +
      11. clean-local
      12. +
      13. dist
      14. +
      15. dist-check
      16. +
      17. dist-clean
      18. +
      19. install
      20. +
      21. preconditions
      22. +
      23. printvars
      24. +
      25. reconfigure
      26. +
      27. spotless
      28. +
      29. tags
      30. +
      31. uninstall
      32. +
      +
    8. +
    9. Using Variables +
        +
      1. Control Variables
      2. +
      3. Override Variables
      4. +
      5. Readable Variables
      6. +
      7. Internal Variables
      8. +
      +
    10. +
    + +
    +

    Written by Reid Spencer

    +
    + + + + + +
    +

    This document provides usage information about the LLVM makefile + system. While loosely patterned after the BSD makefile system, LLVM has taken + a departure from BSD in order to implement additional features needed by LLVM. + Although makefile systems such as automake were attempted at one point, it + has become clear that the features needed by LLVM and the Makefile norm are + too great to use a more limited tool. Consequently, LLVM requires simply GNU + Make 3.79, a widely portable makefile processor. LLVM unabashedly makes heavy + use of the features of GNU Make so the dependency on GNU Make is firm. If + you're not familiar with make, it is recommended that you read the + GNU Makefile + Manual.

    +

    While this document is rightly part of the + LLVM Programmer's Manual, it is treated + separately here because of the volume of content and because it is often an + early source of bewilderment for new developers.

    +
    + + + + + +
    +

    The LLVM Makefile System is the component of LLVM that is responsible for + building the software, testing it, generating distributions, checking those + distributions, installing and uninstalling, etc. It consists of a several + files throughout the source tree. These files and other general concepts are + described in this section.

    +
    + + + +
    +

    The LLVM Makefile System is quite generous. It not only builds its own + software, but it can build yours too. Built into the system is knowledge of + the llvm/projects directory. Any directory under projects + that has both a configure script and a Makefile is assumed + to be a project that uses the LLVM Makefile system. Building software that + uses LLVM does not require the LLVM Makefile System nor even placement in the + llvm/projects directory. However, doing so will allow your project + to get up and running quickly by utilizing the built-in features that are used + to compile LLVM. LLVM compiles itself using the same features of the makefile + system as used for projects.

    +

    For complete details on setting up your projects configuration, simply + mimic the llvm/projects/sample project or for further details, + consult the Projects.html page.

    +
    + + + +
    +

    To use the makefile system, you simply create a file named + Makefile in your directory and declare values for certain variables. + The variables and values that you select determine what the makefile system + will do. These variables enable rules and processing in the makefile system + that automatically Do The Right Thing™. +

    + + + +
    +

    Setting variables alone is not enough. You must include into your Makefile + additional files that provide the rules of the LLVM Makefile system. The + various files involved are described in the sections that follow.

    +
    + + + +
    +

    Each directory to participate in the build needs to have a file named + Makefile. This is the file first read by make. It has three + sections:

    +
      +
    1. Settable Variables - Required that must be set + first.
    2. +
    3. include $(LEVEL)/Makefile.common + - include the LLVM Makefile system. +
    4. Override Variables - Override variables set by + the LLVM Makefile system. +
    +
    + + + +
    +

    Every project must have a Makefile.common file at its top source + directory. This file serves three purposes:

    +
      +
    1. It includes the project's configuration makefile to obtain values + determined by the configure script. This is done by including the + $(LEVEL)/Makefile.config file.
    2. +
    3. It specifies any other (static) values that are needed throughout the + project. Only values that are used in all or a large proportion of the + project's directories should be placed here.
    4. +
    5. It includes the standard rules for the LLVM Makefile system, + $(LLVM_SRC_ROOT)/Makefile.rules. + This file is the "guts" of the LLVM Makefile system.
    6. +
    +
    + + + +
    +

    Every project must have a Makefile.config at the top of its + build directory. This file is generated by the + configure script from the pattern provided by the + Makefile.config.in file located at the top of the project's + source directory. The contents of this file depend largely on what + configuration items the project uses, however most projects can get what they + need by just relying on LLVM's configuration found in + $(LLVM_OBJ_ROOT)/Makefile.config. +

    + + + +
    +

    This file, located at $(LLVM_SRC_ROOT)/Makefile.rules is the heart + of the LLVM Makefile System. It provides all the logic, dependencies, and + rules for building the targets supported by the system. What it does largely + depends on the values of make variables that + have been set before Makefile.rules is included. +

    + + + +
    +

    User Makefiles need not have comments in them unless the construction is + unusual or it does not strictly follow the rules and patterns of the LLVM + makefile system. Makefile comments are invoked with the pound (#) character. + The # character and any text following it, to the end of the line, are ignored + by make.

    +
    + + + + +
    +

    This section provides some examples of the different kinds of modules you + can build with the LLVM makefile system. In general, each directory you + provide will build a single object although that object may be composed of + additionally compiled components.

    +
    + + + +
    +

    Only a few variable definitions are needed to build a regular library. + Normally, the makefile system will build all the software into a single + libname.o (pre-linked) object. This means the library is not + searchable and that the distinction between compilation units has been + dissolved. Optionally, you can ask for a shared library (.so), archive library + (.a) or to not have the default (relinked) library built. For example:

    +
    
    +       LIBRARYNAME = mylib
    +       SHARED_LIBRARY = 1
    +       ARCHIVE_LIBRARY = 1
    +       DONT_BUILD_RELINKED = 1
    +   
    +

    says to build a library named "mylib" with both a shared library + (mylib.so) and an archive library (mylib.a) version but + not to build the relinked object (mylib.o). The contents of all the + libraries produced will be the same, they are just constructed differently. + Note that you normally do not need to specify the sources involved. The LLVM + Makefile system will infer the source files from the contents of the source + directory.

    +

    The LOADABLE_MODULE=1 directive can be used in conjunction with + SHARED_LIBRARY=1 to indicate that the resulting shared library should + be openable with the dlopen function and searchable with the + dlsym function (or your operating system's equivalents). While this + isn't strictly necessary on Linux and a few other platforms, it is required + on systems like HP-UX and Darwin. You should use LOADABLE_MODULE for + any shared library that you intend to be loaded into an tool via the + -load option. See the + WritingAnLLVMPass.html document + for an example of why you might want to do this. +

    + + + +
    +

    In some situations, it is desireable to build a single bitcode module from + a variety of sources, instead of an archive, shared library, or bitcode + library. Bitcode modules can be specified in addition to any of the other + types of libraries by defining the MODULE_NAME + variable. For example:

    +
    
    +       LIBRARYNAME = mylib
    +       BYTECODE_LIBRARY = 1
    +       MODULE_NAME = mymod
    +   
    +

    will build a module named mymod.bc from the sources in the + directory. This module will be an aggregation of all the bitcode modules + derived from the sources. The example will also build a bitcode archive + containing a bitcode module for each compiled source file. The difference is + subtle, but important depending on how the module or library is to be linked. +

    +
    + + + +
    +

    In some situations, you need to create a loadable module. Loadable modules + can be loaded into programs like opt or llc to specify + additional passes to run or targets to support. Loadable modules are also + useful for debugging a pass or providing a pass with another package if that + pass can't be included in LLVM.

    +

    LLVM provides complete support for building such a module. All you need to + do is use the LOADABLE_MODULE variable in your Makefile. For example, to + build a loadable module named MyMod that uses the LLVM libraries + LLVMSupport.a and LLVMSystem.a, you would specify:

    +
    
    +      LIBRARYNAME := MyMod
    +      LOADABLE_MODULE := 1
    +      LINK_COMPONENTS := support system
    +   
    +

    Use of the LOADABLE_MODULE facility implies several things:

    +
      +
    1. There will be no "lib" prefix on the module. This differentiates it from + a standard shared library of the same name.
    2. +
    3. The SHARED_LIBRARY variable is turned + on.
    4. +
    5. The LINK_LIBS_IN_SHARED variable + is turned on.
    6. +
    7. The DONT_BUILD_RELINKED variable + is turned on.
    8. +
    +

    A loadable module is loaded by LLVM via the facilities of libtool's libltdl + library which is part of lib/System implementation.

    +
    + + + +
    +

    For building executable programs (tools), you must provide the name of the + tool and the names of the libraries you wish to link with the tool. For + example:

    +
    
    +       TOOLNAME = mytool
    +       USEDLIBS = mylib
    +       LINK_COMPONENTS = support system
    +   
    +

    says that we are to build a tool name mytool and that it requires + three libraries: mylib, LLVMSupport.a and + LLVMSystem.a.

    +

    Note that two different variables are use to indicate which libraries are + linked: USEDLIBS and LLVMLIBS. This distinction is necessary + to support projects. LLVMLIBS refers to the LLVM libraries found in + the LLVM object directory. USEDLIBS refers to the libraries built by + your project. In the case of building LLVM tools, USEDLIBS and + LLVMLIBS can be used interchangeably since the "project" is LLVM + itself and USEDLIBS refers to the same place as LLVMLIBS. +

    +

    Also note that there are two different ways of specifying a library: with a + .a suffix and without. Without the suffix, the entry refers to the + re-linked (.o) file which will include all symbols of the library. + This is useful, for example, to include all passes from a library of passes. + If the .a suffix is used then the library is linked as a searchable + library (with the -l option). In this case, only the symbols that are + unresolved at that point will be resolved from the library, if they + exist. Other (unreferenced) symbols will not be included when the .a + syntax is used. Note that in order to use the .a suffix, the library + in question must have been built with the ARCHIVE_LIBRARY option set. +

    +
    + + + +
    +

    Many tools will want to use the JIT features of LLVM. To do this, you + simply specify that you want an execution 'engine', and the makefiles will + automatically link in the appropriate JIT for the host or an interpreter + if none is available:

    +
    
    +       TOOLNAME = my_jit_tool
    +       USEDLIBS = mylib
    +       LINK_COMPONENTS = engine
    +   
    +

    Of course, any additional libraries may be listed as other components. To + get a full understanding of how this changes the linker command, it is + recommended that you:

    +
    
    +       cd examples/Fibonacci
    +       make VERBOSE=1
    +   
    +
    + + + + + +
    +

    This section describes each of the targets that can be built using the LLVM + Makefile system. Any target can be invoked from any directory but not all are + applicable to a given directory (e.g. "check", "dist" and "install" will + always operate as if invoked from the top level directory).

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Target NameImplied TargetsTarget Description
    allCompile the software recursively. Default target. +
    all-localCompile the software in the local directory only. +
    checkChange to the test directory in a project and run the + test suite there. +
    check-localRun a local test suite. Generally this is only defined in the + Makefile of the project's test directory. +
    cleanRemove built objects recursively. +
    clean-localRemove built objects from the local directory only. +
    distallPrepare a source distribution tarball. +
    dist-checkallPrepare a source distribution tarball and check that it builds. +
    dist-cleancleanClean source distribution tarball temporary files. +
    installallCopy built objects to installation directory. +
    preconditionsallCheck to make sure configuration and makefiles are up to date. +
    printvarsallPrints variables defined by the makefile system (for debugging). +
    tagsMake C and C++ tags files for emacs and vi. +
    uninstallRemove built objects from installation directory. +
    +
    + + + +
    +

    When you invoke make with no arguments, you are implicitly + instructing it to seek the "all" target (goal). This target is used for + building the software recursively and will do different things in different + directories. For example, in a lib directory, the "all" target will + compile source files and generate libraries. But, in a tools + directory, it will link libraries and generate executables.

    +
    + + + +
    +

    This target is the same as all but it operates only on + the current directory instead of recursively.

    +
    + + + +
    +

    This target can be invoked from anywhere within a project's directories + but always invokes the check-local target + in the project's test directory, if it exists and has a + Makefile. A warning is produced otherwise. If + TESTSUITE is defined on the make + command line, it will be passed down to the invocation of + make check-local in the test directory. The intended usage + for this is to assist in running specific suites of tests. If + TESTSUITE is not set, the implementation of check-local + should run all normal tests. It is up to the project to define what + different values for TESTSUTE will do. See the + TestingGuide for further details.

    +
    + + + +
    +

    This target should be implemented by the Makefile in the project's + test directory. It is invoked by the check target elsewhere. + Each project is free to define the actions of check-local as + appropriate for that project. The LLVM project itself uses dejagnu to run a + suite of feature and regresson tests. Other projects may choose to use + dejagnu or any other testing mechanism.

    +
    + + + +
    +

    This target cleans the build directory, recursively removing all things + that the Makefile builds. The cleaning rules have been made guarded so they + shouldn't go awry (via rm -f $(UNSET_VARIABLE)/* which will attempt + to erase the entire directory structure.

    +
    + + + +
    +

    This target does the same thing as clean but only for the current + (local) directory.

    +
    + + + +
    +

    This target builds a distribution tarball. It first builds the entire + project using the all target and then tars up the necessary files and + compresses it. The generated tarball is sufficient for a casual source + distribution, but probably not for a release (see dist-check).

    +
    + + + +
    +

    This target does the same thing as the dist target but also checks + the distribution tarball. The check is made by unpacking the tarball to a new + directory, configuring it, building it, installing it, and then verifying that + the installation results are correct (by comparing to the original build). + This target can take a long time to run but should be done before a release + goes out to make sure that the distributed tarball can actually be built into + a working release.

    +
    + + + +
    +

    This is a special form of the clean clean target. It performs a + normal clean but also removes things pertaining to building the + distribution.

    +
    + + + +
    +

    This target finalizes shared objects and executables and copies all + libraries, headers, executables and documentation to the directory given + with the --prefix option to configure. When completed, + the prefix directory will have everything needed to use LLVM.

    +

    The LLVM makefiles can generate complete internal documentation + for all the classes by using doxygen. By default, this feature is + not enabled because it takes a long time and generates a massive + amount of data (>100MB). If you want this feature, you must configure LLVM + with the --enable-doxygen switch and ensure that a modern version of doxygen + (1.3.7 or later) is available in your PATH. You can download + doxygen from + + here. +

    + + + +
    +

    This utility target checks to see if the Makefile in the object + directory is older than the Makefile in the source directory and + copies it if so. It also reruns the configure script if that needs to + be done and rebuilds the Makefile.config file similarly. Users may + overload this target to ensure that sanity checks are run before any + building of targets as all the targets depend on preconditions.

    +
    + + + +
    +

    This utility target just causes the LLVM makefiles to print out some of + the makefile variables so that you can double check how things are set.

    +
    + + + +
    +

    This utility target will force a reconfigure of LLVM or your project. It + simply runs $(PROJ_OBJ_ROOT)/config.status --recheck to rerun the + configuration tests and rebuild the configured files. This isn't generally + useful as the makefiles will reconfigure themselves whenever its necessary. +

    +
    + + + +
    +

    This utility target, only available when $(PROJ_OBJ_ROOT) is not + the same as $(PROJ_SRC_ROOT), will completely clean the + $(PROJ_OBJ_ROOT) directory by removing its content entirely and + reconfiguring the directory. This returns the $(PROJ_OBJ_ROOT) + directory to a completely fresh state. All content in the directory except + configured files and top-level makefiles will be lost.

    +

    Use with caution.

    +
    + + + +
    +

    This target will generate a TAGS file in the top-level source + directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file + provides an index of symbol definitions so that the editor can jump you to the + definition quickly.

    +
    + + + +
    +

    This target is the opposite of the install target. It removes the + header, library and executable files from the installation directories. Note + that the directories themselves are not removed because it is not guaranteed + that LLVM is the only thing installing there (e.g. --prefix=/usr).

    +
    + + + + +
    +

    Variables are used to tell the LLVM Makefile System what to do and to + obtain information from it. Variables are also used internally by the LLVM + Makefile System. Variable names that contain only the upper case alphabetic + letters and underscore are intended for use by the end user. All other + variables are internal to the LLVM Makefile System and should not be relied + upon nor modified. The sections below describe how to use the LLVM Makefile + variables.

    +
    + + + +
    +

    Variables listed in the table below should be set before the + inclusion of $(LEVEL)/Makefile.common. + These variables provide input to the LLVM make system that tell it what to do + for the current directory.

    +
    +
    BUILD_ARCHIVE
    +
    If set to any value, causes an archive (.a) library to be built.
    +
    BUILT_SOURCES
    +
    Specifies a set of source files that are generated from other source + files. These sources will be built before any other target processing to + ensure they are present.
    +
    BYTECODE_LIBRARY
    +
    If set to any value, causes a bitcode library (.bc) to be built.
    +
    CONFIG_FILES
    +
    Specifies a set of configuration files to be installed.
    +
    DIRS
    +
    Specifies a set of directories, usually children of the current + directory, that should also be made using the same goal. These directories + will be built serially.
    +
    DISABLE_AUTO_DEPENDENCIES
    +
    If set to any value, causes the makefiles to not automatically + generate dependencies when running the compiler. Use of this feature is + discouraged and it may be removed at a later date.
    +
    DONT_BUILD_RELINKED
    +
    If set to any value, causes a relinked library (.o) not to be built. By + default, libraries are built as re-linked since most LLVM libraries are + needed in their entirety and re-linked libraries will be linked more quickly + than equivalent archive libraries.
    +
    ENABLE_OPTIMIZED
    +
    If set to any value, causes the build to generate optimized objects, + libraries and executables. This alters the flags specified to the compilers + and linkers. Generally debugging won't be a fun experience with an optimized + build.
    +
    ENABLE_PROFILING
    +
    If set to any value, causes the build to generate both optimized and + profiled objects, libraries and executables. This alters the flags specified + to the compilers and linkers to ensure that profile data can be collected + from the tools built. Use the gprof tool to analyze the output from + the profiled tools (gmon.out).
    +
    DISABLE_ASSERTIONS
    +
    If set to any value, causes the build to disable assertions, even if + building a release or profile build. This will exclude all assertion check + code from the build. LLVM will execute faster, but with little help when + things go wrong.
    +
    EXPERIMENTAL_DIRS
    +
    Specify a set of directories that should be built, but if they fail, it + should not cause the build to fail. Note that this should only be used + temporarily while code is being written.
    +
    EXPORTED_SYMBOL_FILE
    +
    Specifies the name of a single file that contains a list of the + symbols to be exported by the linker. One symbol per line.
    +
    EXPORTED_SYMBOL_LIST
    +
    Specifies a set of symbols to be exported by the linker.
    +
    EXTRA_DIST
    +
    Specifies additional files that should be distributed with LLVM. All + source files, all built sources, all Makefiles, and most documentation files + will be automatically distributed. Use this variable to distribute any + files that are not automatically distributed.
    +
    KEEP_SYMBOLS
    +
    If set to any value, specifies that when linking executables the + makefiles should retain debug symbols in the executable. Normally, symbols + are stripped from the executable.
    +
    LEVEL(required)
    +
    Specify the level of nesting from the top level. This variable must be + set in each makefile as it is used to find the top level and thus the other + makefiles.
    +
    LIBRARYNAME
    +
    Specify the name of the library to be built. (Required For + Libraries)
    +
    LINK_COMPONENTS
    +
    When specified for building a tool, the value of this variable will be + passed to the llvm-config tool to generate a link line for the + tool. Unlike USEDLIBS and LLVMLIBS, not all libraries need + to be specified. The llvm-config tool will figure out the library + dependencies and add any libraries that are needed. The USEDLIBS + variable can still be used in conjunction with LINK_COMPONENTS so + that additional project-specific libraries can be linked with the LLVM + libraries specified by LINK_COMPONENTS
    +
    LINK_LIBS_IN_SHARED
    +
    By default, shared library linking will ignore any libraries specified + with the LLVMLIBS or USEDLIBS. + This prevents shared libs from including things that will be in the LLVM + tool the shared library will be loaded into. However, sometimes it is useful + to link certain libraries into your shared library and this option enables + that feature.
    +
    LLVMLIBS
    +
    Specifies the set of libraries from the LLVM $(ObjDir) that will be + linked into the tool or library.
    +
    LOADABLE_MODULE
    +
    If set to any value, causes the shared library being built to also be + a loadable module. Loadable modules can be opened with the dlopen() function + and searched with dlsym (or the operating system's equivalent). Note that + setting this variable without also setting SHARED_LIBRARY will have + no effect.
    +
    MODULE_NAME
    +
    Specifies the name of a bitcode module to be created. A bitcode + module can be specified in conjunction with other kinds of library builds + or by itself. It constructs from the sources a single linked bitcode + file.
    +
    NO_INSTALL
    +
    Specifies that the build products of the directory should not be + installed but should be built even if the install target is given. + This is handy for directories that build libraries or tools that are only + used as part of the build process, such as code generators (e.g. + tblgen).
    +
    OPTIONAL_DIRS
    +
    Specify a set of directories that may be built, if they exist, but its + not an error for them not to exist.
    +
    PARALLEL_DIRS
    +
    Specify a set of directories to build recursively and in parallel if + the -j option was used with make.
    +
    SHARED_LIBRARY
    +
    If set to any value, causes a shared library (.so) to be built in + addition to any other kinds of libraries. Note that this option will cause + all source files to be built twice: once with options for position + independent code and once without. Use it only where you really need a + shared library.
    +
    SOURCES(optional)
    +
    Specifies the list of source files in the current directory to be + built. Source files of any type may be specified (programs, documentation, + config files, etc.). If not specified, the makefile system will infer the + set of source files from the files present in the current directory.
    +
    SUFFIXES
    +
    Specifies a set of filename suffixes that occur in suffix match rules. + Only set this if your local Makefile specifies additional suffix + match rules.
    +
    TARGET
    +
    Specifies the name of the LLVM code generation target that the + current directory builds. Setting this variable enables additional rules to + build .inc files from .td files.
    +
    TESTSUITE
    +
    Specifies the directory of tests to run in llvm/test.
    +
    TOOLNAME
    +
    Specifies the name of the tool that the current directory should + build.
    +
    TOOL_VERBOSE
    +
    Implies VERBOSE and also tells each tool invoked to be verbose. This is + handy when you're trying to see the sub-tools invoked by each tool invoked + by the makefile. For example, this will pass -v to the GCC + compilers which causes it to print out the command lines it uses to invoke + sub-tools (compiler, assembler, linker).
    +
    USEDLIBS
    +
    Specifies the list of project libraries that will be linked into the + tool or library.
    +
    VERBOSE
    +
    Tells the Makefile system to produce detailed output of what it is doing + instead of just summary comments. This will generate a LOT of output.
    +
    +
    + + + +
    +

    Override variables can be used to override the default + values provided by the LLVM makefile system. These variables can be set in + several ways:

    +
      +
    • In the environment (e.g. setenv, export) -- not recommended.
    • +
    • On the make command line -- recommended.
    • +
    • On the configure command line
    • +
    • In the Makefile (only after the inclusion of $(LEVEL)/Makefile.common).
    • +
    +

    The override variables are given below:

    +
    +
    AR (defaulted)
    +
    Specifies the path to the ar tool.
    +
    PROJ_OBJ_DIR
    +
    The directory into which the products of build rules will be placed. + This might be the same as + PROJ_SRC_DIR but typically is + not.
    +
    PROJ_SRC_DIR
    +
    The directory which contains the source files to be built.
    +
    BZIP2(configured)
    +
    The path to the bzip2 tool.
    +
    CC(configured)
    +
    The path to the 'C' compiler.
    +
    CFLAGS
    +
    Additional flags to be passed to the 'C' compiler.
    +
    CXX
    +
    Specifies the path to the C++ compiler.
    +
    CXXFLAGS
    +
    Additional flags to be passed to the C++ compiler.
    +
    DATE(configured)
    +
    Specifies the path to the date program or any program that can + generate the current date and time on its standard output
    +
    DOT(configured)
    +
    Specifies the path to the dot tool or false if there + isn't one.
    +
    ECHO(configured)
    +
    Specifies the path to the echo tool for printing output.
    +
    EXEEXT(configured)
    +
    Provides the extension to be used on executables built by the makefiles. + The value may be empty on platforms that do not use file extensions for + executables (e.g. Unix).
    +
    INSTALL(configured)
    +
    Specifies the path to the install tool.
    +
    LDFLAGS(configured)
    +
    Allows users to specify additional flags to pass to the linker.
    +
    LIBS(configured)
    +
    The list of libraries that should be linked with each tool.
    +
    LIBTOOL(configured)
    +
    Specifies the path to the libtool tool. This tool is renamed + mklib by the configure script and always located in the +
    LLVMAS(defaulted)
    +
    Specifies the path to the llvm-as tool.
    +
    LLVMGCC(defaulted)
    +
    Specifies the path to the LLVM version of the GCC 'C' Compiler
    +
    LLVMGXX(defaulted)
    +
    Specifies the path to the LLVM version of the GCC C++ Compiler
    +
    LLVMLD(defaulted)
    +
    Specifies the path to the LLVM bitcode linker tool
    +
    LLVM_OBJ_ROOT(configured) +
    +
    Specifies the top directory into which the output of the build is + placed.
    +
    LLVM_SRC_ROOT(configured) +
    +
    Specifies the top directory in which the sources are found.
    +
    LLVM_TARBALL_NAME + (configured)
    +
    Specifies the name of the distribution tarball to create. This is + configured from the name of the project and its version number.
    +
    MKDIR(defaulted)
    +
    Specifies the path to the mkdir tool that creates + directories.
    +
    PLATFORMSTRIPOPTS
    +
    The options to provide to the linker to specify that a stripped (no + symbols) executable should be built.
    +
    RANLIB(defaulted)
    +
    Specifies the path to the ranlib tool.
    +
    RM(defaulted)
    +
    Specifies the path to the rm tool.
    +
    SED(defaulted)
    +
    Specifies the path to the sed tool.
    +
    SHLIBEXT(configured)
    +
    Provides the filename extension to use for shared libraries.
    +
    TBLGEN(defaulted)
    +
    Specifies the path to the tblgen tool.
    +
    TAR(defaulted)
    +
    Specifies the path to the tar tool.
    +
    ZIP(defaulted)
    +
    Specifies the path to the zip tool.
    +
    +
    + + + +
    +

    Variables listed in the table below can be used by the user's Makefile but + should not be changed. Changing the value will generally cause the build to go + wrong, so don't do it.

    +
    +
    bindir
    +
    The directory into which executables will ultimately be installed. This + value is derived from the --prefix option given to + configure.
    +
    BuildMode
    +
    The name of the type of build being performed: Debug, Release, or + Profile
    +
    bytecode_libdir
    +
    The directory into which bitcode libraries will ultimately be + installed. This value is derived from the --prefix option given to + configure.
    +
    ConfigureScriptFLAGS
    +
    Additional flags given to the configure script when + reconfiguring.
    +
    DistDir
    +
    The current directory for which a distribution copy is being + made.
    +
    Echo
    +
    The LLVM Makefile System output command. This provides the + llvm[n] prefix and starts with @ so the command itself is not + printed by make.
    +
    EchoCmd
    +
    Same as Echo but without the leading @. +
    +
    includedir
    +
    The directory into which include files will ultimately be installed. + This value is derived from the --prefix option given to + configure.
    +
    libdir
    +
    The directory into which native libraries will ultimately be installed. + This value is derived from the --prefix option given to + configure.
    +
    LibDir
    +
    The configuration specific directory into which libraries are placed + before installation.
    +
    MakefileConfig
    +
    Full path of the Makefile.config file.
    +
    MakefileConfigIn
    +
    Full path of the Makefile.config.in file.
    +
    ObjDir
    +
    The configuration and directory specific directory where build objects + (compilation results) are placed.
    +
    SubDirs
    +
    The complete list of sub-directories of the current directory as + specified by other variables.
    +
    Sources
    +
    The complete list of source files.
    +
    sysconfdir
    +
    The directory into which configuration files will ultimately be + installed. This value is derived from the --prefix option given to + configure.
    +
    ToolDir
    +
    The configuration specific directory into which executables are placed + before they are installed.
    +
    TopDistDir
    +
    The top most directory into which the distribution files are copied. +
    +
    Verb
    +
    Use this as the first thing on your build script lines to enable or + disable verbose mode. It expands to either an @ (quiet mode) or nothing + (verbose mode).
    +
    +
    + + + +
    +

    Variables listed below are used by the LLVM Makefile System + and considered internal. You should not use these variables under any + circumstances.

    +

    + Archive + AR.Flags + BaseNameSources + BCCompile.C + BCCompile.CXX + BCLinkLib + C.Flags + Compile.C + CompileCommonOpts + Compile.CXX + ConfigStatusScript + ConfigureScript + CPP.Flags + CPP.Flags + CXX.Flags + DependFiles + DestArchiveLib + DestBitcodeLib + DestModule + DestRelinkedLib + DestSharedLib + DestTool + DistAlways + DistCheckDir + DistCheckTop + DistFiles + DistName + DistOther + DistSources + DistSubDirs + DistTarBZ2 + DistTarGZip + DistZip + ExtraLibs + FakeSources + INCFiles + InternalTargets + LD.Flags + LibName.A + LibName.BC + LibName.LA + LibName.O + LibTool.Flags + Link + LinkModule + LLVMLibDir + LLVMLibsOptions + LLVMLibsPaths + LLVMToolDir + LLVMUsedLibs + LocalTargets + LTCompile.C + LTCompile.CXX + LTInstall + Module + ObjectsBC + ObjectsLO + ObjectsO + ObjMakefiles + ParallelTargets + PreConditions + ProjLibsOptions + ProjLibsPaths + ProjUsedLibs + Ranlib + RecursiveTargets + Relink + SrcMakefiles + Strip + StripWarnMsg + TableGen + TDFiles + ToolBuildPath + TopLevelTargets + UserTargets +

    +
    + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Reid Spencer
    + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + Index: llvm-www/releases/2.5/docs/Passes.html diff -c /dev/null llvm-www/releases/2.5/docs/Passes.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/Passes.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,1970 ---- + + + + LLVM's Analysis and Transform Passes + + + + + + + +
    LLVM's Analysis and Transform Passes
    + +
      +
    1. Introduction
    2. +
    3. Analysis Passes +
    4. Transform Passes
    5. +
    6. Utility Passes
    7. +
    + +
    +

    Written by Reid Spencer + and Gordon Henriksen

    +
    + + + +
    +

    This document serves as a high level summary of the optimization features + that LLVM provides. Optimizations are implemented as Passes that traverse some + portion of a program to either collect information or transform the program. + The table below divides the passes that LLVM provides into three categories. + Analysis passes compute information that other passes can use or for debugging + or program visualization purposes. Transform passes can use (or invalidate) + the analysis passes. Transform passes all mutate the program in some way. + Utility passes provides some utility but don't otherwise fit categorization. + For example passes to extract functions to bitcode or write a module to + bitcode are neither analysis nor transform passes. +

    The table below provides a quick summary of each pass and links to the more + complete pass description later in the document.

    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ANALYSIS PASSES
    OptionName
    -aa-evalExhaustive Alias Analysis Precision Evaluator
    -anders-aaAndersen's Interprocedural Alias Analysis
    -basicaaBasic Alias Analysis (default AA impl)
    -basiccgBasic CallGraph Construction
    -basicvnBasic Value Numbering (default GVN impl)
    -codegenprepareOptimize for code generation
    -count-aaCount Alias Analysis Query Responses
    -debug-aaAA use debugger
    -domfrontierDominance Frontier Construction
    -domtreeDominator Tree Construction
    -dot-callgraphPrint Call Graph to 'dot' file
    -dot-cfgPrint CFG of function to 'dot' file
    -dot-cfg-onlyPrint CFG of function to 'dot' file (with no function bodies)
    -globalsmodref-aaSimple mod/ref analysis for globals
    -instcountCounts the various types of Instructions
    -intervalsInterval Partition Construction
    -load-vnLoad Value Numbering
    -loopsNatural Loop Construction
    -memdepMemory Dependence Analysis
    -no-aaNo Alias Analysis (always returns 'may' alias)
    -no-profileNo Profile Information
    -postdomfrontierPost-Dominance Frontier Construction
    -postdomtreePost-Dominator Tree Construction
    -print-alias-setsAlias Set Printer
    -print-callgraphPrint a call graph
    -print-callgraph-sccsPrint SCCs of the Call Graph
    -print-cfg-sccsPrint SCCs of each function CFG
    -print-externalfnconstantsPrint external fn callsites passed constants
    -print-functionPrint function to stderr
    -print-modulePrint module to stderr
    -print-used-typesFind Used Types
    -profile-loaderLoad profile information from llvmprof.out
    -scalar-evolutionScalar Evolution Analysis
    -targetdataTarget Data Layout
    TRANSFORM PASSES
    OptionName
    -adceAggressive Dead Code Elimination
    -argpromotionPromote 'by reference' arguments to scalars
    -block-placementProfile Guided Basic Block Placement
    -break-crit-edgesBreak critical edges in CFG
    -codegenpreparePrepare a function for code generation
    -condpropConditional Propagation
    -constmergeMerge Duplicate Global Constants
    -constpropSimple constant propagation
    -dceDead Code Elimination
    -deadargelimDead Argument Elimination
    -deadtypeelimDead Type Elimination
    -dieDead Instruction Elimination
    -dseDead Store Elimination
    -gcseGlobal Common Subexpression Elimination
    -globaldceDead Global Elimination
    -globaloptGlobal Variable Optimizer
    -gvnGlobal Value Numbering
    -gvnpreGlobal Value Numbering/Partial Redundancy Elimination
    -indmemremIndirect Malloc and Free Removal
    -indvarsCanonicalize Induction Variables
    -inlineFunction Integration/Inlining
    -insert-block-profilingInsert instrumentation for block profiling
    -insert-edge-profilingInsert instrumentation for edge profiling
    -insert-function-profilingInsert instrumentation for function profiling
    -insert-null-profiling-rsMeasure profiling framework overhead
    -insert-rs-profiling-frameworkInsert random sampling instrumentation framework
    -instcombineCombine redundant instructions
    -internalizeInternalize Global Symbols
    -ipconstpropInterprocedural constant propagation
    -ipsccpInterprocedural Sparse Conditional Constant Propagation
    -jump-threadingThread control through conditional blocks
    -lcssaLoop-Closed SSA Form Pass
    -licmLoop Invariant Code Motion
    -loop-deletionDead Loop Deletion Pass
    -loop-extractExtract loops into new functions
    -loop-extract-singleExtract at most one loop into a new function
    -loop-index-splitIndex Split Loops
    -loop-reduceLoop Strength Reduction
    -loop-rotateRotate Loops
    -loop-unrollUnroll loops
    -loop-unswitchUnswitch loops
    -loopsimplifyCanonicalize natural loops
    -lowerallocsLower allocations from instructions to calls
    -lowerinvokeLower invoke and unwind, for unwindless code generators
    -lowersetjmpLower Set Jump
    -lowerswitchLower SwitchInst's to branches
    -mem2regPromote Memory to Register
    -memcpyoptOptimize use of memcpy and friends
    -mergereturnUnify function exit nodes
    -predsimplifyPredicate Simplifier
    -prune-ehRemove unused exception handling info
    -raiseallocsRaise allocations from calls to instructions
    -reassociateReassociate expressions
    -reg2memDemote all values to stack slots
    -scalarreplScalar Replacement of Aggregates
    -sccpSparse Conditional Constant Propagation
    -simplify-libcallsSimplify well-known library calls
    -simplifycfgSimplify the CFG
    -stripStrip all symbols from a module
    -strip-dead-prototypesRemove unused function declarations
    -sretpromotionPromote sret arguments
    -tailcallelimTail Call Elimination
    -tailduplicateTail Duplication
    UTILITY PASSES
    OptionName
    -deadarghaX0rDead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE)
    -extract-blocksExtract Basic Blocks From Module (for bugpoint use)
    -preverifyPreliminary module verification
    -verifyModule Verifier
    -view-cfgView CFG of function
    -view-cfg-onlyView CFG of function (with no function bodies)
    +
    + + + +
    +

    This section describes the LLVM Analysis Passes.

    +
    + + + +
    +

    This is a simple N^2 alias analysis accuracy evaluator. + Basically, for each function in the program, it simply queries to see how the + alias analysis implementation answers alias queries between each pair of + pointers in the function.

    + +

    This is inspired and adapted from code by: Naveen Neelakantam, Francesco + Spadini, and Wojciech Stryjewski.

    +
    + + + +
    +

    + This is an implementation of Andersen's interprocedural alias + analysis +

    + +

    + In pointer analysis terms, this is a subset-based, flow-insensitive, + field-sensitive, and context-insensitive algorithm pointer algorithm. +

    + +

    + This algorithm is implemented as three stages: +

    + +
      +
    1. Object identification.
    2. +
    3. Inclusion constraint identification.
    4. +
    5. Offline constraint graph optimization.
    6. +
    7. Inclusion constraint solving.
    8. +
    + +

    + The object identification stage identifies all of the memory objects in the + program, which includes globals, heap allocated objects, and stack allocated + objects. +

    + +

    + The inclusion constraint identification stage finds all inclusion constraints + in the program by scanning the program, looking for pointer assignments and + other statements that effect the points-to graph. For a statement like + A = B, this statement is processed to + indicate that A can point to anything that B can point + to. Constraints can handle copies, loads, and stores, and address taking. +

    + +

    + The offline constraint graph optimization portion includes offline variable + substitution algorithms intended to computer pointer and location + equivalences. Pointer equivalences are those pointers that will have the + same points-to sets, and location equivalences are those variables that + always appear together in points-to sets. +

    + +

    + The inclusion constraint solving phase iteratively propagates the inclusion + constraints until a fixed point is reached. This is an O(n??) + algorithm. +

    + +

    + Function constraints are handled as if they were structs with X + fields. Thus, an access to argument X of function Y is + an access to node index getNode(Y) + X. + This representation allows handling of indirect calls without any issues. To + wit, an indirect call Y(a,b) is + equivalent to *(Y + 1) = a, *(Y + 2) = + b. The return node for a function F is always + located at getNode(F) + CallReturnPos. The arguments + start at getNode(F) + CallArgPos. +

    +
    + + + +
    +

    + This is the default implementation of the Alias Analysis interface + that simply implements a few identities (two different globals cannot alias, + etc), but otherwise does no analysis. +

    +
    + + + +
    +

    Yet to be written.

    +
    + + + +
    +

    + This is the default implementation of the ValueNumbering + interface. It walks the SSA def-use chains to trivially identify + lexically identical expressions. This does not require any ahead of time + analysis, so it is a very fast default implementation. +

    +

    + The ValueNumbering analysis passes are mostly deprecated. They are only used + by the Global Common Subexpression Elimination pass, which + is deprecated by the Global Value Numbering pass (which + does its value numbering on its own). +

    +
    + + + +
    +

    + This pass munges the code in the input function to better prepare it for + SelectionDAG-based code generation. This works around limitations in it's + basic-block-at-a-time approach. It should eventually be removed. +

    +
    + + + +
    +

    + A pass which can be used to count how many alias queries + are being made and how the alias analysis implementation being used responds. +

    +
    + + + +
    +

    + This simple pass checks alias analysis users to ensure that if they + create a new value, they do not query AA without informing it of the value. + It acts as a shim over any other AA pass you want. +

    + +

    + Yes keeping track of every value in the program is expensive, but this is + a debugging pass. +

    +
    + + + +
    +

    + This pass is a simple dominator construction algorithm for finding forward + dominator frontiers. +

    +
    + + + +
    +

    + This pass is a simple dominator construction algorithm for finding forward + dominators. +

    +
    + + + +
    +

    + This pass, only available in opt, prints the call graph into a + .dot graph. This graph can then be processed with the "dot" tool + to convert it to postscript or some other suitable format. +

    +
    + + + +
    +

    + This pass, only available in opt, prints the control flow graph + into a .dot graph. This graph can then be processed with the + "dot" tool to convert it to postscript or some other suitable format. +

    +
    + + + +
    +

    + This pass, only available in opt, prints the control flow graph + into a .dot graph, omitting the function bodies. This graph can + then be processed with the "dot" tool to convert it to postscript or some + other suitable format. +

    +
    + + + +
    +

    + This simple pass provides alias and mod/ref information for global values + that do not have their address taken, and keeps track of whether functions + read or write memory (are "pure"). For this simple (but very common) case, + we can provide pretty accurate and useful information. +

    +
    + + + +
    +

    + This pass collects the count of all instructions and reports them +

    +
    + + + +
    +

    + This analysis calculates and represents the interval partition of a function, + or a preexisting interval partition. +

    + +

    + In this way, the interval partition may be used to reduce a flow graph down + to its degenerate single node interval partition (unless it is irreducible). +

    +
    + + + +
    +

    + This pass value numbers load and call instructions. To do this, it finds + lexically identical load instructions, and uses alias analysis to determine + which loads are guaranteed to produce the same value. To value number call + instructions, it looks for calls to functions that do not write to memory + which do not have intervening instructions that clobber the memory that is + read from. +

    + +

    + This pass builds off of another value numbering pass to implement value + numbering for non-load and non-call instructions. It uses Alias Analysis so + that it can disambiguate the load instructions. The more powerful these base + analyses are, the more powerful the resultant value numbering will be. +

    +
    + + + +
    +

    + This analysis is used to identify natural loops and determine the loop depth + of various nodes of the CFG. Note that the loops identified may actually be + several natural loops that share the same header node... not just a single + natural loop. +

    +
    + + + +
    +

    + An analysis that determines, for a given memory operation, what preceding + memory operations it depends on. It builds on alias analysis information, and + tries to provide a lazy, caching interface to a common kind of alias + information query. +

    +
    + + + +
    +

    + Always returns "I don't know" for alias queries. NoAA is unlike other alias + analysis implementations, in that it does not chain to a previous analysis. As + such it doesn't follow many of the rules that other alias analyses must. +

    +
    + + + +
    +

    + The default "no profile" implementation of the abstract + ProfileInfo interface. +

    +
    + + + +
    +

    + This pass is a simple post-dominator construction algorithm for finding + post-dominator frontiers. +

    +
    + + + +
    +

    + This pass is a simple post-dominator construction algorithm for finding + post-dominators. +

    +
    + + + +
    +

    Yet to be written.

    +
    + + + +
    +

    + This pass, only available in opt, prints the call graph to + standard output in a human-readable form. +

    +
    + + + +
    +

    + This pass, only available in opt, prints the SCCs of the call + graph to standard output in a human-readable form. +

    +
    + + + +
    +

    + This pass, only available in opt, prints the SCCs of each + function CFG to standard output in a human-readable form. +

    +
    + + + +
    +

    + This pass, only available in opt, prints out call sites to + external functions that are called with constant arguments. This can be + useful when looking for standard library functions we should constant fold + or handle in alias analyses. +

    +
    + + + +
    +

    + The PrintFunctionPass class is designed to be pipelined with + other FunctionPasses, and prints out the functions of the module + as they are processed. +

    +
    + + + +
    +

    + This pass simply prints out the entire module when it is executed. +

    +
    + + + +
    +

    + This pass is used to seek out all of the types in use by the program. Note + that this analysis explicitly does not include types only used by the symbol + table. +

    + + + +
    +

    + A concrete implementation of profiling information that loads the information + from a profile dump file. +

    +
    + + + +
    +

    + The ScalarEvolution analysis can be used to analyze and + catagorize scalar expressions in loops. It specializes in recognizing general + induction variables, representing them with the abstract and opaque + SCEV class. Given this analysis, trip counts of loops and other + important properties can be obtained. +

    + +

    + This analysis is primarily useful for induction variable substitution and + strength reduction. +

    +
    + + + +
    +

    Provides other passes access to information on how the size and alignment + required by the the target ABI for various data types.

    +
    + + + +
    +

    This section describes the LLVM Transform Passes.

    +
    + + + +
    +

    ADCE aggressively tries to eliminate code. This pass is similar to + DCE but it assumes that values are dead until proven + otherwise. This is similar to SCCP, except applied to + the liveness of values.

    +
    + + + +
    +

    + This pass promotes "by reference" arguments to be "by value" arguments. In + practice, this means looking for internal functions that have pointer + arguments. If it can prove, through the use of alias analysis, that an + argument is *only* loaded, then it can pass the value into the function + instead of the address of the value. This can cause recursive simplification + of code and lead to the elimination of allocas (especially in C++ template + code like the STL). +

    + +

    + This pass also handles aggregate arguments that are passed into a function, + scalarizing them if the elements of the aggregate are only loaded. Note that + it refuses to scalarize aggregates which would require passing in more than + three operands to the function, because passing thousands of operands for a + large array or structure is unprofitable! +

    + +

    + Note that this transformation could also be done for arguments that are only + stored to (returning the value instead), but does not currently. This case + would be best handled when and if LLVM starts supporting multiple return + values from functions. +

    +
    + + + +
    +

    This pass is a very simple profile guided basic block placement algorithm. + The idea is to put frequently executed blocks together at the start of the + function and hopefully increase the number of fall-through conditional + branches. If there is no profile information for a particular function, this + pass basically orders blocks in depth-first order.

    +
    + + + +
    +

    + Break all of the critical edges in the CFG by inserting a dummy basic block. + It may be "required" by passes that cannot deal with critical edges. This + transformation obviously invalidates the CFG, but can update forward dominator + (set, immediate dominators, tree, and frontier) information. +

    +
    + + + +
    + This pass munges the code in the input function to better prepare it for + SelectionDAG-based code generation. This works around limitations in it's + basic-block-at-a-time approach. It should eventually be removed. +
    + + + +
    +

    This pass propagates information about conditional expressions through the + program, allowing it to eliminate conditional branches in some cases.

    +
    + + + +
    +

    + Merges duplicate global constants together into a single constant that is + shared. This is useful because some passes (ie TraceValues) insert a lot of + string constants into the program, regardless of whether or not an existing + string is available. +

    +
    + + + +
    +

    This file implements constant propagation and merging. It looks for + instructions involving only constant operands and replaces them with a + constant value instead of an instruction. For example:

    +
    add i32 1, 2
    +

    becomes

    +
    i32 3
    +

    NOTE: this pass has a habit of making definitions be dead. It is a good + idea to to run a DIE (Dead Instruction Elimination) pass + sometime after running this pass.

    +
    + + + +
    +

    + Dead code elimination is similar to dead instruction + elimination, but it rechecks instructions that were used by removed + instructions to see if they are newly dead. +

    +
    + + + +
    +

    + This pass deletes dead arguments from internal functions. Dead argument + elimination removes arguments which are directly dead, as well as arguments + only passed into function calls as dead arguments of other functions. This + pass also deletes dead arguments in a similar way. +

    + +

    + This pass is often useful as a cleanup pass to run after aggressive + interprocedural passes, which add possibly-dead arguments. +

    +
    + + + +
    +

    + This pass is used to cleanup the output of GCC. It eliminate names for types + that are unused in the entire translation unit, using the find used types pass. +

    +
    + + + +
    +

    + Dead instruction elimination performs a single pass over the function, + removing instructions that are obviously dead. +

    +
    + + + +
    +

    + A trivial dead store elimination that only considers basic-block local + redundant stores. +

    +
    + + + +
    +

    + This pass is designed to be a very quick global transformation that + eliminates global common subexpressions from a function. It does this by + using an existing value numbering analysis pass to identify the common + subexpressions, eliminating them when possible. +

    +

    + This pass is deprecated by the Global Value Numbering pass + (which does a better job with its own value numbering). +

    +
    + + + +
    +

    + This transform is designed to eliminate unreachable internal globals from the + program. It uses an aggressive algorithm, searching out globals that are + known to be alive. After it finds all of the globals which are needed, it + deletes whatever is left over. This allows it to delete recursive chunks of + the program which are unreachable. +

    +
    + + + +
    +

    + This pass transforms simple global variables that never have their address + taken. If obviously true, it marks read/write globals as constant, deletes + variables only stored to, etc. +

    +
    + + + +
    +

    + This pass performs global value numbering to eliminate fully redundant + instructions. It also performs simple dead load elimination. +

    +

    + Note that this pass does the value numbering itself, it does not use the + ValueNumbering analysis passes. +

    +
    + + + +
    +

    + This pass performs a hybrid of global value numbering and partial redundancy + elimination, known as GVN-PRE. It performs partial redundancy elimination on + values, rather than lexical expressions, allowing a more comprehensive view + the optimization. It replaces redundant values with uses of earlier + occurences of the same value. While this is beneficial in that it eliminates + unneeded computation, it also increases register pressure by creating large + live ranges, and should be used with caution on platforms that are very + sensitive to register pressure. +

    +

    + Note that this pass does the value numbering itself, it does not use the + ValueNumbering analysis passes. +

    +
    + + + +
    +

    + This pass finds places where memory allocation functions may escape into + indirect land. Some transforms are much easier (aka possible) only if free + or malloc are not called indirectly. +

    + +

    + Thus find places where the address of memory functions are taken and construct + bounce functions with direct calls of those functions. +

    +
    + + + +
    +

    + This transformation analyzes and transforms the induction variables (and + computations derived from them) into simpler forms suitable for subsequent + analysis and transformation. +

    + +

    + This transformation makes the following changes to each loop with an + identifiable induction variable: +

    + +
      +
    1. All loops are transformed to have a single canonical + induction variable which starts at zero and steps by one.
    2. +
    3. The canonical induction variable is guaranteed to be the first PHI node + in the loop header block.
    4. +
    5. Any pointer arithmetic recurrences are raised to use array + subscripts.
    6. +
    + +

    + If the trip count of a loop is computable, this pass also makes the following + changes: +

    + +
      +
    1. The exit condition for the loop is canonicalized to compare the + induction value against the exit value. This turns loops like: +
      for (i = 7; i*i < 1000; ++i)
      + into +
      for (i = 0; i != 25; ++i)
    2. +
    3. Any use outside of the loop of an expression derived from the indvar + is changed to compute the derived value outside of the loop, eliminating + the dependence on the exit value of the induction variable. If the only + purpose of the loop is to compute the exit value of some derived + expression, this transformation will make the loop dead.
    4. +
    + +

    + This transformation should be followed by strength reduction after all of the + desired loop transformations have been performed. Additionally, on targets + where it is profitable, the loop could be transformed to count down to zero + (the "do loop" optimization). +

    +
    + + + +
    +

    + Bottom-up inlining of functions into callees. +

    +
    + + + +
    +

    + This pass instruments the specified program with counters for basic block + profiling, which counts the number of times each basic block executes. This + is the most basic form of profiling, which can tell which blocks are hot, but + cannot reliably detect hot paths through the CFG. +

    + +

    + Note that this implementation is very na??ve. Control equivalent regions of + the CFG should not require duplicate counters, but it does put duplicate + counters in. +

    +
    + + + +
    +

    + This pass instruments the specified program with counters for edge profiling. + Edge profiling can give a reasonable approximation of the hot paths through a + program, and is used for a wide variety of program transformations. +

    + +

    + Note that this implementation is very na??ve. It inserts a counter for + every edge in the program, instead of using control flow information + to prune the number of counters inserted. +

    +
    + + + +
    +

    + This pass instruments the specified program with counters for function + profiling, which counts the number of times each function is called. +

    +
    + + + +
    +

    + The basic profiler that does nothing. It is the default profiler and thus + terminates RSProfiler chains. It is useful for measuring + framework overhead. +

    +
    + + + +
    +

    + The second stage of the random-sampling instrumentation framework, duplicates + all instructions in a function, ignoring the profiling code, then connects the + two versions together at the entry and at backedges. At each connection point + a choice is made as to whether to jump to the profiled code (take a sample) or + execute the unprofiled code. +

    + +

    + After this pass, it is highly recommended to runmem2reg + and adce. instcombine, + load-vn, gdce, and + dse also are good to run afterwards. +

    +
    + + + +
    +

    + Combine instructions to form fewer, simple + instructions. This pass does not modify the CFG This pass is where algebraic + simplification happens. +

    + +

    + This pass combines things like: +

    + +
    %Y = add i32 %X, 1
    + %Z = add i32 %Y, 1
    + +

    + into: +

    + +
    %Z = add i32 %X, 2
    + +

    + This is a simple worklist driven algorithm. +

    + +

    + This pass guarantees that the following canonicalizations are performed on + the program: +

    + +
      +
    • If a binary operator has a constant operand, it is moved to the right- + hand side.
    • +
    • Bitwise operators with constant operands are always grouped so that + shifts are performed first, then ors, then + ands, then xors.
    • +
    • Compare instructions are converted from <, + >, ???, or ??? to + = or ??? if possible.
    • +
    • All cmp instructions on boolean values are replaced with + logical operations.
    • +
    • add X, X is represented as + mul X, 2 ??? shl X, 1
    • +
    • Multiplies with a constant power-of-two argument are transformed into + shifts.
    • +
    • ??? etc.
    • +
    +
    + + + +
    +

    + This pass loops over all of the functions in the input module, looking for a + main function. If a main function is found, all other functions and all + global variables with initializers are marked as internal. +

    +
    + + + +
    +

    + This pass implements an extremely simple interprocedural constant + propagation pass. It could certainly be improved in many different ways, + like using a worklist. This pass makes arguments dead, but does not remove + them. The existing dead argument elimination pass should be run after this + to clean up the mess. +

    +
    + + + +
    +

    + An interprocedural variant of Sparse Conditional Constant + Propagation. +

    +
    + + + +
    +

    + Jump threading tries to find distinct threads of control flow running through + a basic block. This pass looks at blocks that have multiple predecessors and + multiple successors. If one or more of the predecessors of the block can be + proven to always cause a jump to one of the successors, we forward the edge + from the predecessor to the successor by duplicating the contents of this + block. +

    +

    + An example of when this can occur is code like this: +

    + +
    if () { ...
    +   X = 4;
    + }
    + if (X < 3) {
    + +

    + In this case, the unconditional branch at the end of the first if can be + revectored to the false side of the second if. +

    +
    + + + +
    +

    + This pass transforms loops by placing phi nodes at the end of the loops for + all values that are live across the loop boundary. For example, it turns + the left into the right code: +

    + +
    for (...)                for (...)
    +   if (c)                   if (c)
    +     X1 = ...                 X1 = ...
    +   else                     else
    +     X2 = ...                 X2 = ...
    +   X3 = phi(X1, X2)         X3 = phi(X1, X2)
    + ... = X3 + 4              X4 = phi(X3)
    +                           ... = X4 + 4
    + +

    + This is still valid LLVM; the extra phi nodes are purely redundant, and will + be trivially eliminated by InstCombine. The major benefit of + this transformation is that it makes many other loop optimizations, such as + LoopUnswitching, simpler. +

    +
    + + + +
    +

    + This pass performs loop invariant code motion, attempting to remove as much + code from the body of a loop as possible. It does this by either hoisting + code into the preheader block, or by sinking code to the exit blocks if it is + safe. This pass also promotes must-aliased memory locations in the loop to + live in registers, thus hoisting and sinking "invariant" loads and stores. +

    + +

    + This pass uses alias analysis for two purposes: +

    + +
      +
    • Moving loop invariant loads and calls out of loops. If we can determine + that a load or call inside of a loop never aliases anything stored to, + we can hoist it or sink it like any other instruction.
    • +
    • Scalar Promotion of Memory - If there is a store instruction inside of + the loop, we try to move the store to happen AFTER the loop instead of + inside of the loop. This can only happen if a few conditions are true: +
        +
      • The pointer stored through is loop invariant.
      • +
      • There are no stores or loads in the loop which may alias + the pointer. There are no calls in the loop which mod/ref the + pointer.
      • +
      + If these conditions are true, we can promote the loads and stores in the + loop of the pointer to use a temporary alloca'd variable. We then use + the mem2reg functionality to construct the appropriate SSA form for the + variable.
    • +
    +
    + + +
    +

    + This file implements the Dead Loop Deletion Pass. This pass is responsible + for eliminating loops with non-infinite computable trip counts that have no + side effects or volatile instructions, and do not contribute to the + computation of the function's return value. +

    +
    + + + +
    +

    + A pass wrapper around the ExtractLoop() scalar transformation to + extract each top-level loop into its own new function. If the loop is the + only loop in a given function, it is not touched. This is a pass most + useful for debugging via bugpoint. +

    +
    + + + +
    +

    + Similar to Extract loops into new functions, + this pass extracts one natural loop from the program into a function if it + can. This is used by bugpoint. +

    +
    + + + +
    +

    + This pass divides loop's iteration range by spliting loop such that each + individual loop is executed efficiently. +

    +
    + + + +
    +

    + This pass performs a strength reduction on array references inside loops that + have as one or more of their components the loop induction variable. This is + accomplished by creating a new value to hold the initial value of the array + access for the first iteration, and then creating a new GEP instruction in + the loop to increment the value by the appropriate amount. +

    +
    + + + +
    +

    A simple loop rotation transformation.

    +
    + + + +
    +

    + This pass implements a simple loop unroller. It works best when loops have + been canonicalized by the -indvars pass, + allowing it to determine the trip counts of loops easily. +

    +
    + + + +
    +

    + This pass transforms loops that contain branches on loop-invariant conditions + to have multiple loops. For example, it turns the left into the right code: +

    + +
    for (...)                  if (lic)
    +   A                          for (...)
    +   if (lic)                     A; B; C
    +     B                      else
    +   C                          for (...)
    +                                A; C
    + +

    + This can increase the size of the code exponentially (doubling it every time + a loop is unswitched) so we only unswitch if the resultant code will be + smaller than a threshold. +

    + +

    + This pass expects LICM to be run before it to hoist invariant conditions out + of the loop, to make the unswitching opportunity obvious. +

    +
    + + + +
    +

    + This pass performs several transformations to transform natural loops into a + simpler form, which makes subsequent analyses and transformations simpler and + more effective. +

    + +

    + Loop pre-header insertion guarantees that there is a single, non-critical + entry edge from outside of the loop to the loop header. This simplifies a + number of analyses and transformations, such as LICM. +

    + +

    + Loop exit-block insertion guarantees that all exit blocks from the loop + (blocks which are outside of the loop that have predecessors inside of the + loop) only have predecessors from inside of the loop (and are thus dominated + by the loop header). This simplifies transformations such as store-sinking + that are built into LICM. +

    + +

    + This pass also guarantees that loops will have exactly one backedge. +

    + +

    + Note that the simplifycfg pass will clean up blocks which are split out but + end up being unnecessary, so usage of this pass should not pessimize + generated code. +

    + +

    + This pass obviously modifies the CFG, but updates loop information and + dominator information. +

    +
    + + + +
    +

    + Turn malloc and free instructions into @malloc and + @free calls. +

    + +

    + This is a target-dependent tranformation because it depends on the size of + data types and alignment constraints. +

    +
    + + + +
    +

    + This transformation is designed for use by code generators which do not yet + support stack unwinding. This pass supports two models of exception handling + lowering, the 'cheap' support and the 'expensive' support. +

    + +

    + 'Cheap' exception handling support gives the program the ability to execute + any program which does not "throw an exception", by turning 'invoke' + instructions into calls and by turning 'unwind' instructions into calls to + abort(). If the program does dynamically use the unwind instruction, the + program will print a message then abort. +

    + +

    + 'Expensive' exception handling support gives the full exception handling + support to the program at the cost of making the 'invoke' instruction + really expensive. It basically inserts setjmp/longjmp calls to emulate the + exception handling as necessary. +

    + +

    + Because the 'expensive' support slows down programs a lot, and EH is only + used for a subset of the programs, it must be specifically enabled by the + -enable-correct-eh-support option. +

    + +

    + Note that after this pass runs the CFG is not entirely accurate (exceptional + control flow edges are not correct anymore) so only very simple things should + be done after the lowerinvoke pass has run (like generation of native code). + This should not be used as a general purpose "my LLVM-to-LLVM pass doesn't + support the invoke instruction yet" lowering pass. +

    +
    + + + +
    +

    + Lowers setjmp and longjmp to use the LLVM invoke and unwind + instructions as necessary. +

    + +

    + Lowering of longjmp is fairly trivial. We replace the call with a + call to the LLVM library function __llvm_sjljeh_throw_longjmp(). + This unwinds the stack for us calling all of the destructors for + objects allocated on the stack. +

    + +

    + At a setjmp call, the basic block is split and the setjmp + removed. The calls in a function that have a setjmp are converted to + invoke where the except part checks to see if it's a longjmp + exception and, if so, if it's handled in the function. If it is, then it gets + the value returned by the longjmp and goes to where the basic block + was split. invoke instructions are handled in a similar fashion with + the original except block being executed if it isn't a longjmp + except that is handled by that function. +

    +
    + + + +
    +

    + Rewrites switch instructions with a sequence of branches, which + allows targets to get away with not implementing the switch instruction until + it is convenient. +

    +
    + + + +
    +

    + This file promotes memory references to be register references. It promotes + alloca instructions which only have loads and + stores as uses. An alloca is transformed by using dominator + frontiers to place phi nodes, then traversing the function in + depth-first order to rewrite loads and stores as + appropriate. This is just the standard SSA construction algorithm to construct + "pruned" SSA form. +

    +
    + + + +
    +

    + This pass performs various transformations related to eliminating memcpy + calls, or transforming sets of stores into memset's. +

    +
    + + + +
    +

    + Ensure that functions have at most one ret instruction in them. + Additionally, it keeps track of which node is the new exit node of the CFG. +

    +
    + + + +
    +

    + Path-sensitive optimizer. In a branch where x == y, replace uses of + x with y. Permits further optimization, such as the + elimination of the unreachable call: +

    + +
    void test(int *p, int *q)
    + {
    +   if (p != q)
    +     return;
    + 
    +   if (*p != *q)
    +     foo(); // unreachable
    + }
    +
    + + + +
    +

    + This file implements a simple interprocedural pass which walks the call-graph, + turning invoke instructions into call instructions if and + only if the callee cannot throw an exception. It implements this as a + bottom-up traversal of the call-graph. +

    +
    + + + +
    +

    + Converts @malloc and @free calls to malloc and + free instructions. +

    +
    + + + +
    +

    + This pass reassociates commutative expressions in an order that is designed + to promote better constant propagation, GCSE, LICM, PRE, etc. +

    + +

    + For example: 4 + (x + 5) ??? x + (4 + 5) +

    + +

    + In the implementation of this algorithm, constants are assigned rank = 0, + function arguments are rank = 1, and other values are assigned ranks + corresponding to the reverse post order traversal of current function + (starting at 2), which effectively gives values in deep loops higher rank + than values not in loops. +

    +
    + + + +
    +

    + This file demotes all registers to memory references. It is intented to be + the inverse of -mem2reg. By converting to + load instructions, the only values live accross basic blocks are + alloca instructions and load instructions before + phi nodes. It is intended that this should make CFG hacking much + easier. To make later hacking easier, the entry block is split into two, such + that all introduced alloca instructions (and nothing else) are in the + entry block. +

    +
    + + + +
    +

    + The well-known scalar replacement of aggregates transformation. This + transform breaks up alloca instructions of aggregate type (structure + or array) into individual alloca instructions for each member if + possible. Then, if possible, it transforms the individual alloca + instructions into nice clean scalar SSA form. +

    + +

    + This combines a simple scalar replacement of aggregates algorithm with the mem2reg algorithm because often interact, + especially for C++ programs. As such, iterating between scalarrepl, + then mem2reg until we run out of things to + promote works well. +

    +
    + + + +
    +

    + Sparse conditional constant propagation and merging, which can be summarized + as: +

    + +
      +
    1. Assumes values are constant unless proven otherwise
    2. +
    3. Assumes BasicBlocks are dead unless proven otherwise
    4. +
    5. Proves values to be constant, and replaces them with constants
    6. +
    7. Proves conditional branches to be unconditional
    8. +
    + +

    + Note that this pass has a habit of making definitions be dead. It is a good + idea to to run a DCE pass sometime after running this pass. +

    +
    + + + +
    +

    + Applies a variety of small optimizations for calls to specific well-known + function calls (e.g. runtime library functions). For example, a call + exit(3) that occurs within the main() function can be + transformed into simply return 3. +

    +
    + + + +
    +

    + Performs dead code elimination and basic block merging. Specifically: +

    + +
      +
    1. Removes basic blocks with no predecessors.
    2. +
    3. Merges a basic block into its predecessor if there is only one and the + predecessor only has one successor.
    4. +
    5. Eliminates PHI nodes for basic blocks with a single predecessor.
    6. +
    7. Eliminates a basic block that only contains an unconditional + branch.
    8. +
    +
    + + + +
    +

    + Performs code stripping. This transformation can delete: +

    + +
      +
    1. names for virtual registers
    2. +
    3. symbols for internal globals and functions
    4. +
    5. debug information
    6. +
    + +

    + Note that this transformation makes code much less readable, so it should + only be used in situations where the strip utility would be used, + such as reducing code size or making it harder to reverse engineer code. +

    +
    + + + +
    +

    + This pass loops over all of the functions in the input module, looking for + dead declarations and removes them. Dead declarations are declarations of + functions for which no implementation is available (i.e., declarations for + unused library functions). +

    +
    + + + +
    +

    + This pass finds functions that return a struct (using a pointer to the struct + as the first argument of the function, marked with the 'sret' attribute) and + replaces them with a new function that simply returns each of the elements of + that struct (using multiple return values). +

    + +

    + This pass works under a number of conditions: +

    + +
      +
    • The returned struct must not contain other structs
    • +
    • The returned struct must only be used to load values from
    • +
    • The placeholder struct passed in is the result of an alloca
    • +
    +
    + + + +
    +

    + This file transforms calls of the current function (self recursion) followed + by a return instruction with a branch to the entry of the function, creating + a loop. This pass also implements the following extensions to the basic + algorithm: +

    + +
      +
    • Trivial instructions between the call and return do not prevent the + transformation from taking place, though currently the analysis cannot + support moving any really useful instructions (only dead ones). +
    • This pass transforms functions that are prevented from being tail + recursive by an associative expression to use an accumulator variable, + thus compiling the typical naive factorial or fib implementation + into efficient code. +
    • TRE is performed if the function returns void, if the return + returns the result returned by the call, or if the function returns a + run-time constant on all exits from the function. It is possible, though + unlikely, that the return returns something else (like constant 0), and + can still be TRE'd. It can be TRE'd if all other return + instructions in the function return the exact same value. +
    • If it can prove that callees do not access theier caller stack frame, + they are marked as eligible for tail call elimination (by the code + generator). +
    +
    + + + +
    +

    + This pass performs a limited form of tail duplication, intended to simplify + CFGs by removing some unconditional branches. This pass is necessary to + straighten out loops created by the C front-end, but also is capable of + making other code nicer. After this pass is run, the CFG simplify pass + should be run to clean up the mess. +

    +
    + + + +
    +

    This section describes the LLVM Utility Passes.

    +
    + + + +
    +

    + Same as dead argument elimination, but deletes arguments to functions which + are external. This is only for use by bugpoint.

    +
    + + + +
    +

    + This pass is used by bugpoint to extract all blocks from the module into their + own functions.

    +
    + + + +
    +

    + Ensures that the module is in the form required by the Module Verifier pass. +

    + +

    + Running the verifier runs this pass automatically, so there should be no need + to use it directly. +

    +
    + + + +
    +

    + Verifies an LLVM IR code. This is useful to run after an optimization which is + undergoing testing. Note that llvm-as verifies its input before + emitting bitcode, and also that malformed bitcode is likely to make LLVM + crash. All language front-ends are therefore encouraged to verify their output + before performing optimizing transformations. +

    + +
      +
    • Both of a binary operator's parameters are of the same type.
    • +
    • Verify that the indices of mem access instructions match other + operands.
    • +
    • Verify that arithmetic and other things are only performed on + first-class types. Verify that shifts and logicals only happen on + integrals f.e.
    • +
    • All of the constants in a switch statement are of the correct type.
    • +
    • The code is in valid SSA form.
    • +
    • It should be illegal to put a label into any other type (like a + structure) or to return one. [except constant arrays!]
    • +
    • Only phi nodes can be self referential: %x = add i32 %x, %x is + invalid.
    • +
    • PHI nodes must have an entry for each predecessor, with no extras.
    • +
    • PHI nodes must be the first thing in a basic block, all grouped + together.
    • +
    • PHI nodes must have at least one entry.
    • +
    • All basic blocks should only end with terminator insts, not contain + them.
    • +
    • The entry node to a function must not have predecessors.
    • +
    • All Instructions must be embedded into a basic block.
    • +
    • Functions cannot take a void-typed parameter.
    • +
    • Verify that a function's argument list agrees with its declared + type.
    • +
    • It is illegal to specify a name for a void value.
    • +
    • It is illegal to have a internal global value with no initializer.
    • +
    • It is illegal to have a ret instruction that returns a value that does + not agree with the function return value type.
    • +
    • Function call argument types match the function prototype.
    • +
    • All other things that are tested by asserts spread about the code.
    • +
    + +

    + Note that this does not provide full security verification (like Java), but + instead just tries to ensure that code is well-formed. +

    +
    + + + +
    +

    + Displays the control flow graph using the GraphViz tool. +

    +
    + + + +
    +

    + Displays the control flow graph using the GraphViz tool, but omitting function + bodies. +

    +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Reid Spencer
    + LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/ProgrammersManual.html diff -c /dev/null llvm-www/releases/2.5/docs/ProgrammersManual.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/ProgrammersManual.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,3426 ---- + + + + LLVM Programmer's Manual + + + + +
    + LLVM Programmer's Manual +
    + +
      +
    1. Introduction
    2. +
    3. General Information + +
    4. +
    5. Important and useful LLVM APIs + +
    6. +
    7. Picking the Right Data Structure for a Task + +
    8. +
    9. Helpful Hints for Common Operations + +
    10. + +
    11. Advanced Topics +
    12. + +
    13. The Core LLVM Class Hierarchy Reference + +
    14. +
    + + + + + + + +
    + +

    This document is meant to highlight some of the important classes and + interfaces available in the LLVM source-base. This manual is not + intended to explain what LLVM is, how it works, and what LLVM code looks + like. It assumes that you know the basics of LLVM and are interested + in writing transformations or otherwise analyzing or manipulating the + code.

    + +

    This document should get you oriented so that you can find your + way in the continuously growing source code that makes up the LLVM + infrastructure. Note that this manual is not intended to serve as a + replacement for reading the source code, so if you think there should be + a method in one of these classes to do something, but it's not listed, + check the source. Links to the doxygen sources + are provided to make this as easy as possible.

    + +

    The first section of this document describes general information that is + useful to know when working in the LLVM infrastructure, and the second describes + the Core LLVM classes. In the future this manual will be extended with + information describing how to use extension libraries, such as dominator + information, CFG traversal routines, and useful utilities like the InstVisitor template.

    + +
    + + + + + +
    + +

    This section contains general information that is useful if you are working + in the LLVM source-base, but that isn't specific to any particular API.

    + +
    + + + + +
    + +

    LLVM makes heavy use of the C++ Standard Template Library (STL), + perhaps much more than you are used to, or have seen before. Because of + this, you might want to do a little background reading in the + techniques used and capabilities of the library. There are many good + pages that discuss the STL, and several books on the subject that you + can get, so it will not be discussed in this document.

    + +

    Here are some useful links:

    + +
      + +
    1. Dinkumware C++ Library + reference - an excellent reference for the STL and other parts of the + standard C++ library.
    2. + +
    3. C++ In a Nutshell - This is an + O'Reilly book in the making. It has a decent + Standard Library + Reference that rivals Dinkumware's, and is unfortunately no longer free since the book has been + published.
    4. + +
    5. C++ Frequently Asked + Questions
    6. + +
    7. SGI's STL Programmer's Guide - + Contains a useful Introduction to the + STL.
    8. + +
    9. Bjarne Stroustrup's C++ + Page
    10. + +
    11. + Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get + the book).
    12. + +
    + +

    You are also encouraged to take a look at the LLVM Coding Standards guide which focuses on how + to write maintainable code more than where to put your curly braces.

    + +
    + + + + + + + + + + +
    + +

    Here we highlight some LLVM APIs that are generally useful and good to + know about when writing transformations.

    + +
    + + + + +
    + +

    The LLVM source-base makes extensive use of a custom form of RTTI. + These templates have many similarities to the C++ dynamic_cast<> + operator, but they don't have some drawbacks (primarily stemming from + the fact that dynamic_cast<> only works on classes that + have a v-table). Because they are used so often, you must know what they + do and how they work. All of these templates are defined in the llvm/Support/Casting.h + file (note that you very rarely have to include this file directly).

    + +
    +
    isa<>:
    + +

    The isa<> operator works exactly like the Java + "instanceof" operator. It returns true or false depending on whether + a reference or pointer points to an instance of the specified class. This can + be very useful for constraint checking of various sorts (example below).

    +
    + +
    cast<>:
    + +

    The cast<> operator is a "checked cast" operation. It + converts a pointer or reference from a base class to a derived class, causing + an assertion failure if it is not really an instance of the right type. This + should be used in cases where you have some information that makes you believe + that something is of the right type. An example of the isa<> + and cast<> template is:

    + +
    +
    + static bool isLoopInvariant(const Value *V, const Loop *L) {
    +   if (isa<Constant>(V) || isa<Argument>(V) || isa<GlobalValue>(V))
    +     return true;
    + 
    +   // Otherwise, it must be an instruction...
    +   return !L->contains(cast<Instruction>(V)->getParent());
    + }
    + 
    +
    + +

    Note that you should not use an isa<> test followed + by a cast<>, for that use the dyn_cast<> + operator.

    + +
    + +
    dyn_cast<>:
    + +

    The dyn_cast<> operator is a "checking cast" operation. + It checks to see if the operand is of the specified type, and if so, returns a + pointer to it (this operator does not work with references). If the operand is + not of the correct type, a null pointer is returned. Thus, this works very + much like the dynamic_cast<> operator in C++, and should be + used in the same circumstances. Typically, the dyn_cast<> + operator is used in an if statement or some other flow control + statement like this:

    + +
    +
    + if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) {
    +   // ...
    + }
    + 
    +
    + +

    This form of the if statement effectively combines together a call + to isa<> and a call to cast<> into one + statement, which is very convenient.

    + +

    Note that the dyn_cast<> operator, like C++'s + dynamic_cast<> or Java's instanceof operator, can be + abused. In particular, you should not use big chained if/then/else + blocks to check for lots of different variants of classes. If you find + yourself wanting to do this, it is much cleaner and more efficient to use the + InstVisitor class to dispatch over the instruction type directly.

    + +
    + +
    cast_or_null<>:
    + +

    The cast_or_null<> operator works just like the + cast<> operator, except that it allows for a null pointer as an + argument (which it then propagates). This can sometimes be useful, allowing + you to combine several null checks into one.

    + +
    dyn_cast_or_null<>:
    + +

    The dyn_cast_or_null<> operator works just like the + dyn_cast<> operator, except that it allows for a null pointer + as an argument (which it then propagates). This can sometimes be useful, + allowing you to combine several null checks into one.

    + +
    + +

    These five templates can be used with any classes, whether they have a + v-table or not. To add support for these templates, you simply need to add + classof static methods to the class you are interested casting + to. Describing this is currently outside the scope of this document, but there + are lots of examples in the LLVM source base.

    + +
    + + + + +
    + +

    Often when working on your pass you will put a bunch of debugging printouts + and other code into your pass. After you get it working, you want to remove + it, but you may need it again in the future (to work out new bugs that you run + across).

    + +

    Naturally, because of this, you don't want to delete the debug printouts, + but you don't want them to always be noisy. A standard compromise is to comment + them out, allowing you to enable them if you need them in the future.

    + +

    The "llvm/Support/Debug.h" + file provides a macro named DEBUG() that is a much nicer solution to + this problem. Basically, you can put arbitrary code into the argument of the + DEBUG macro, and it is only executed if 'opt' (or any other + tool) is run with the '-debug' command line argument:

    + +
    +
    + DOUT << "I am here!\n";
    + 
    +
    + +

    Then you can run your pass like this:

    + +
    +
    + $ opt < a.bc > /dev/null -mypass
    + <no output>
    + $ opt < a.bc > /dev/null -mypass -debug
    + I am here!
    + 
    +
    + +

    Using the DEBUG() macro instead of a home-brewed solution allows you + to not have to create "yet another" command line option for the debug output for + your pass. Note that DEBUG() macros are disabled for optimized builds, + so they do not cause a performance impact at all (for the same reason, they + should also not contain side-effects!).

    + +

    One additional nice thing about the DEBUG() macro is that you can + enable or disable it directly in gdb. Just use "set DebugFlag=0" or + "set DebugFlag=1" from the gdb if the program is running. If the + program hasn't been started yet, you can always just run it with + -debug.

    + +
    + + + + +
    + +

    Sometimes you may find yourself in a situation where enabling -debug + just turns on too much information (such as when working on the code + generator). If you want to enable debug information with more fine-grained + control, you define the DEBUG_TYPE macro and the -debug only + option as follows:

    + +
    +
    + DOUT << "No debug type\n";
    + #undef  DEBUG_TYPE
    + #define DEBUG_TYPE "foo"
    + DOUT << "'foo' debug type\n";
    + #undef  DEBUG_TYPE
    + #define DEBUG_TYPE "bar"
    + DOUT << "'bar' debug type\n";
    + #undef  DEBUG_TYPE
    + #define DEBUG_TYPE ""
    + DOUT << "No debug type (2)\n";
    + 
    +
    + +

    Then you can run your pass like this:

    + +
    +
    + $ opt < a.bc > /dev/null -mypass
    + <no output>
    + $ opt < a.bc > /dev/null -mypass -debug
    + No debug type
    + 'foo' debug type
    + 'bar' debug type
    + No debug type (2)
    + $ opt < a.bc > /dev/null -mypass -debug-only=foo
    + 'foo' debug type
    + $ opt < a.bc > /dev/null -mypass -debug-only=bar
    + 'bar' debug type
    + 
    +
    + +

    Of course, in practice, you should only set DEBUG_TYPE at the top of + a file, to specify the debug type for the entire module (if you do this before + you #include "llvm/Support/Debug.h", you don't have to insert the ugly + #undef's). Also, you should use names more meaningful than "foo" and + "bar", because there is no system in place to ensure that names do not + conflict. If two different modules use the same string, they will all be turned + on when the name is specified. This allows, for example, all debug information + for instruction scheduling to be enabled with -debug-type=InstrSched, + even if the source lives in multiple files.

    + +
    + + + + +
    + +

    The "llvm/ADT/Statistic.h" file + provides a class named Statistic that is used as a unified way to + keep track of what the LLVM compiler is doing and how effective various + optimizations are. It is useful to see what optimizations are contributing to + making a particular program run faster.

    + +

    Often you may run your pass on some big program, and you're interested to see + how many times it makes a certain transformation. Although you can do this with + hand inspection, or some ad-hoc method, this is a real pain and not very useful + for big programs. Using the Statistic class makes it very easy to + keep track of this information, and the calculated information is presented in a + uniform manner with the rest of the passes being executed.

    + +

    There are many examples of Statistic uses, but the basics of using + it are as follows:

    + +
      +
    1. Define your statistic like this:

      + +
      +
      + #define DEBUG_TYPE "mypassname"   // This goes before any #includes.
      + STATISTIC(NumXForms, "The # of times I did stuff");
      + 
      +
      + +

      The STATISTIC macro defines a static variable, whose name is + specified by the first argument. The pass name is taken from the DEBUG_TYPE + macro, and the description is taken from the second argument. The variable + defined ("NumXForms" in this case) acts like an unsigned integer.

    2. + +
    3. Whenever you make a transformation, bump the counter:

      + +
      +
      + ++NumXForms;   // I did stuff!
      + 
      +
      + +
    4. +
    + +

    That's all you have to do. To get 'opt' to print out the + statistics gathered, use the '-stats' option:

    + +
    +
    + $ opt -stats -mypassname < program.bc > /dev/null
    + ... statistics output ...
    + 
    +
    + +

    When running opt on a C file from the SPEC benchmark + suite, it gives a report that looks like this:

    + +
    +
    +    7646 bitcodewriter   - Number of normal instructions
    +     725 bitcodewriter   - Number of oversized instructions
    +  129996 bitcodewriter   - Number of bitcode bytes written
    +    2817 raise           - Number of insts DCEd or constprop'd
    +    3213 raise           - Number of cast-of-self removed
    +    5046 raise           - Number of expression trees converted
    +      75 raise           - Number of other getelementptr's formed
    +     138 raise           - Number of load/store peepholes
    +      42 deadtypeelim    - Number of unused typenames removed from symtab
    +     392 funcresolve     - Number of varargs functions resolved
    +      27 globaldce       - Number of global variables removed
    +       2 adce            - Number of basic blocks removed
    +     134 cee             - Number of branches revectored
    +      49 cee             - Number of setcc instruction eliminated
    +     532 gcse            - Number of loads removed
    +    2919 gcse            - Number of instructions removed
    +      86 indvars         - Number of canonical indvars added
    +      87 indvars         - Number of aux indvars removed
    +      25 instcombine     - Number of dead inst eliminate
    +     434 instcombine     - Number of insts combined
    +     248 licm            - Number of load insts hoisted
    +    1298 licm            - Number of insts hoisted to a loop pre-header
    +       3 licm            - Number of insts hoisted to multiple loop preds (bad, no loop pre-header)
    +      75 mem2reg         - Number of alloca's promoted
    +    1444 cfgsimplify     - Number of blocks simplified
    + 
    +
    + +

    Obviously, with so many optimizations, having a unified framework for this + stuff is very nice. Making your pass fit well into the framework makes it more + maintainable and useful.

    + +
    + + + + +
    + +

    Several of the important data structures in LLVM are graphs: for example + CFGs made out of LLVM BasicBlocks, CFGs made out of + LLVM MachineBasicBlocks, and + Instruction Selection + DAGs. In many cases, while debugging various parts of the compiler, it is + nice to instantly visualize these graphs.

    + +

    LLVM provides several callbacks that are available in a debug build to do + exactly that. If you call the Function::viewCFG() method, for example, + the current LLVM tool will pop up a window containing the CFG for the function + where each basic block is a node in the graph, and each node contains the + instructions in the block. Similarly, there also exists + Function::viewCFGOnly() (does not include the instructions), the + MachineFunction::viewCFG() and MachineFunction::viewCFGOnly(), + and the SelectionDAG::viewGraph() methods. Within GDB, for example, + you can usually use something like call DAG.viewGraph() to pop + up a window. Alternatively, you can sprinkle calls to these functions in your + code in places you want to debug.

    + +

    Getting this to work requires a small amount of configuration. On Unix + systems with X11, install the graphviz + toolkit, and make sure 'dot' and 'gv' are in your path. If you are running on + Mac OS/X, download and install the Mac OS/X Graphviz program, and add + /Applications/Graphviz.app/Contents/MacOS/ (or wherever you install + it) to your path. Once in your system and path are set up, rerun the LLVM + configure script and rebuild LLVM to enable this functionality.

    + +

    SelectionDAG has been extended to make it easier to locate + interesting nodes in large complex graphs. From gdb, if you + call DAG.setGraphColor(node, "color"), then the + next call DAG.viewGraph() would highlight the node in the + specified color (choices of colors can be found at colors.) More + complex node attributes can be provided with call + DAG.setGraphAttrs(node, "attributes") (choices can be + found at Graph + Attributes.) If you want to restart and clear all the current graph + attributes, then you can call DAG.clearGraphAttrs().

    + +
    + + + + + +
    + +

    LLVM has a plethora of data structures in the llvm/ADT/ directory, + and we commonly use STL data structures. This section describes the trade-offs + you should consider when you pick one.

    + +

    + The first step is a choose your own adventure: do you want a sequential + container, a set-like container, or a map-like container? The most important + thing when choosing a container is the algorithmic properties of how you plan to + access the container. Based on that, you should use:

    + +
      +
    • a map-like container if you need efficient look-up + of an value based on another value. Map-like containers also support + efficient queries for containment (whether a key is in the map). Map-like + containers generally do not support efficient reverse mapping (values to + keys). If you need that, use two maps. Some map-like containers also + support efficient iteration through the keys in sorted order. Map-like + containers are the most expensive sort, only use them if you need one of + these capabilities.
    • + +
    • a set-like container if you need to put a bunch of + stuff into a container that automatically eliminates duplicates. Some + set-like containers support efficient iteration through the elements in + sorted order. Set-like containers are more expensive than sequential + containers. +
    • + +
    • a sequential container provides + the most efficient way to add elements and keeps track of the order they are + added to the collection. They permit duplicates and support efficient + iteration, but do not support efficient look-up based on a key. +
    • + +
    • a bit container provides an efficient way to store and + perform set operations on sets of numeric id's, while automatically + eliminating duplicates. Bit containers require a maximum of 1 bit for each + identifier you want to store. +
    • +
    + +

    + Once the proper category of container is determined, you can fine tune the + memory use, constant factors, and cache behaviors of access by intelligently + picking a member of the category. Note that constant factors and cache behavior + can be a big deal. If you have a vector that usually only contains a few + elements (but could contain many), for example, it's much better to use + SmallVector than vector + . Doing so avoids (relatively) expensive malloc/free calls, which dwarf the + cost of adding the elements to the container.

    + +
    + + + + +
    + There are a variety of sequential containers available for you, based on your + needs. Pick the first in this section that will do what you want. +
    + + + + +
    +

    Fixed size arrays are very simple and very fast. They are good if you know + exactly how many elements you have, or you have a (low) upper bound on how many + you have.

    +
    + + + + +
    +

    Heap allocated arrays (new[] + delete[]) are also simple. They are good if + the number of elements is variable, if you know how many elements you will need + before the array is allocated, and if the array is usually large (if not, + consider a SmallVector). The cost of a heap + allocated array is the cost of the new/delete (aka malloc/free). Also note that + if you are allocating an array of a type with a constructor, the constructor and + destructors will be run for every element in the array (re-sizable vectors only + construct those elements actually used).

    +
    + + + + +
    +

    SmallVector<Type, N> is a simple class that looks and smells + just like vector<Type>: + it supports efficient iteration, lays out elements in memory order (so you can + do pointer arithmetic between elements), supports efficient push_back/pop_back + operations, supports efficient random access to its elements, etc.

    + +

    The advantage of SmallVector is that it allocates space for + some number of elements (N) in the object itself. Because of this, if + the SmallVector is dynamically smaller than N, no malloc is performed. This can + be a big win in cases where the malloc/free call is far more expensive than the + code that fiddles around with the elements.

    + +

    This is good for vectors that are "usually small" (e.g. the number of + predecessors/successors of a block is usually less than 8). On the other hand, + this makes the size of the SmallVector itself large, so you don't want to + allocate lots of them (doing so will waste a lot of space). As such, + SmallVectors are most useful when on the stack.

    + +

    SmallVector also provides a nice portable and efficient replacement for + alloca.

    + +
    + + +
    + <vector> +
    + +
    +

    + std::vector is well loved and respected. It is useful when SmallVector isn't: + when the size of the vector is often large (thus the small optimization will + rarely be a benefit) or if you will be allocating many instances of the vector + itself (which would waste space for elements that aren't in the container). + vector is also useful when interfacing with code that expects vectors :). +

    + +

    One worthwhile note about std::vector: avoid code like this:

    + +
    +
    + for ( ... ) {
    +    std::vector<foo> V;
    +    use V;
    + }
    + 
    +
    + +

    Instead, write this as:

    + +
    +
    + std::vector<foo> V;
    + for ( ... ) {
    +    use V;
    +    V.clear();
    + }
    + 
    +
    + +

    Doing so will save (at least) one heap allocation and free per iteration of + the loop.

    + +
    + + +
    + <deque> +
    + +
    +

    std::deque is, in some senses, a generalized version of std::vector. Like + std::vector, it provides constant time random access and other similar + properties, but it also provides efficient access to the front of the list. It + does not guarantee continuity of elements within memory.

    + +

    In exchange for this extra flexibility, std::deque has significantly higher + constant factor costs than std::vector. If possible, use std::vector or + something cheaper.

    +
    + + +
    + <list> +
    + +
    +

    std::list is an extremely inefficient class that is rarely useful. + It performs a heap allocation for every element inserted into it, thus having an + extremely high constant factor, particularly for small data types. std::list + also only supports bidirectional iteration, not random access iteration.

    + +

    In exchange for this high cost, std::list supports efficient access to both + ends of the list (like std::deque, but unlike std::vector or SmallVector). In + addition, the iterator invalidation characteristics of std::list are stronger + than that of a vector class: inserting or removing an element into the list does + not invalidate iterator or pointers to other elements in the list.

    +
    + + + + +
    +

    ilist<T> implements an 'intrusive' doubly-linked list. It is + intrusive, because it requires the element to store and provide access to the + prev/next pointers for the list.

    + +

    ilist has the same drawbacks as std::list, and additionally requires an + ilist_traits implementation for the element type, but it provides some novel + characteristics. In particular, it can efficiently store polymorphic objects, + the traits class is informed when an element is inserted or removed from the + list, and ilists are guaranteed to support a constant-time splice operation. +

    + +

    These properties are exactly what we want for things like Instructions and + basic blocks, which is why these are implemented with ilists.

    +
    + + + + +
    +

    Other STL containers are available, such as std::string.

    + +

    There are also various STL adapter classes such as std::queue, + std::priority_queue, std::stack, etc. These provide simplified access to an + underlying container but don't affect the cost of the container itself.

    + +
    + + + + + +
    + +

    Set-like containers are useful when you need to canonicalize multiple values + into a single representation. There are several different choices for how to do + this, providing various trade-offs.

    + +
    + + + + + +
    + +

    If you intend to insert a lot of elements, then do a lot of queries, a + great approach is to use a vector (or other sequential container) with + std::sort+std::unique to remove duplicates. This approach works really well if + your usage pattern has these two distinct phases (insert then query), and can be + coupled with a good choice of sequential container. +

    + +

    + This combination provides the several nice properties: the result data is + contiguous in memory (good for cache locality), has few allocations, is easy to + address (iterators in the final vector are just indices or pointers), and can be + efficiently queried with a standard binary or radix search.

    + +
    + + + + +
    + +

    If you have a set-like data structure that is usually small and whose elements + are reasonably small, a SmallSet<Type, N> is a good choice. This set + has space for N elements in place (thus, if the set is dynamically smaller than + N, no malloc traffic is required) and accesses them with a simple linear search. + When the set grows beyond 'N' elements, it allocates a more expensive representation that + guarantees efficient access (for most types, it falls back to std::set, but for + pointers it uses something far better, SmallPtrSet).

    + +

    The magic of this class is that it handles small sets extremely efficiently, + but gracefully handles extremely large sets without loss of efficiency. The + drawback is that the interface is quite small: it supports insertion, queries + and erasing, but does not support iteration.

    + +
    + + + + +
    + +

    SmallPtrSet has all the advantages of SmallSet (and a SmallSet of pointers is + transparently implemented with a SmallPtrSet), but also supports iterators. If + more than 'N' insertions are performed, a single quadratically + probed hash table is allocated and grows as needed, providing extremely + efficient access (constant time insertion/deleting/queries with low constant + factors) and is very stingy with malloc traffic.

    + +

    Note that, unlike std::set, the iterators of SmallPtrSet are invalidated + whenever an insertion occurs. Also, the values visited by the iterators are not + visited in sorted order.

    + +
    + + + + +
    + +

    + DenseSet is a simple quadratically probed hash table. It excels at supporting + small values: it uses a single allocation to hold all of the pairs that + are currently inserted in the set. DenseSet is a great way to unique small + values that are not simple pointers (use SmallPtrSet for pointers). Note that DenseSet has + the same requirements for the value type that DenseMap has. +

    + +
    + + + + +
    + +

    + FoldingSet is an aggregate class that is really good at uniquing + expensive-to-create or polymorphic objects. It is a combination of a chained + hash table with intrusive links (uniqued objects are required to inherit from + FoldingSetNode) that uses SmallVector as part of + its ID process.

    + +

    Consider a case where you want to implement a "getOrCreateFoo" method for + a complex object (for example, a node in the code generator). The client has a + description of *what* it wants to generate (it knows the opcode and all the + operands), but we don't want to 'new' a node, then try inserting it into a set + only to find out it already exists, at which point we would have to delete it + and return the node that already exists. +

    + +

    To support this style of client, FoldingSet perform a query with a + FoldingSetNodeID (which wraps SmallVector) that can be used to describe the + element that we want to query for. The query either returns the element + matching the ID or it returns an opaque ID that indicates where insertion should + take place. Construction of the ID usually does not require heap traffic.

    + +

    Because FoldingSet uses intrusive links, it can support polymorphic objects + in the set (for example, you can have SDNode instances mixed with LoadSDNodes). + Because the elements are individually allocated, pointers to the elements are + stable: inserting or removing elements does not invalidate any pointers to other + elements. +

    + +
    + + +
    + <set> +
    + +
    + +

    std::set is a reasonable all-around set class, which is decent at + many things but great at nothing. std::set allocates memory for each element + inserted (thus it is very malloc intensive) and typically stores three pointers + per element in the set (thus adding a large amount of per-element space + overhead). It offers guaranteed log(n) performance, which is not particularly + fast from a complexity standpoint (particularly if the elements of the set are + expensive to compare, like strings), and has extremely high constant factors for + lookup, insertion and removal.

    + +

    The advantages of std::set are that its iterators are stable (deleting or + inserting an element from the set does not affect iterators or pointers to other + elements) and that iteration over the set is guaranteed to be in sorted order. + If the elements in the set are large, then the relative overhead of the pointers + and malloc traffic is not a big deal, but if the elements of the set are small, + std::set is almost never a good choice.

    + +
    + + + + +
    +

    LLVM's SetVector<Type> is an adapter class that combines your choice of + a set-like container along with a Sequential + Container. The important property + that this provides is efficient insertion with uniquing (duplicate elements are + ignored) with iteration support. It implements this by inserting elements into + both a set-like container and the sequential container, using the set-like + container for uniquing and the sequential container for iteration. +

    + +

    The difference between SetVector and other sets is that the order of + iteration is guaranteed to match the order of insertion into the SetVector. + This property is really important for things like sets of pointers. Because + pointer values are non-deterministic (e.g. vary across runs of the program on + different machines), iterating over the pointers in the set will + not be in a well-defined order.

    + +

    + The drawback of SetVector is that it requires twice as much space as a normal + set and has the sum of constant factors from the set-like container and the + sequential container that it uses. Use it *only* if you need to iterate over + the elements in a deterministic order. SetVector is also expensive to delete + elements out of (linear time), unless you use it's "pop_back" method, which is + faster. +

    + +

    SetVector is an adapter class that defaults to using std::vector and std::set + for the underlying containers, so it is quite expensive. However, + "llvm/ADT/SetVector.h" also provides a SmallSetVector class, which + defaults to using a SmallVector and SmallSet of a specified size. If you use + this, and if your sets are dynamically smaller than N, you will save a lot of + heap traffic.

    + +
    + + + + +
    + +

    + UniqueVector is similar to SetVector, but it + retains a unique ID for each element inserted into the set. It internally + contains a map and a vector, and it assigns a unique ID for each value inserted + into the set.

    + +

    UniqueVector is very expensive: its cost is the sum of the cost of + maintaining both the map and vector, it has high complexity, high constant + factors, and produces a lot of malloc traffic. It should be avoided.

    + +
    + + + + + +
    + +

    + The STL provides several other options, such as std::multiset and the various + "hash_set" like containers (whether from C++ TR1 or from the SGI library).

    + +

    std::multiset is useful if you're not interested in elimination of + duplicates, but has all the drawbacks of std::set. A sorted vector (where you + don't delete duplicate entries) or some other approach is almost always + better.

    + +

    The various hash_set implementations (exposed portably by + "llvm/ADT/hash_set") is a simple chained hashtable. This algorithm is as malloc + intensive as std::set (performing an allocation for each element inserted, + thus having really high constant factors) but (usually) provides O(1) + insertion/deletion of elements. This can be useful if your elements are large + (thus making the constant-factor cost relatively low) or if comparisons are + expensive. Element iteration does not visit elements in a useful order.

    + +
    + + + + +
    + Map-like containers are useful when you want to associate data to a key. As + usual, there are a lot of different ways to do this. :) +
    + + + + +
    + +

    + If your usage pattern follows a strict insert-then-query approach, you can + trivially use the same approach as sorted vectors + for set-like containers. The only difference is that your query function + (which uses std::lower_bound to get efficient log(n) lookup) should only compare + the key, not both the key and value. This yields the same advantages as sorted + vectors for sets. +

    +
    + + + + +
    + +

    + Strings are commonly used as keys in maps, and they are difficult to support + efficiently: they are variable length, inefficient to hash and compare when + long, expensive to copy, etc. StringMap is a specialized container designed to + cope with these issues. It supports mapping an arbitrary range of bytes to an + arbitrary other object.

    + +

    The StringMap implementation uses a quadratically-probed hash table, where + the buckets store a pointer to the heap allocated entries (and some other + stuff). The entries in the map must be heap allocated because the strings are + variable length. The string data (key) and the element object (value) are + stored in the same allocation with the string data immediately after the element + object. This container guarantees the "(char*)(&Value+1)" points + to the key string for a value.

    + +

    The StringMap is very fast for several reasons: quadratic probing is very + cache efficient for lookups, the hash value of strings in buckets is not + recomputed when lookup up an element, StringMap rarely has to touch the + memory for unrelated objects when looking up a value (even when hash collisions + happen), hash table growth does not recompute the hash values for strings + already in the table, and each pair in the map is store in a single allocation + (the string data is stored in the same allocation as the Value of a pair).

    + +

    StringMap also provides query methods that take byte ranges, so it only ever + copies a string if a value is inserted into the table.

    +
    + + + + +
    +

    + IndexedMap is a specialized container for mapping small dense integers (or + values that can be mapped to small dense integers) to some other type. It is + internally implemented as a vector with a mapping function that maps the keys to + the dense integer range. +

    + +

    + This is useful for cases like virtual registers in the LLVM code generator: they + have a dense mapping that is offset by a compile-time constant (the first + virtual register ID).

    + +
    + + + + +
    + +

    + DenseMap is a simple quadratically probed hash table. It excels at supporting + small keys and values: it uses a single allocation to hold all of the pairs that + are currently inserted in the map. DenseMap is a great way to map pointers to + pointers, or map other small types to each other. +

    + +

    + There are several aspects of DenseMap that you should be aware of, however. The + iterators in a densemap are invalidated whenever an insertion occurs, unlike + map. Also, because DenseMap allocates space for a large number of key/value + pairs (it starts with 64 by default), it will waste a lot of space if your keys + or values are large. Finally, you must implement a partial specialization of + DenseMapInfo for the key that you want, if it isn't already supported. This + is required to tell DenseMap about two special marker values (which can never be + inserted into the map) that it needs internally.

    + +
    + + +
    + <map> +
    + +
    + +

    + std::map has similar characteristics to std::set: it uses + a single allocation per pair inserted into the map, it offers log(n) lookup with + an extremely large constant factor, imposes a space penalty of 3 pointers per + pair in the map, etc.

    + +

    std::map is most useful when your keys or values are very large, if you need + to iterate over the collection in sorted order, or if you need stable iterators + into the map (i.e. they don't get invalidated if an insertion or deletion of + another element takes place).

    + +
    + + + + +
    + +

    + The STL provides several other options, such as std::multimap and the various + "hash_map" like containers (whether from C++ TR1 or from the SGI library).

    + +

    std::multimap is useful if you want to map a key to multiple values, but has + all the drawbacks of std::map. A sorted vector or some other approach is almost + always better.

    + +

    The various hash_map implementations (exposed portably by + "llvm/ADT/hash_map") are simple chained hash tables. This algorithm is as + malloc intensive as std::map (performing an allocation for each element + inserted, thus having really high constant factors) but (usually) provides O(1) + insertion/deletion of elements. This can be useful if your elements are large + (thus making the constant-factor cost relatively low) or if comparisons are + expensive. Element iteration does not visit elements in a useful order.

    + +
    + + + + +
    +

    Unlike the other containers, there are only two bit storage containers, and + choosing when to use each is relatively straightforward.

    + +

    One additional option is + std::vector<bool>: we discourage its use for two reasons 1) the + implementation in many common compilers (e.g. commonly available versions of + GCC) is extremely inefficient and 2) the C++ standards committee is likely to + deprecate this container and/or change it significantly somehow. In any case, + please don't use it.

    +
    + + +
    + BitVector +
    + +
    +

    The BitVector container provides a fixed size set of bits for manipulation. + It supports individual bit setting/testing, as well as set operations. The set + operations take time O(size of bitvector), but operations are performed one word + at a time, instead of one bit at a time. This makes the BitVector very fast for + set operations compared to other containers. Use the BitVector when you expect + the number of set bits to be high (IE a dense set). +

    +
    + + + + +
    +

    The SparseBitVector container is much like BitVector, with one major + difference: Only the bits that are set, are stored. This makes the + SparseBitVector much more space efficient than BitVector when the set is sparse, + as well as making set operations O(number of set bits) instead of O(size of + universe). The downside to the SparseBitVector is that setting and testing of random bits is O(N), and on large SparseBitVectors, this can be slower than BitVector. In our implementation, setting or testing bits in sorted order + (either forwards or reverse) is O(1) worst case. Testing and setting bits within 128 bits (depends on size) of the current bit is also O(1). As a general statement, testing/setting bits in a SparseBitVector is O(distance away from last set bit). +

    +
    + + + + + +
    + +

    This section describes how to perform some very simple transformations of + LLVM code. This is meant to give examples of common idioms used, showing the + practical side of LLVM transformations.

    Because this is a "how-to" section, + you should also read about the main classes that you will be working with. The + Core LLVM Class Hierarchy Reference contains details + and descriptions of the main classes that you should know about.

    + +
    + + + + + +
    + +

    The LLVM compiler infrastructure have many different data structures that may + be traversed. Following the example of the C++ standard template library, the + techniques used to traverse these various data structures are all basically the + same. For a enumerable sequence of values, the XXXbegin() function (or + method) returns an iterator to the start of the sequence, the XXXend() + function returns an iterator pointing to one past the last valid element of the + sequence, and there is some XXXiterator data type that is common + between the two operations.

    + +

    Because the pattern for iteration is common across many different aspects of + the program representation, the standard template library algorithms may be used + on them, and it is easier to remember how to iterate. First we show a few common + examples of the data structures that need to be traversed. Other data + structures are traversed in very similar ways.

    + +
    + + + + +
    + +

    It's quite common to have a Function instance that you'd like to + transform in some way; in particular, you'd like to manipulate its + BasicBlocks. To facilitate this, you'll need to iterate over all of + the BasicBlocks that constitute the Function. The following is + an example that prints the name of a BasicBlock and the number of + Instructions it contains:

    + +
    +
    + // func is a pointer to a Function instance
    + for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i)
    +   // Print out the name of the basic block if it has one, and then the
    +   // number of instructions that it contains
    +   llvm::cerr << "Basic block (name=" << i->getName() << ") has "
    +              << i->size() << " instructions.\n";
    + 
    +
    + +

    Note that i can be used as if it were a pointer for the purposes of + invoking member functions of the Instruction class. This is + because the indirection operator is overloaded for the iterator + classes. In the above code, the expression i->size() is + exactly equivalent to (*i).size() just like you'd expect.

    + +
    + + + + +
    + +

    Just like when dealing with BasicBlocks in Functions, it's + easy to iterate over the individual instructions that make up + BasicBlocks. Here's a code snippet that prints out each instruction in + a BasicBlock:

    + +
    +
    + // blk is a pointer to a BasicBlock instance
    + for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
    +    // The next statement works since operator<<(ostream&,...)
    +    // is overloaded for Instruction&
    +    llvm::cerr << *i << "\n";
    + 
    +
    + +

    However, this isn't really the best way to print out the contents of a + BasicBlock! Since the ostream operators are overloaded for virtually + anything you'll care about, you could have just invoked the print routine on the + basic block itself: llvm::cerr << *blk << "\n";.

    + +
    + + + + +
    + +

    If you're finding that you commonly iterate over a Function's + BasicBlocks and then that BasicBlock's Instructions, + InstIterator should be used instead. You'll need to include llvm/Support/InstIterator.h, + and then instantiate InstIterators explicitly in your code. Here's a + small example that shows how to dump all instructions in a function to the standard error stream:

    + +

    +
    + #include "llvm/Support/InstIterator.h"
    + 
    + // F is a pointer to a Function instance
    + for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
    +   llvm::cerr << *I << "\n";
    + 
    +
    + +

    Easy, isn't it? You can also use InstIterators to fill a + work list with its initial contents. For example, if you wanted to + initialize a work list to contain all instructions in a Function + F, all you would need to do is something like:

    + +
    +
    + std::set<Instruction*> worklist;
    + // or better yet, SmallPtrSet<Instruction*, 64> worklist;
    + 
    + for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
    +    worklist.insert(&*I);
    + 
    +
    + +

    The STL set worklist would now contain all instructions in the + Function pointed to by F.

    + +
    + + + + +
    + +

    Sometimes, it'll be useful to grab a reference (or pointer) to a class + instance when all you've got at hand is an iterator. Well, extracting + a reference or a pointer from an iterator is very straight-forward. + Assuming that i is a BasicBlock::iterator and j + is a BasicBlock::const_iterator:

    + +
    +
    + Instruction& inst = *i;   // Grab reference to instruction reference
    + Instruction* pinst = &*i; // Grab pointer to instruction reference
    + const Instruction& inst = *j;
    + 
    +
    + +

    However, the iterators you'll be working with in the LLVM framework are + special: they will automatically convert to a ptr-to-instance type whenever they + need to. Instead of dereferencing the iterator and then taking the address of + the result, you can simply assign the iterator to the proper pointer type and + you get the dereference and address-of operation as a result of the assignment + (behind the scenes, this is a result of overloading casting mechanisms). Thus + the last line of the last example,

    + +
    +
    + Instruction *pinst = &*i;
    + 
    +
    + +

    is semantically equivalent to

    + +
    +
    + Instruction *pinst = i;
    + 
    +
    + +

    It's also possible to turn a class pointer into the corresponding iterator, + and this is a constant time operation (very efficient). The following code + snippet illustrates use of the conversion constructors provided by LLVM + iterators. By using these, you can explicitly grab the iterator of something + without actually obtaining it via iteration over some structure:

    + +
    +
    + void printNextInstruction(Instruction* inst) {
    +   BasicBlock::iterator it(inst);
    +   ++it; // After this line, it refers to the instruction after *inst
    +   if (it != inst->getParent()->end()) llvm::cerr << *it << "\n";
    + }
    + 
    +
    + +
    + + + + +
    + +

    Say that you're writing a FunctionPass and would like to count all the + locations in the entire module (that is, across every Function) where a + certain function (i.e., some Function*) is already in scope. As you'll + learn later, you may want to use an InstVisitor to accomplish this in a + much more straight-forward manner, but this example will allow us to explore how + you'd do it if you didn't have InstVisitor around. In pseudo-code, this + is what we want to do:

    + +
    +
    + initialize callCounter to zero
    + for each Function f in the Module
    +   for each BasicBlock b in f
    +     for each Instruction i in b
    +       if (i is a CallInst and calls the given function)
    +         increment callCounter
    + 
    +
    + +

    And the actual code is (remember, because we're writing a + FunctionPass, our FunctionPass-derived class simply has to + override the runOnFunction method):

    + +
    +
    + Function* targetFunc = ...;
    + 
    + class OurFunctionPass : public FunctionPass {
    +   public:
    +     OurFunctionPass(): callCounter(0) { }
    + 
    +     virtual runOnFunction(Function& F) {
    +       for (Function::iterator b = F.begin(), be = F.end(); b != be; ++b) {
    +         for (BasicBlock::iterator i = b->begin(), ie = b->end(); i != ie; ++i) {
    +           if (CallInst* callInst = dyn_cast<CallInst>(&*i)) {
    +             // We know we've encountered a call instruction, so we
    +             // need to determine if it's a call to the
    +             // function pointed to by m_func or not.
    +             if (callInst->getCalledFunction() == targetFunc)
    +               ++callCounter;
    +           }
    +         }
    +       }
    +     }
    + 
    +   private:
    +     unsigned callCounter;
    + };
    + 
    +
    + +
    + + + + +
    + +

    You may have noticed that the previous example was a bit oversimplified in + that it did not deal with call sites generated by 'invoke' instructions. In + this, and in other situations, you may find that you want to treat + CallInsts and InvokeInsts the same way, even though their + most-specific common base class is Instruction, which includes lots of + less closely-related things. For these cases, LLVM provides a handy wrapper + class called CallSite. + It is essentially a wrapper around an Instruction pointer, with some + methods that provide functionality common to CallInsts and + InvokeInsts.

    + +

    This class has "value semantics": it should be passed by value, not by + reference and it should not be dynamically allocated or deallocated using + operator new or operator delete. It is efficiently copyable, + assignable and constructable, with costs equivalents to that of a bare pointer. + If you look at its definition, it has only a single pointer member.

    + +
    + + + + +
    + +

    Frequently, we might have an instance of the Value Class and we want to + determine which Users use the Value. The list of all + Users of a particular Value is called a def-use chain. + For example, let's say we have a Function* named F to a + particular function foo. Finding all of the instructions that + use foo is as simple as iterating over the def-use chain + of F:

    + +
    +
    + Function *F = ...;
    + 
    + for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i)
    +   if (Instruction *Inst = dyn_cast<Instruction>(*i)) {
    +     llvm::cerr << "F is used in instruction:\n";
    +     llvm::cerr << *Inst << "\n";
    +   }
    + 
    +
    + +

    Alternately, it's common to have an instance of the User Class and need to know what + Values are used by it. The list of all Values used by a + User is known as a use-def chain. Instances of class + Instruction are common Users, so we might want to iterate over + all of the values that a particular instruction uses (that is, the operands of + the particular Instruction):

    + +
    +
    + Instruction *pi = ...;
    + 
    + for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
    +   Value *v = *i;
    +   // ...
    + }
    + 
    +
    + + + +
    + + + + +
    + +

    Iterating over the predecessors and successors of a block is quite easy + with the routines defined in "llvm/Support/CFG.h". Just use code like + this to iterate over all predecessors of BB:

    + +
    +
    + #include "llvm/Support/CFG.h"
    + BasicBlock *BB = ...;
    + 
    + for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++PI) {
    +   BasicBlock *Pred = *PI;
    +   // ...
    + }
    + 
    +
    + +

    Similarly, to iterate over successors use + succ_iterator/succ_begin/succ_end.

    + +
    + + + + + +
    + +

    There are some primitive transformation operations present in the LLVM + infrastructure that are worth knowing about. When performing + transformations, it's fairly common to manipulate the contents of basic + blocks. This section describes some of the common methods for doing so + and gives example code.

    + +
    + + + + +
    + +

    Instantiating Instructions

    + +

    Creation of Instructions is straight-forward: simply call the + constructor for the kind of instruction to instantiate and provide the necessary + parameters. For example, an AllocaInst only requires a + (const-ptr-to) Type. Thus:

    + +
    +
    + AllocaInst* ai = new AllocaInst(Type::Int32Ty);
    + 
    +
    + +

    will create an AllocaInst instance that represents the allocation of + one integer in the current stack frame, at run time. Each Instruction + subclass is likely to have varying default parameters which change the semantics + of the instruction, so refer to the doxygen documentation for the subclass of + Instruction that you're interested in instantiating.

    + +

    Naming values

    + +

    It is very useful to name the values of instructions when you're able to, as + this facilitates the debugging of your transformations. If you end up looking + at generated LLVM machine code, you definitely want to have logical names + associated with the results of instructions! By supplying a value for the + Name (default) parameter of the Instruction constructor, you + associate a logical name with the result of the instruction's execution at + run time. For example, say that I'm writing a transformation that dynamically + allocates space for an integer on the stack, and that integer is going to be + used as some kind of index by some other code. To accomplish this, I place an + AllocaInst at the first point in the first BasicBlock of some + Function, and I'm intending to use it within the same + Function. I might do:

    + +
    +
    + AllocaInst* pa = new AllocaInst(Type::Int32Ty, 0, "indexLoc");
    + 
    +
    + +

    where indexLoc is now the logical name of the instruction's + execution value, which is a pointer to an integer on the run time stack.

    + +

    Inserting instructions

    + +

    There are essentially two ways to insert an Instruction + into an existing sequence of instructions that form a BasicBlock:

    + +
      +
    • Insertion into an explicit instruction list + +

      Given a BasicBlock* pb, an Instruction* pi within that + BasicBlock, and a newly-created instruction we wish to insert + before *pi, we do the following:

      + +
      +
      + BasicBlock *pb = ...;
      + Instruction *pi = ...;
      + Instruction *newInst = new Instruction(...);
      + 
      + pb->getInstList().insert(pi, newInst); // Inserts newInst before pi in pb
      + 
      +
      + +

      Appending to the end of a BasicBlock is so common that + the Instruction class and Instruction-derived + classes provide constructors which take a pointer to a + BasicBlock to be appended to. For example code that + looked like:

      + +
      +
      + BasicBlock *pb = ...;
      + Instruction *newInst = new Instruction(...);
      + 
      + pb->getInstList().push_back(newInst); // Appends newInst to pb
      + 
      +
      + +

      becomes:

      + +
      +
      + BasicBlock *pb = ...;
      + Instruction *newInst = new Instruction(..., pb);
      + 
      +
      + +

      which is much cleaner, especially if you are creating + long instruction streams.

    • + +
    • Insertion into an implicit instruction list + +

      Instruction instances that are already in BasicBlocks + are implicitly associated with an existing instruction list: the instruction + list of the enclosing basic block. Thus, we could have accomplished the same + thing as the above code without being given a BasicBlock by doing: +

      + +
      +
      + Instruction *pi = ...;
      + Instruction *newInst = new Instruction(...);
      + 
      + pi->getParent()->getInstList().insert(pi, newInst);
      + 
      +
      + +

      In fact, this sequence of steps occurs so frequently that the + Instruction class and Instruction-derived classes provide + constructors which take (as a default parameter) a pointer to an + Instruction which the newly-created Instruction should + precede. That is, Instruction constructors are capable of + inserting the newly-created instance into the BasicBlock of a + provided instruction, immediately before that instruction. Using an + Instruction constructor with a insertBefore (default) + parameter, the above code becomes:

      + +
      +
      + Instruction* pi = ...;
      + Instruction* newInst = new Instruction(..., pi);
      + 
      +
      + +

      which is much cleaner, especially if you're creating a lot of + instructions and adding them to BasicBlocks.

    • +
    + +
    + + + + +
    + +

    Deleting an instruction from an existing sequence of instructions that form a + BasicBlock is very straight-forward. First, + you must have a pointer to the instruction that you wish to delete. Second, you + need to obtain the pointer to that instruction's basic block. You use the + pointer to the basic block to get its list of instructions and then use the + erase function to remove your instruction. For example:

    + +
    +
    + Instruction *I = .. ;
    + I->eraseFromParent();
    + 
    +
    + +
    + + + + +
    + +

    Replacing individual instructions

    + +

    Including "llvm/Transforms/Utils/BasicBlockUtils.h" + permits use of two very useful replace functions: ReplaceInstWithValue + and ReplaceInstWithInst.

    + +

    Deleting Instructions

    + +
      +
    • ReplaceInstWithValue + +

      This function replaces all uses of a given instruction with a value, + and then removes the original instruction. The following example + illustrates the replacement of the result of a particular + AllocaInst that allocates memory for a single integer with a null + pointer to an integer.

      + +
      +
      + AllocaInst* instToReplace = ...;
      + BasicBlock::iterator ii(instToReplace);
      + 
      + ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii,
      +                      Constant::getNullValue(PointerType::getUnqual(Type::Int32Ty)));
      + 
    • + +
    • ReplaceInstWithInst + +

      This function replaces a particular instruction with another + instruction, inserting the new instruction into the basic block at the + location where the old instruction was, and replacing any uses of the old + instruction with the new instruction. The following example illustrates + the replacement of one AllocaInst with another.

      + +
      +
      + AllocaInst* instToReplace = ...;
      + BasicBlock::iterator ii(instToReplace);
      + 
      + ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii,
      +                     new AllocaInst(Type::Int32Ty, 0, "ptrToReplacedInt"));
      + 
    • +
    + +

    Replacing multiple uses of Users and Values

    + +

    You can use Value::replaceAllUsesWith and + User::replaceUsesOfWith to change more than one use at a time. See the + doxygen documentation for the Value Class + and User Class, respectively, for more + information.

    + + + +
    + + + + +
    + +

    Deleting a global variable from a module is just as easy as deleting an + Instruction. First, you must have a pointer to the global variable that you wish + to delete. You use this pointer to erase it from its parent, the module. + For example:

    + +
    +
    + GlobalVariable *GV = .. ;
    + 
    + GV->eraseFromParent();
    + 
    +
    + +
    + + + + + +
    +

    + This section describes some of the advanced or obscure API's that most clients + do not need to be aware of. These API's tend manage the inner workings of the + LLVM system, and only need to be accessed in unusual circumstances. +

    +
    + + + + +
    + +

    + The LLVM type system has a very simple goal: allow clients to compare types for + structural equality with a simple pointer comparison (aka a shallow compare). + This goal makes clients much simpler and faster, and is used throughout the LLVM + system. +

    + +

    + Unfortunately achieving this goal is not a simple matter. In particular, + recursive types and late resolution of opaque types makes the situation very + difficult to handle. Fortunately, for the most part, our implementation makes + most clients able to be completely unaware of the nasty internal details. The + primary case where clients are exposed to the inner workings of it are when + building a recursive type. In addition to this case, the LLVM bitcode reader, + assembly parser, and linker also have to be aware of the inner workings of this + system. +

    + +

    + For our purposes below, we need three concepts. First, an "Opaque Type" is + exactly as defined in the language + reference. Second an "Abstract Type" is any type which includes an + opaque type as part of its type graph (for example "{ opaque, i32 }"). + Third, a concrete type is a type that is not an abstract type (e.g. "{ i32, + float }"). +

    + +
    + + + + +
    + +

    + Because the most common question is "how do I build a recursive type with LLVM", + we answer it now and explain it as we go. Here we include enough to cause this + to be emitted to an output .ll file: +

    + +
    +
    + %mylist = type { %mylist*, i32 }
    + 
    +
    + +

    + To build this, use the following LLVM APIs: +

    + +
    +
    + // Create the initial outer struct
    + PATypeHolder StructTy = OpaqueType::get();
    + std::vector<const Type*> Elts;
    + Elts.push_back(PointerType::getUnqual(StructTy));
    + Elts.push_back(Type::Int32Ty);
    + StructType *NewSTy = StructType::get(Elts);
    + 
    + // At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that
    + // the struct and the opaque type are actually the same.
    + cast<OpaqueType>(StructTy.get())->refineAbstractTypeTo(NewSTy);
    + 
    + // NewSTy is potentially invalidated, but StructTy (a PATypeHolder) is
    + // kept up-to-date
    + NewSTy = cast<StructType>(StructTy.get());
    + 
    + // Add a name for the type to the module symbol table (optional)
    + MyModule->addTypeName("mylist", NewSTy);
    + 
    +
    + +

    + This code shows the basic approach used to build recursive types: build a + non-recursive type using 'opaque', then use type unification to close the cycle. + The type unification step is performed by the refineAbstractTypeTo method, which is + described next. After that, we describe the PATypeHolder class. +

    + +
    + + + + +
    +

    + The refineAbstractTypeTo method starts the type unification process. + While this method is actually a member of the DerivedType class, it is most + often used on OpaqueType instances. Type unification is actually a recursive + process. After unification, types can become structurally isomorphic to + existing types, and all duplicates are deleted (to preserve pointer equality). +

    + +

    + In the example above, the OpaqueType object is definitely deleted. + Additionally, if there is an "{ \2*, i32}" type already created in the system, + the pointer and struct type created are also deleted. Obviously whenever + a type is deleted, any "Type*" pointers in the program are invalidated. As + such, it is safest to avoid having any "Type*" pointers to abstract types + live across a call to refineAbstractTypeTo (note that non-abstract + types can never move or be deleted). To deal with this, the PATypeHolder class is used to maintain a stable + reference to a possibly refined type, and the AbstractTypeUser class is used to update more + complex datastructures. +

    + +
    + + + + +
    +

    + PATypeHolder is a form of a "smart pointer" for Type objects. When VMCore + happily goes about nuking types that become isomorphic to existing types, it + automatically updates all PATypeHolder objects to point to the new type. In the + example above, this allows the code to maintain a pointer to the resultant + resolved recursive type, even though the Type*'s are potentially invalidated. +

    + +

    + PATypeHolder is an extremely light-weight object that uses a lazy union-find + implementation to update pointers. For example the pointer from a Value to its + Type is maintained by PATypeHolder objects. +

    + +
    + + + + +
    + +

    + Some data structures need more to perform more complex updates when types get + resolved. To support this, a class can derive from the AbstractTypeUser class. + This class + allows it to get callbacks when certain types are resolved. To register to get + callbacks for a particular type, the DerivedType::{add/remove}AbstractTypeUser + methods can be called on a type. Note that these methods only work for + abstract types. Concrete types (those that do not include any opaque + objects) can never be refined. +

    +
    + + + + + +
    +

    The + ValueSymbolTable class provides a symbol table that the Function and + Module classes use for naming value definitions. The symbol table + can provide a name for any Value. + The + TypeSymbolTable class is used by the Module class to store + names for types.

    + +

    Note that the SymbolTable class should not be directly accessed + by most clients. It should only be used when iteration over the symbol table + names themselves are required, which is very special purpose. Note that not + all LLVM + Values have names, and those without names (i.e. they have + an empty name) do not exist in the symbol table. +

    + +

    These symbol tables support iteration over the values/types in the symbol + table with begin/end/iterator and supports querying to see if a + specific name is in the symbol table (with lookup). The + ValueSymbolTable class exposes no public mutator methods, instead, + simply call setName on a value, which will autoinsert it into the + appropriate symbol table. For types, use the Module::addTypeName method to + insert entries into the symbol table.

    + +
    + + + + + + +
    +

    The + User class provides a basis for expressing the ownership of User + towards other + Values. The + Use helper class is employed to do the bookkeeping and to facilitate O(1) + addition and removal.

    + + + + +
    +

    + A subclass of User can choose between incorporating its Use objects + or refer to them out-of-line by means of a pointer. A mixed variant + (some Uses inline others hung off) is impractical and breaks the invariant + that the Use objects belonging to the same User form a contiguous array. +

    +
    + +

    + We have 2 different layouts in the User (sub)classes: +

      +
    • Layout a) + The Use object(s) are inside (resp. at fixed offset) of the User + object and there are a fixed number of them.

      + +
    • Layout b) + The Use object(s) are referenced by a pointer to an + array from the User object and there may be a variable + number of them.

      +
    +

    + As of v2.4 each layout still possesses a direct pointer to the + start of the array of Uses. Though not mandatory for layout a), + we stick to this redundancy for the sake of simplicity. + The User object also stores the number of Use objects it + has. (Theoretically this information can also be calculated + given the scheme presented below.)

    +

    + Special forms of allocation operators (operator new) + enforce the following memory layouts:

    + +
      +
    • Layout a) is modelled by prepending the User object by the Use[] array.

      + +
      + ...---.---.---.---.-------...
      +   | P | P | P | P | User
      + '''---'---'---'---'-------'''
      + 
      + +
    • Layout b) is modelled by pointing at the Use[] array.

      +
      + .-------...
      + | User
      + '-------'''
      +     |
      +     v
      +     .---.---.---.---...
      +     | P | P | P | P |
      +     '---'---'---'---'''
      + 
      +
    + (In the above figures 'P' stands for the Use** that + is stored in each Use object in the member Use::Prev) + + + + +
    +

    + Since the Use objects are deprived of the direct (back)pointer to + their User objects, there must be a fast and exact method to + recover it. This is accomplished by the following scheme:

    +
    + + A bit-encoding in the 2 LSBits (least significant bits) of the Use::Prev allows to find the + start of the User object: +
      +
    • 00 —> binary digit 0
    • +
    • 01 —> binary digit 1
    • +
    • 10 —> stop and calculate (s)
    • +
    • 11 —> full stop (S)
    • +
    +

    + Given a Use*, all we have to do is to walk till we get + a stop and we either have a User immediately behind or + we have to walk to the next stop picking up digits + and calculating the offset:

    +
    + .---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.----------------
    + | 1 | s | 1 | 0 | 1 | 0 | s | 1 | 1 | 0 | s | 1 | 1 | s | 1 | S | User (or User*)
    + '---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'----------------
    +     |+15                |+10            |+6         |+3     |+1
    +     |                   |               |           |       |__>
    +     |                   |               |           |__________>
    +     |                   |               |______________________>
    +     |                   |______________________________________>
    +     |__________________________________________________________>
    + 
    +

    + Only the significant number of bits need to be stored between the + stops, so that the worst case is 20 memory accesses when there are + 1000 Use objects associated with a User.

    + + + + +
    +

    + The following literate Haskell fragment demonstrates the concept:

    +
    + +
    +
    + > import Test.QuickCheck
    + > 
    + > digits :: Int -> [Char] -> [Char]
    + > digits 0 acc = '0' : acc
    + > digits 1 acc = '1' : acc
    + > digits n acc = digits (n `div` 2) $ digits (n `mod` 2) acc
    + > 
    + > dist :: Int -> [Char] -> [Char]
    + > dist 0 [] = ['S']
    + > dist 0 acc = acc
    + > dist 1 acc = let r = dist 0 acc in 's' : digits (length r) r
    + > dist n acc = dist (n - 1) $ dist 1 acc
    + > 
    + > takeLast n ss = reverse $ take n $ reverse ss
    + > 
    + > test = takeLast 40 $ dist 20 []
    + > 
    + 
    +
    +

    + Printing <test> gives: "1s100000s11010s10100s1111s1010s110s11s1S"

    +

    + The reverse algorithm computes the length of the string just by examining + a certain prefix:

    + +
    +
    + > pref :: [Char] -> Int
    + > pref "S" = 1
    + > pref ('s':'1':rest) = decode 2 1 rest
    + > pref (_:rest) = 1 + pref rest
    + > 
    + > decode walk acc ('0':rest) = decode (walk + 1) (acc * 2) rest
    + > decode walk acc ('1':rest) = decode (walk + 1) (acc * 2 + 1) rest
    + > decode walk acc _ = walk + acc
    + > 
    + 
    +
    +

    + Now, as expected, printing <pref test> gives 40.

    +

    + We can quickCheck this with following property:

    + +
    +
    + > testcase = dist 2000 []
    + > testcaseLength = length testcase
    + > 
    + > identityProp n = n > 0 && n <= testcaseLength ==> length arr == pref arr
    + >     where arr = takeLast n testcase
    + > 
    + 
    +
    +

    + As expected <quickCheck identityProp> gives:

    + +
    + *Main> quickCheck identityProp
    + OK, passed 100 tests.
    + 
    +

    + Let's be a bit more exhaustive:

    + +
    +
    + > 
    + > deepCheck p = check (defaultConfig { configMaxTest = 500 }) p
    + > 
    + 
    +
    +

    + And here is the result of <deepCheck identityProp>:

    + +
    + *Main> deepCheck identityProp
    + OK, passed 500 tests.
    + 
    + + + + +

    + To maintain the invariant that the 2 LSBits of each Use** in Use + never change after being set up, setters of Use::Prev must re-tag the + new Use** on every modification. Accordingly getters must strip the + tag bits.

    +

    + For layout b) instead of the User we find a pointer (User* with LSBit set). + Following this pointer brings us to the User. A portable trick ensures + that the first bytes of User (if interpreted as a pointer) never has + the LSBit set. (Portability is relying on the fact that all known compilers place the + vptr in the first word of the instances.)

    + +
    + + + + + +
    +

    #include "llvm/Type.h" +
    doxygen info: Type Class

    + +

    The Core LLVM classes are the primary means of representing the program + being inspected or transformed. The core LLVM classes are defined in + header files in the include/llvm/ directory, and implemented in + the lib/VMCore directory.

    + +
    + + + + +
    + +

    Type is a superclass of all type classes. Every Value has + a Type. Type cannot be instantiated directly but only + through its subclasses. Certain primitive types (VoidType, + LabelType, FloatType and DoubleType) have hidden + subclasses. They are hidden because they offer no useful functionality beyond + what the Type class offers except to distinguish themselves from + other subclasses of Type.

    +

    All other types are subclasses of DerivedType. Types can be + named, but this is not a requirement. There exists exactly + one instance of a given shape at any one time. This allows type equality to + be performed with address equality of the Type Instance. That is, given two + Type* values, the types are identical if the pointers are identical. +

    +
    + + + + +
    + +
      +
    • bool isInteger() const: Returns true for any integer type.
    • + +
    • bool isFloatingPoint(): Return true if this is one of the two + floating point types.
    • + +
    • bool isAbstract(): Return true if the type is abstract (contains + an OpaqueType anywhere in its definition).
    • + +
    • bool isSized(): Return true if the type has known size. Things + that don't have a size are abstract types, labels and void.
    • + +
    +
    + + + +
    +
    +
    IntegerType
    +
    Subclass of DerivedType that represents integer types of any bit width. + Any bit width between IntegerType::MIN_INT_BITS (1) and + IntegerType::MAX_INT_BITS (~8 million) can be represented. +
      +
    • static const IntegerType* get(unsigned NumBits): get an integer + type of a specific bit width.
    • +
    • unsigned getBitWidth() const: Get the bit width of an integer + type.
    • +
    +
    +
    SequentialType
    +
    This is subclassed by ArrayType and PointerType +
      +
    • const Type * getElementType() const: Returns the type of each + of the elements in the sequential type.
    • +
    +
    +
    ArrayType
    +
    This is a subclass of SequentialType and defines the interface for array + types. +
      +
    • unsigned getNumElements() const: Returns the number of + elements in the array.
    • +
    +
    +
    PointerType
    +
    Subclass of SequentialType for pointer types.
    +
    VectorType
    +
    Subclass of SequentialType for vector types. A + vector type is similar to an ArrayType but is distinguished because it is + a first class type wherease ArrayType is not. Vector types are used for + vector operations and are usually small vectors of of an integer or floating + point type.
    +
    StructType
    +
    Subclass of DerivedTypes for struct types.
    +
    FunctionType
    +
    Subclass of DerivedTypes for function types. +
      +
    • bool isVarArg() const: Returns true if its a vararg + function
    • +
    • const Type * getReturnType() const: Returns the + return type of the function.
    • +
    • const Type * getParamType (unsigned i): Returns + the type of the ith parameter.
    • +
    • const unsigned getNumParams() const: Returns the + number of formal parameters.
    • +
    +
    +
    OpaqueType
    +
    Sublcass of DerivedType for abstract types. This class + defines no content and is used as a placeholder for some other type. Note + that OpaqueType is used (temporarily) during type resolution for forward + references of types. Once the referenced type is resolved, the OpaqueType + is replaced with the actual type. OpaqueType can also be used for data + abstraction. At link time opaque types can be resolved to actual types + of the same name.
    +
    +
    + + + + + + +
    + +

    #include "llvm/Module.h"
    doxygen info: + Module Class

    + +

    The Module class represents the top level structure present in LLVM + programs. An LLVM module is effectively either a translation unit of the + original program or a combination of several translation units merged by the + linker. The Module class keeps track of a list of Functions, a list of GlobalVariables, and a SymbolTable. Additionally, it contains a few + helpful member functions that try to make common operations easy.

    + +
    + + + + +
    + +
      +
    • Module::Module(std::string name = "")
    • +
    + +

    Constructing a Module is easy. You can optionally + provide a name for it (probably based on the name of the translation unit).

    + +
      +
    • Module::iterator - Typedef for function list iterator
      + Module::const_iterator - Typedef for const_iterator.
      + + begin(), end() + size(), empty() + +

      These are forwarding methods that make it easy to access the contents of + a Module object's Function + list.

    • + +
    • Module::FunctionListType &getFunctionList() + +

      Returns the list of Functions. This is + necessary to use when you need to update the list or perform a complex + action that doesn't have a forwarding method.

      + +

    • +
    + +
    + +
      +
    • Module::global_iterator - Typedef for global variable list iterator
      + + Module::const_global_iterator - Typedef for const_iterator.
      + + global_begin(), global_end() + global_size(), global_empty() + +

      These are forwarding methods that make it easy to access the contents of + a Module object's GlobalVariable list.

    • + +
    • Module::GlobalListType &getGlobalList() + +

      Returns the list of GlobalVariables. This is necessary to + use when you need to update the list or perform a complex action that + doesn't have a forwarding method.

      + +

    • +
    + +
    + + + +
    + +
      +
    • Function *getFunction(const std::string + &Name, const FunctionType *Ty) + +

      Look up the specified function in the Module SymbolTable. If it does not exist, return + null.

    • + +
    • Function *getOrInsertFunction(const + std::string &Name, const FunctionType *T) + +

      Look up the specified function in the Module SymbolTable. If it does not exist, add an + external declaration for the function and return it.

    • + +
    • std::string getTypeName(const Type *Ty) + +

      If there is at least one entry in the SymbolTable for the specified Type, return it. Otherwise return the empty + string.

    • + +
    • bool addTypeName(const std::string &Name, const Type *Ty) + +

      Insert an entry in the SymbolTable + mapping Name to Ty. If there is already an entry for this + name, true is returned and the SymbolTable is not modified.

    • +
    + +
    + + + + + +
    + +

    #include "llvm/Value.h" +
    + doxygen info: Value Class

    + +

    The Value class is the most important class in the LLVM Source + base. It represents a typed value that may be used (among other things) as an + operand to an instruction. There are many different types of Values, + such as Constants,Arguments. Even Instructions and Functions are Values.

    + +

    A particular Value may be used many times in the LLVM representation + for a program. For example, an incoming argument to a function (represented + with an instance of the Argument class) is "used" by + every instruction in the function that references the argument. To keep track + of this relationship, the Value class keeps a list of all of the Users that is using it (the User class is a base class for all nodes in the LLVM + graph that can refer to Values). This use list is how LLVM represents + def-use information in the program, and is accessible through the use_* + methods, shown below.

    + +

    Because LLVM is a typed representation, every LLVM Value is typed, + and this Type is available through the getType() + method. In addition, all LLVM values can be named. The "name" of the + Value is a symbolic string printed in the LLVM code:

    + +
    +
    + %foo = add i32 1, 2
    + 
    +
    + +

    The name of this instruction is "foo". NOTE + that the name of any value may be missing (an empty string), so names should + ONLY be used for debugging (making the source code easier to read, + debugging printouts), they should not be used to keep track of values or map + between them. For this purpose, use a std::map of pointers to the + Value itself instead.

    + +

    One important aspect of LLVM is that there is no distinction between an SSA + variable and the operation that produces it. Because of this, any reference to + the value produced by an instruction (or the value available as an incoming + argument, for example) is represented as a direct pointer to the instance of + the class that + represents this value. Although this may take some getting used to, it + simplifies the representation and makes it easier to manipulate.

    + +
    + + + + +
    + +
      +
    • Value::use_iterator - Typedef for iterator over the + use-list
      + Value::use_const_iterator - Typedef for const_iterator over + the use-list
      + unsigned use_size() - Returns the number of users of the + value.
      + bool use_empty() - Returns true if there are no users.
      + use_iterator use_begin() - Get an iterator to the start of + the use-list.
      + use_iterator use_end() - Get an iterator to the end of the + use-list.
      + User *use_back() - Returns the last + element in the list. +

      These methods are the interface to access the def-use + information in LLVM. As with all other iterators in LLVM, the naming + conventions follow the conventions defined by the STL.

      +
    • +
    • Type *getType() const +

      This method returns the Type of the Value.

      +
    • +
    • bool hasName() const
      + std::string getName() const
      + void setName(const std::string &Name) +

      This family of methods is used to access and assign a name to a Value, + be aware of the precaution above.

      +
    • +
    • void replaceAllUsesWith(Value *V) + +

      This method traverses the use list of a Value changing all Users of the current value to refer to + "V" instead. For example, if you detect that an instruction always + produces a constant value (for example through constant folding), you can + replace all uses of the instruction with the constant like this:

      + +
      +
      + Inst->replaceAllUsesWith(ConstVal);
      + 
      +
      + +
    + +
    + + + + +
    + +

    + #include "llvm/User.h"
    + doxygen info: User Class
    + Superclass: Value

    + +

    The User class is the common base class of all LLVM nodes that may + refer to Values. It exposes a list of "Operands" + that are all of the Values that the User is + referring to. The User class itself is a subclass of + Value.

    + +

    The operands of a User point directly to the LLVM Value that it refers to. Because LLVM uses Static + Single Assignment (SSA) form, there can only be one definition referred to, + allowing this direct connection. This connection provides the use-def + information in LLVM.

    + +
    + + + + +
    + +

    The User class exposes the operand list in two ways: through + an index access interface and through an iterator based interface.

    + +
      +
    • Value *getOperand(unsigned i)
      + unsigned getNumOperands() +

      These two methods expose the operands of the User in a + convenient form for direct access.

    • + +
    • User::op_iterator - Typedef for iterator over the operand + list
      + op_iterator op_begin() - Get an iterator to the start of + the operand list.
      + op_iterator op_end() - Get an iterator to the end of the + operand list. +

      Together, these methods make up the iterator based interface to + the operands of a User.

    • +
    + +
    + + + + +
    + +

    #include "llvm/Instruction.h"
    + doxygen info: Instruction Class
    + Superclasses: User, Value

    + +

    The Instruction class is the common base class for all LLVM + instructions. It provides only a few methods, but is a very commonly used + class. The primary data tracked by the Instruction class itself is the + opcode (instruction type) and the parent BasicBlock the Instruction is embedded + into. To represent a specific type of instruction, one of many subclasses of + Instruction are used.

    + +

    Because the Instruction class subclasses the User class, its operands can be accessed in the same + way as for other Users (with the + getOperand()/getNumOperands() and + op_begin()/op_end() methods).

    An important file for + the Instruction class is the llvm/Instruction.def file. This + file contains some meta-data about the various different types of instructions + in LLVM. It describes the enum values that are used as opcodes (for example + Instruction::Add and Instruction::ICmp), as well as the + concrete sub-classes of Instruction that implement the instruction (for + example BinaryOperator and CmpInst). Unfortunately, the use of macros in + this file confuses doxygen, so these enum values don't show up correctly in the + doxygen output.

    + +
    + + + +
    +
      +
    • BinaryOperator +

      This subclasses represents all two operand instructions whose operands + must be the same type, except for the comparison instructions.

    • +
    • CastInst +

      This subclass is the parent of the 12 casting instructions. It provides + common operations on cast instructions.

      +
    • CmpInst +

      This subclass respresents the two comparison instructions, + ICmpInst (integer opreands), and + FCmpInst (floating point operands).

      +
    • TerminatorInst +

      This subclass is the parent of all terminator instructions (those which + can terminate a block).

      +
    +
    + + + + +
    + +
      +
    • BasicBlock *getParent() +

      Returns the BasicBlock that + this Instruction is embedded into.

    • +
    • bool mayWriteToMemory() +

      Returns true if the instruction writes to memory, i.e. it is a + call,free,invoke, or store.

    • +
    • unsigned getOpcode() +

      Returns the opcode for the Instruction.

    • +
    • Instruction *clone() const +

      Returns another instance of the specified instruction, identical + in all ways to the original except that the instruction has no parent + (ie it's not embedded into a BasicBlock), + and it has no name

    • +
    + +
    + + + + +
    + +

    Constant represents a base class for different types of constants. It + is subclassed by ConstantInt, ConstantArray, etc. for representing + the various types of Constants. GlobalValue is also + a subclass, which represents the address of a global variable or function. +

    + +
    + + +
    Important Subclasses of Constant
    +
    +
      +
    • ConstantInt : This subclass of Constant represents an integer constant of + any width. +
        +
      • const APInt& getValue() const: Returns the underlying + value of this constant, an APInt value.
      • +
      • int64_t getSExtValue() const: Converts the underlying APInt + value to an int64_t via sign extension. If the value (not the bit width) + of the APInt is too large to fit in an int64_t, an assertion will result. + For this reason, use of this method is discouraged.
      • +
      • uint64_t getZExtValue() const: Converts the underlying APInt + value to a uint64_t via zero extension. IF the value (not the bit width) + of the APInt is too large to fit in a uint64_t, an assertion will result. + For this reason, use of this method is discouraged.
      • +
      • static ConstantInt* get(const APInt& Val): Returns the + ConstantInt object that represents the value provided by Val. + The type is implied as the IntegerType that corresponds to the bit width + of Val.
      • +
      • static ConstantInt* get(const Type *Ty, uint64_t Val): + Returns the ConstantInt object that represents the value provided by + Val for integer type Ty.
      • +
      +
    • +
    • ConstantFP : This class represents a floating point constant. +
        +
      • double getValue() const: Returns the underlying value of + this constant.
      • +
      +
    • +
    • ConstantArray : This represents a constant array. +
        +
      • const std::vector<Use> &getValues() const: Returns + a vector of component constants that makeup this array.
      • +
      +
    • +
    • ConstantStruct : This represents a constant struct. +
        +
      • const std::vector<Use> &getValues() const: Returns + a vector of component constants that makeup this array.
      • +
      +
    • +
    • GlobalValue : This represents either a global variable or a function. In + either case, the value is a constant fixed address (after linking). +
    • +
    +
    + + + + + +
    + +

    #include "llvm/GlobalValue.h"
    + doxygen info: GlobalValue + Class
    + Superclasses: Constant, + User, Value

    + +

    Global values (GlobalVariables or Functions) are the only LLVM values that are + visible in the bodies of all Functions. + Because they are visible at global scope, they are also subject to linking with + other globals defined in different translation units. To control the linking + process, GlobalValues know their linkage rules. Specifically, + GlobalValues know whether they have internal or external linkage, as + defined by the LinkageTypes enumeration.

    + +

    If a GlobalValue has internal linkage (equivalent to being + static in C), it is not visible to code outside the current translation + unit, and does not participate in linking. If it has external linkage, it is + visible to external code, and does participate in linking. In addition to + linkage information, GlobalValues keep track of which Module they are currently part of.

    + +

    Because GlobalValues are memory objects, they are always referred to + by their address. As such, the Type of a + global is always a pointer to its contents. It is important to remember this + when using the GetElementPtrInst instruction because this pointer must + be dereferenced first. For example, if you have a GlobalVariable (a + subclass of GlobalValue) that is an array of 24 ints, type [24 x + i32], then the GlobalVariable is a pointer to that array. Although + the address of the first element of this array and the value of the + GlobalVariable are the same, they have different types. The + GlobalVariable's type is [24 x i32]. The first element's type + is i32. Because of this, accessing a global value requires you to + dereference the pointer with GetElementPtrInst first, then its elements + can be accessed. This is explained in the LLVM + Language Reference Manual.

    + +
    + + + + +
    + +
      +
    • bool hasInternalLinkage() const
      + bool hasExternalLinkage() const
      + void setInternalLinkage(bool HasInternalLinkage) +

      These methods manipulate the linkage characteristics of the GlobalValue.

      +

      +
    • +
    • Module *getParent() +

      This returns the Module that the + GlobalValue is currently embedded into.

    • +
    + +
    + + + + +
    + +

    #include "llvm/Function.h"
    doxygen + info: Function Class
    + Superclasses: GlobalValue, + Constant, + User, + Value

    + +

    The Function class represents a single procedure in LLVM. It is + actually one of the more complex classes in the LLVM heirarchy because it must + keep track of a large amount of data. The Function class keeps track + of a list of BasicBlocks, a list of formal + Arguments, and a + SymbolTable.

    + +

    The list of BasicBlocks is the most + commonly used part of Function objects. The list imposes an implicit + ordering of the blocks in the function, which indicate how the code will be + layed out by the backend. Additionally, the first BasicBlock is the implicit entry node for the + Function. It is not legal in LLVM to explicitly branch to this initial + block. There are no implicit exit nodes, and in fact there may be multiple exit + nodes from a single Function. If the BasicBlock list is empty, this indicates that + the Function is actually a function declaration: the actual body of the + function hasn't been linked in yet.

    + +

    In addition to a list of BasicBlocks, the + Function class also keeps track of the list of formal Arguments that the function receives. This + container manages the lifetime of the Argument + nodes, just like the BasicBlock list does for + the BasicBlocks.

    + +

    The SymbolTable is a very rarely used + LLVM feature that is only used when you have to look up a value by name. Aside + from that, the SymbolTable is used + internally to make sure that there are not conflicts between the names of Instructions, BasicBlocks, or Arguments in the function body.

    + +

    Note that Function is a GlobalValue + and therefore also a Constant. The value of the function + is its address (after linking) which is guaranteed to be constant.

    +
    + + + + +
    + +
      +
    • Function(const FunctionType + *Ty, LinkageTypes Linkage, const std::string &N = "", Module* Parent = 0) + +

      Constructor used when you need to create new Functions to add + the the program. The constructor must specify the type of the function to + create and what type of linkage the function should have. The FunctionType argument + specifies the formal arguments and return value for the function. The same + FunctionType value can be used to + create multiple functions. The Parent argument specifies the Module + in which the function is defined. If this argument is provided, the function + will automatically be inserted into that module's list of + functions.

    • + +
    • bool isDeclaration() + +

      Return whether or not the Function has a body defined. If the + function is "external", it does not have a body, and thus must be resolved + by linking with a function defined in a different translation unit.

    • + +
    • Function::iterator - Typedef for basic block list iterator
      + Function::const_iterator - Typedef for const_iterator.
      + + begin(), end() + size(), empty() + +

      These are forwarding methods that make it easy to access the contents of + a Function object's BasicBlock + list.

    • + +
    • Function::BasicBlockListType &getBasicBlockList() + +

      Returns the list of BasicBlocks. This + is necessary to use when you need to update the list or perform a complex + action that doesn't have a forwarding method.

    • + +
    • Function::arg_iterator - Typedef for the argument list + iterator
      + Function::const_arg_iterator - Typedef for const_iterator.
      + + arg_begin(), arg_end() + arg_size(), arg_empty() + +

      These are forwarding methods that make it easy to access the contents of + a Function object's Argument + list.

    • + +
    • Function::ArgumentListType &getArgumentList() + +

      Returns the list of Arguments. This is + necessary to use when you need to update the list or perform a complex + action that doesn't have a forwarding method.

    • + +
    • BasicBlock &getEntryBlock() + +

      Returns the entry BasicBlock for the + function. Because the entry block for the function is always the first + block, this returns the first block of the Function.

    • + +
    • Type *getReturnType()
      + FunctionType *getFunctionType() + +

      This traverses the Type of the + Function and returns the return type of the function, or the FunctionType of the actual + function.

    • + +
    • SymbolTable *getSymbolTable() + +

      Return a pointer to the SymbolTable + for this Function.

    • +
    + +
    + + + + +
    + +

    #include "llvm/GlobalVariable.h" +
    + doxygen info: GlobalVariable + Class
    + Superclasses: GlobalValue, + Constant, + User, + Value

    + +

    Global variables are represented with the (suprise suprise) + GlobalVariable class. Like functions, GlobalVariables are also + subclasses of GlobalValue, and as such are + always referenced by their address (global values must live in memory, so their + "name" refers to their constant address). See + GlobalValue for more on this. Global + variables may have an initial value (which must be a + Constant), and if they have an initializer, + they may be marked as "constant" themselves (indicating that their contents + never change at runtime).

    +
    + + + + +
    + +
      +
    • GlobalVariable(const Type *Ty, bool + isConstant, LinkageTypes& Linkage, Constant + *Initializer = 0, const std::string &Name = "", Module* Parent = 0) + +

      Create a new global variable of the specified type. If + isConstant is true then the global variable will be marked as + unchanging for the program. The Linkage parameter specifies the type of + linkage (internal, external, weak, linkonce, appending) for the variable. If + the linkage is InternalLinkage, WeakLinkage, or LinkOnceLinkage,  then + the resultant global variable will have internal linkage. AppendingLinkage + concatenates together all instances (in different translation units) of the + variable into a single variable but is only applicable to arrays.  See + the LLVM Language Reference for + further details on linkage types. Optionally an initializer, a name, and the + module to put the variable into may be specified for the global variable as + well.

    • + +
    • bool isConstant() const + +

      Returns true if this is a global variable that is known not to + be modified at runtime.

    • + +
    • bool hasInitializer() + +

      Returns true if this GlobalVariable has an intializer.

    • + +
    • Constant *getInitializer() + +

      Returns the intial value for a GlobalVariable. It is not legal + to call this method if there is no initializer.

    • +
    + +
    + + + + + +
    + +

    #include "llvm/BasicBlock.h"
    + doxygen info: BasicBlock + Class
    + Superclass: Value

    + +

    This class represents a single entry multiple exit section of the code, + commonly known as a basic block by the compiler community. The + BasicBlock class maintains a list of Instructions, which form the body of the block. + Matching the language definition, the last element of this list of instructions + is always a terminator instruction (a subclass of the TerminatorInst class).

    + +

    In addition to tracking the list of instructions that make up the block, the + BasicBlock class also keeps track of the Function that it is embedded into.

    + +

    Note that BasicBlocks themselves are Values, because they are referenced by instructions + like branches and can go in the switch tables. BasicBlocks have type + label.

    + +
    + + + + +
    +
      + +
    • BasicBlock(const std::string &Name = "", Function *Parent = 0) + +

      The BasicBlock constructor is used to create new basic blocks for + insertion into a function. The constructor optionally takes a name for the new + block, and a Function to insert it into. If + the Parent parameter is specified, the new BasicBlock is + automatically inserted at the end of the specified Function, if not specified, the BasicBlock must be + manually inserted into the Function.

    • + +
    • BasicBlock::iterator - Typedef for instruction list iterator
      + BasicBlock::const_iterator - Typedef for const_iterator.
      + begin(), end(), front(), back(), + size(), empty() + STL-style functions for accessing the instruction list. + +

      These methods and typedefs are forwarding functions that have the same + semantics as the standard library methods of the same names. These methods + expose the underlying instruction list of a basic block in a way that is easy to + manipulate. To get the full complement of container operations (including + operations to update the list), you must use the getInstList() + method.

    • + +
    • BasicBlock::InstListType &getInstList() + +

      This method is used to get access to the underlying container that actually + holds the Instructions. This method must be used when there isn't a forwarding + function in the BasicBlock class for the operation that you would like + to perform. Because there are no forwarding functions for "updating" + operations, you need to use this if you want to update the contents of a + BasicBlock.

    • + +
    • Function *getParent() + +

      Returns a pointer to Function the block is + embedded into, or a null pointer if it is homeless.

    • + +
    • TerminatorInst *getTerminator() + +

      Returns a pointer to the terminator instruction that appears at the end of + the BasicBlock. If there is no terminator instruction, or if the last + instruction in the block is not a terminator, then a null pointer is + returned.

    • + +
    + +
    + + + + + +
    + +

    This subclass of Value defines the interface for incoming formal + arguments to a function. A Function maintains a list of its formal + arguments. An argument has a pointer to the parent Function.

    + +
    + + +
    +
    + Valid CSS + Valid HTML 4.01 Strict + + Dinakar Dhurjati and + Chris Lattner
    + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/Projects.html diff -c /dev/null llvm-www/releases/2.5/docs/Projects.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/Projects.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,460 ---- + + + + Creating an LLVM Project + + + + +
    Creating an LLVM Project
    + +
      +
    1. Overview
    2. +
    3. Create a project from the Sample Project
    4. +
    5. Source tree layout
    6. +
    7. Writing LLVM-style Makefiles +
        +
      1. Required Variables
      2. +
      3. Variables for Building Subdirectories
      4. +
      5. Variables for Building Libraries
      6. +
      7. Variables for Building Programs
      8. +
      9. Miscellaneous Variables
      10. +
    8. +
    9. Placement of object code
    10. +
    11. Further help
    12. +
    + +
    +

    Written by John Criswell

    +
    + + + + + +
    + +

    The LLVM build system is designed to facilitate the building of third party + projects that use LLVM header files, libraries, and tools. In order to use + these facilities, a Makefile from a project must do the following things:

    + +
      +
    1. Set make variables. There are several variables that a Makefile + needs to set to use the LLVM build system: +
        +
      • PROJECT_NAME - The name by which your project is known.
      • +
      • LLVM_SRC_ROOT - The root of the LLVM source tree.
      • +
      • LLVM_OBJ_ROOT - The root of the LLVM object tree.
      • +
      • PROJ_SRC_ROOT - The root of the project's source tree.
      • +
      • PROJ_OBJ_ROOT - The root of the project's object tree.
      • +
      • PROJ_INSTALL_ROOT - The root installation directory.
      • +
      • LEVEL - The relative path from the current directory to the + project's root ($PROJ_OBJ_ROOT).
      • +
    2. +
    3. Include Makefile.config from $(LLVM_OBJ_ROOT).
    4. +
    5. Include Makefile.rules from $(LLVM_SRC_ROOT).
    6. +
    + +

    There are two ways that you can set all of these variables:

    +
      +
    1. You can write your own Makefiles which hard-code these values.
    2. +
    3. You can use the pre-made LLVM sample project. This sample project + includes Makefiles, a configure script that can be used to configure the + location of LLVM, and the ability to support multiple object directories + from a single source directory.
    4. +
    + +

    This document assumes that you will base your project on the LLVM sample + project found in llvm/projects/sample. If you want to devise your own + build system, studying the sample project and LLVM Makefiles will probably + provide enough information on how to write your own Makefiles.

    + +
    + + + + + +
    + +

    Follow these simple steps to start your project:

    + +
      +
    1. Copy the llvm/projects/sample directory to any place of your + choosing. You can place it anywhere you like. Rename the directory to match + the name of your project.
    2. + +
    3. + If you downloaded LLVM using Subversion, remove all the directories named .svn + (and all the files therein) from your project's new source tree. This will + keep Subversion from thinking that your project is inside + llvm/trunk/projects/sample.
    4. + +
    5. Add your source code and Makefiles to your source tree.
    6. + +
    7. If you want your project to be configured with the configure script + then you need to edit autoconf/configure.ac as follows: +
        +
      • AC_INIT. Place the name of your project, its version number and + a contact email address for your project as the arguments to this macro
      • +
      • AC_CONFIG_AUX_DIR. If your project isn't in the + llvm/projects directory then you might need to adjust this so that + it specifies a relative path to the llvm/autoconf directory.
      • +
      • LLVM_CONFIG_PROJECT. Just leave this alone.
      • +
      • AC_CONFIG_SRCDIR. Specify a path to a file name that identifies + your project; or just leave it at Makefile.common.in
      • +
      • AC_CONFIG_FILES. Do not change.
      • +
      • AC_CONFIG_MAKEFILE. Use one of these macros for each Makefile + that your project uses. This macro arranges for your makefiles to be copied + from the source directory, unmodified, to the build directory.
      • +
      +
    8. + +
    9. After updating autoconf/configure.ac, regenerate the + configure script with these commands: + +
      +

      % cd autoconf
      + % ./AutoRegen.sh

      +
      + +

      You must be using Autoconf version 2.59 or later and your aclocal version + should 1.9 or later.

    10. + +
    11. Run configure in the directory in which you want to place + object code. Use the following options to tell your project where it + can find LLVM: + +
      +
      --with-llvmsrc=<directory>
      +
      Tell your project where the LLVM source tree is located.
      +

      --with-llvmobj=<directory>
      +
      Tell your project where the LLVM object tree is located.
      +

      --prefix=<directory>
      +
      Tell your project where it should get installed.
      +
      +
    + +

    That's it! Now all you have to do is type gmake (or make + if your on a GNU/Linux system) in the root of your object directory, and your + project should build.

    + +
    + + + + + +
    + +

    In order to use the LLVM build system, you will want to organize your + source code so that it can benefit from the build system's features. + Mainly, you want your source tree layout to look similar to the LLVM + source tree layout. The best way to do this is to just copy the + project tree from llvm/projects/sample and modify it to meet + your needs, but you can certainly add to it if you want.

    + +

    Underneath your top level directory, you should have the following + directories:

    + +
    +
    lib +
    + This subdirectory should contain all of your library source + code. For each library that you build, you will have one + directory in lib that will contain that library's source + code. + +

    + Libraries can be object files, archives, or dynamic libraries. + The lib directory is just a convenient place for libraries + as it places them all in a directory from which they can be linked + later. + +

    include +
    + This subdirectory should contain any header files that are + global to your project. By global, we mean that they are used + by more than one library or executable of your project. +

    + By placing your header files in include, they will be + found automatically by the LLVM build system. For example, if + you have a file include/jazz/note.h, then your source + files can include it simply with #include "jazz/note.h". + +

    tools +
    + This subdirectory should contain all of your source + code for executables. For each program that you build, you + will have one directory in tools that will contain that + program's source code. +

    + +

    test +
    + This subdirectory should contain tests that verify that your code + works correctly. Automated tests are especially useful. +

    + Currently, the LLVM build system provides basic support for tests. + The LLVM system provides the following: +

      +
    • + LLVM provides a tcl procedure that is used by Dejagnu to run + tests. It can be found in llvm/lib/llvm-dg.exp. This + test procedure uses RUN lines in the actual test case to determine + how to run the test. See the TestingGuide for more details. You + can easily write Makefile support similar to the Makefiles in + llvm/test to use Dejagnu to run your project's tests.
    • +
    • + LLVM contains an optional package called llvm-test + which provides benchmarks and programs that are known to compile with the + LLVM GCC front ends. You can use these + programs to test your code, gather statistics information, and + compare it to the current LLVM performance statistics. +
      Currently, there is no way to hook your tests directly into the + llvm/test testing harness. You will simply + need to find a way to use the source provided within that directory + on your own. +
    +
    + +

    Typically, you will want to build your lib directory first followed by + your tools directory.

    + +
    + + + + + +
    + +

    The LLVM build system provides a convenient way to build libraries and + executables. Most of your project Makefiles will only need to define a few + variables. Below is a list of the variables one can set and what they can + do:

    + +
    + + + + +
    + +
    +
    LEVEL +
    + This variable is the relative path from this Makefile to the + top directory of your project's source code. For example, if + your source code is in /tmp/src, then the Makefile in + /tmp/src/jump/high would set LEVEL to "../..". +
    + +
    + + + + +
    + +
    +
    DIRS +
    + This is a space separated list of subdirectories that should be + built. They will be built, one at a time, in the order + specified. +

    + +

    PARALLEL_DIRS +
    + This is a list of directories that can be built in parallel. + These will be built after the directories in DIRS have been + built. +

    + +

    OPTIONAL_DIRS +
    + This is a list of directories that can be built if they exist, + but will not cause an error if they do not exist. They are + built serially in the order in which they are listed. +
    + +
    + + + + +
    + +
    +
    LIBRARYNAME +
    + This variable contains the base name of the library that will + be built. For example, to build a library named + libsample.a, LIBRARYNAME should be set to + sample. +

    + +

    BUILD_ARCHIVE +
    + By default, a library is a .o file that is linked + directly into a program. To build an archive (also known as + a static library), set the BUILD_ARCHIVE variable. +

    + +

    SHARED_LIBRARY +
    + If SHARED_LIBRARY is defined in your Makefile, a shared + (or dynamic) library will be built. +
    + +
    + + + + +
    + +
    +
    TOOLNAME +
    + This variable contains the name of the program that will + be built. For example, to build an executable named + sample, TOOLNAME should be set to sample. +

    + +

    USEDLIBS +
    + This variable holds a space separated list of libraries that + should be linked into the program. These libraries must either + be LLVM libraries or libraries that come from your lib + directory. The libraries must be specified by their base name. + For example, to link libsample.a, you would set USEDLIBS to + sample. +

    + Note that this works only for statically linked libraries. +

    + +

    LIBS +
    + To link dynamic libraries, add -l<library base name> to + the LIBS variable. The LLVM build system will look in the same places + for dynamic libraries as it does for static libraries. +

    + For example, to link libsample.so, you would have the + following line in your Makefile: +

    + + LIBS += -lsample + +

    + +
    + + + + +
    + +
    +
    ExtraSource +
    + This variable contains a space separated list of extra source + files that need to be built. It is useful for including the + output of Lex and Yacc programs. +

    + +

    CFLAGS +
    CPPFLAGS +
    + This variable can be used to add options to the C and C++ + compiler, respectively. It is typically used to add options + that tell the compiler the location of additional directories + to search for header files. +

    + It is highly suggested that you append to CFLAGS and CPPFLAGS as + opposed to overwriting them. The master Makefiles may already + have useful options in them that you may not want to overwrite. +

    +

    + +
    + + + + + +
    + +

    The final location of built libraries and executables will depend upon + whether you do a Debug, Release, or Profile build.

    + +
    +
    Libraries +
    + All libraries (static and dynamic) will be stored in + PROJ_OBJ_ROOT/<type>/lib, where type is Debug, + Release, or Profile for a debug, optimized, or + profiled build, respectively.

    + +

    Executables +
    All executables will be stored in + PROJ_OBJ_ROOT/<type>/bin, where type is Debug, + Release, or Profile for a debug, optimized, or profiled + build, respectively. +
    + +
    + + + + + +
    + +

    If you have any questions or need any help creating an LLVM project, + the LLVM team would be more than happy to help. You can always post your + questions to the LLVM Developers + Mailing List.

    + +
    + + +
    +
    + Valid CSS + Valid HTML 4.01 + + John Criswell
    + The LLVM Compiler Infrastructure +
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/ReleaseNotes.html diff -c /dev/null llvm-www/releases/2.5/docs/ReleaseNotes.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/ReleaseNotes.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,964 ---- + + + + + + LLVM 2.5 Release Notes + + + +
    LLVM 2.5 Release Notes
    + +
      +
    1. Introduction
    2. +
    3. Sub-project Status Update
    4. +
    5. External Projects Using LLVM 2.5
    6. +
    7. What's New in LLVM 2.5?
    8. +
    9. Installation Instructions
    10. +
    11. Portability and Supported Platforms
    12. +
    13. Known Problems
    14. +
    15. Additional Information
    16. +
    + +
    +

    Written by the LLVM Team

    +
    + + + + + +
    + +

    This document contains the release notes for the LLVM Compiler + Infrastructure, release 2.5. Here we describe the status of LLVM, including + major improvements from the previous release and significant known problems. + All LLVM releases may be downloaded from the LLVM releases web site.

    + +

    For more information about LLVM, including information about the latest + release, please check out the main LLVM + web site. If you have questions or comments, the LLVM Developer's Mailing + List is a good place to send them.

    + +

    Note that if you are reading this file from a Subversion checkout or the + main LLVM web page, this document applies to the next release, not the + current one. To see the release notes for a specific release, please see the + releases page.

    + +
    + + + + + + + + + +
    +

    + The LLVM 2.5 distribution currently consists of code from the core LLVM + repository —which roughly includes the LLVM optimizers, code generators + and supporting tools — and the llvm-gcc repository. In addition to this + code, the LLVM Project includes other sub-projects that are in development. The + two which are the most actively developed are the Clang + Project and the VMKit Project. +

    + +
    + + + + + +
    + +

    The Clang project is an effort to build + a set of new 'LLVM native' front-end technologies for the LLVM optimizer and + code generator. While Clang is not included in the LLVM 2.5 release, it is + continuing to make major strides forward in all areas. Its C and Objective-C + parsing and code generation support is now very solid. For example, it is + capable of successfully building many real-world applications for X86-32 + and X86-64, + including the FreeBSD + kernel and gcc 4.2. C++ is also + making incredible progress, + and work on templates has recently started. If you are + interested in fast compiles and good diagnostics, we encourage you to try it out + by building from mainline + and reporting any issues you hit to the Clang front-end mailing + list.

    + +

    In the LLVM 2.5 time-frame, the Clang team has made many improvements:

    + +
      +
    • Clang now has a new driver, which is focused on providing a GCC-compatible + interface.
    • +
    • The X86-64 ABI is now supported, including support for the Apple + 64-bit Objective-C runtime and zero cost exception handling.
    • +
    • Precompiled header support is now implemented.
    • +
    • Objective-C support is significantly improved beyond LLVM 2.4, supporting + many features, such as Objective-C Garbage Collection.
    • +
    • Variable length arrays are now fully supported.
    • +
    • C99 designated initializers are now fully supported.
    • +
    • Clang now includes all major compiler headers, including a + redesigned tgmath.h and several more intrinsic headers.
    • +
    • Many many bugs are fixed and many features have been added.
    • +
    +
    + + + + +
    + +

    Previously announced in the last LLVM release, the Clang project also + includes an early stage static source code analysis tool for automatically finding bugs + in C and Objective-C programs. The tool performs a growing set of checks to find + bugs that occur on a specific path within a program.

    + +

    In the LLVM 2.5 time-frame there have been many significant improvements to + the analyzer's core path simulation engine and machinery for generating + path-based bug reports to end-users. Particularly noteworthy improvements + include experimental support for full field-sensitivity and reasoning about heap + objects as well as an improved value-constraints subengine that does a much + better job of reasoning about inequality relationships (e.g., x > 2) + between variables and constants. + +

    The set of checks performed by the static analyzer continues to expand, and + future plans for the tool include full source-level inter-procedural analysis + and deeper checks such as buffer overrun detection. There are many opportunities + to extend and enhance the static analyzer, and anyone interested in working on + this project is encouraged to get involved!

    + +
    + + + + +
    +

    + The VMKit project is an implementation of + a JVM and a CLI Virtual Machines (Microsoft .NET is an + implementation of the CLI) using the Just-In-Time compiler of LLVM.

    + +

    Following LLVM 2.5, VMKit has its second release that you can find on its + webpage. The release includes + bug fixes, cleanup and new features. The major changes are:

    + +
      + +
    • Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this + functionality to native compile the standard classes (e.g. java.lang.String). + Users can compile AoT .class files into dynamic libraries and run them with the + help of VMKit.
    • + +
    • New exception model: the dwarf exception model is very slow for + exception-intensive applications, so the JVM has had a new implementation of + exceptions which check at each function call if an exception happened. There is + a low performance penalty on applications without exceptions, but it is a big + gain for exception-intensive applications. For example the jack benchmark in + Spec JVM98 is 6x faster (performance gain of 83%).
    • + +
    • User-level management of thread stacks, so that thread local data access + at runtime is fast and portable.
    • + +
    • Implementation of biased locking for faster object synchronizations at + runtime.
    • + +
    • New support for OSX/X64, Linux/X64 (with the Boehm GC) and Linux/ppc32.
    • + +
    +
    + + + + + + +
    + Pure +
    + +
    +

    + Pure + is an algebraic/functional programming language based on term rewriting. + Programs are collections of equations which are used to evaluate expressions in + a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation, + lexical closures, a hygienic macro system (also based on term rewriting), + built-in list and matrix support (including list and matrix comprehensions) and + an easy-to-use C interface. The interpreter uses LLVM as a backend to + JIT-compile Pure programs to fast native code.

    + +

    In addition to the usual algebraic data structures, Pure also has + MATLAB-style matrices in order to support numeric computations and signal + processing in an efficient way. Pure is mainly aimed at mathematical + applications right now, but it has been designed as a general purpose language. + The dynamic interpreter environment and the C interface make it possible to use + it as a kind of functional scripting language for many application areas. +

    +
    + + + + + +
    +

    + LDC is an implementation of + the D Programming Language using the LLVM optimizer and code generator. + The LDC project works great with the LLVM 2.5 release. General improvements in + this + cycle have included new inline asm constraint handling, better debug info + support, general bugfixes, and better x86-64 support. This has allowed + some major improvements in LDC, getting us much closer to being as + fully featured as the original DMD compiler from DigitalMars. +

    +
    + + + + +
    +

    Roadsend PHP (rphp) is an open + source implementation of the PHP programming + language that uses LLVM for its optimizer, JIT, and static compiler. This is a + reimplementation of an earlier project that is now based on LLVM.

    +
    + + + + + + +
    + +

    This release includes a huge number of bug fixes, performance tweaks, and + minor improvements. Some of the major improvements and new features are listed + in this section. +

    +
    + + + + +
    + +

    LLVM 2.5 includes several major new capabilities:

    + +
      +
    • LLVM 2.5 includes a brand new XCore backend.
    • + +
    • llvm-gcc now generally supports the GFortran front-end, and the precompiled + release binaries now support Fortran, even on Mac OS/X.
    • + +
    • CMake is now used by the LLVM build process + on Windows. It automatically generates Visual Studio project files (and + more) from a set of simple text files. This makes it much easier to + maintain. In time, we'd like to standardize on CMake for everything.
    • + +
    • LLVM 2.5 now uses (and includes) Google Test for unit testing.
    • + +
    • The LLVM native code generator now supports arbitrary precision integers. + Types like i33 have long been valid in the LLVM IR, but were previously + only supported by the interpreter. Note that the C backend still does not + support these.
    • + +
    • LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.
    • +
    + +
    + + + + + +
    + +

    LLVM fully supports the llvm-gcc 4.2 front-end, which marries the GCC + front-ends and driver with the LLVM optimizer and code generator. It currently + includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.

    + +
      +
    • In this release, the GCC inliner is completely disabled. Previously the GCC + inliner was used to handle always-inline functions and other cases. This caused + problems with code size growth, and it is completely disabled in this + release.
    • + +
    • llvm-gcc (and LLVM in general) now support code generation for stack + canaries, which is an effective form of buffer overflow + protection. llvm-gcc supports this with the -fstack-protector + command line option (just like GCC). In LLVM IR, you can request code + generation for stack canaries with function attributes. +
    • +
    + +
    + + + + + +
    +

    LLVM IR has several new features that are used by our existing front-ends and + can be useful if you are writing a front-end for LLVM:

    + +
      +
    • The shufflevector instruction + has been generalized to allow different shuffle mask width than its input + vectors. This allows you to use shufflevector to combine two + "<4 x float>" vectors into a "<8 x float>" for example.
    • + +
    • LLVM IR now supports new intrinsics for computing and acting on overflow of integer operations. This allows + efficient code generation for languages that must trap or throw an exception on + overflow. While these intrinsics work on all targets, they only generate + efficient code on X86 so far.
    • + +
    • LLVM IR now supports a new private + linkage type to produce labels that are stripped by the assembler before it + produces a .o file (thus they are invisible to the linker).
    • + +
    • LLVM IR supports two new attributes for better alias analysis. The noalias attribute can now be used on the + return value of a function to indicate that it returns new memory (e.g. + 'malloc', 'calloc', etc). + The new nocapture attribute can be used + on pointer arguments to indicate that the function does not return the pointer, + store it in an object that outlives the call, or let the value of the pointer + escape from the function in any other way. + Note that it is the pointer itself that must not escape, not the value it + points to: loading a value out of the pointer is perfectly fine. + Many standard library functions (e.g. 'strlen', 'memcpy') have this property. + +
    • + +
    • The parser for ".ll" files in lib/AsmParser is now completely rewritten as a + recursive descent parser. This parser produces better error messages (including + caret diagnostics), is less fragile (less likely to crash on strange things), + does not leak memory, is more efficient, and eliminates LLVM's last use of the + 'bison' tool.
    • + +
    • Debug information representation and manipulation internals have been + consolidated to use a new set of classes in + llvm/Analysis/DebugInfo.h. These routines are more + efficient, robust, and extensible and replace the older mechanisms. + llvm-gcc, clang, and the code generator now use them to create and process + debug information.
    • + +
    + +
    + + + + +
    + +

    In addition to a large array of bug fixes and minor performance tweaks, this + release includes a few major enhancements and additions to the optimizers:

    + +
      + +
    • The loop optimizer now improves floating point induction variables in + several ways, including adding shadow induction variables to avoid + "integer <-> floating point" conversions in loops when safe.
    • + +
    • The "-mem2reg" pass is now much faster on code with large basic blocks.
    • + +
    • The "-jump-threading" pass is more powerful: it is iterative + and handles threading based on values with fully and partially redundant + loads.
    • + +
    • The "-memdep" memory dependence analysis pass (used by GVN and memcpyopt) is + both faster and more aggressive.
    • + +
    • The "-scalarrepl" scalar replacement of aggregates pass is more aggressive + about promoting unions to registers.
    • + +
    + +
    + + + + +
    + +

    We have put a significant amount of work into the code generator + infrastructure, which allows us to implement more aggressive algorithms and make + it run faster:

    + +
      +
    • The Writing an LLVM Compiler + Backend document has been greatly expanded and is substantially more + complete.
    • + +
    • The SelectionDAG type legalization logic has been completely rewritten, is + now more powerful (it supports arbitrary precision integer types for example), + and is more correct in several corner cases. The type legalizer converts + operations on types that are not natively supported by the target machine into + equivalent code sequences that only use natively supported types. The old type + legalizer is still available (for now) and will be used if + -disable-legalize-types is passed to the code generator. +
    • + +
    • The code generator now supports widening illegal vectors to larger legal + ones (for example, converting operations on <3 x float> to work on + <4 x float>) which is very important for common graphics + applications.
    • + +
    • The assembly printers for each target are now split out into their own + libraries that are separate from the main code generation logic. This reduces + the code size of JIT compilers by not requiring them to be linked in.
    • + +
    • The 'fast' instruction selection path (used at -O0 and for fast JIT + compilers) now supports accelerating codegen for code that uses exception + handling constructs.
    • + +
    • The optional PBQP register allocator now supports register coalescing.
    • +
    +
    + + + + +
    +

    New features of the X86 target include: +

    + +
      +
    • The llvm.returnaddress + intrinsic (which is used to implement __builtin_return_address) now + supports non-zero stack depths on X86.
    • + +
    • The X86 backend now supports code generation of vector shift operations + using SSE instructions.
    • + +
    • X86-64 code generation now takes advantage of red zone, unless the + -mno-red-zone option is specified.
    • + +
    • The X86 backend now supports using address space #256 in LLVM IR as a way of + performing memory references off the GS segment register. This allows a + front-end to take advantage of very low-level programming techniques when + targeting X86 CPUs. See test/CodeGen/X86/movgs.ll for a simple + example.
    • + +
    • The X86 backend now supports a -disable-mmx command line option to + prevent use of MMX even on chips that support it. This is important for cases + where code does not contain the proper llvm.x86.mmx.emms + intrinsics.
    • + +
    • The X86 JIT now detects the new Intel Core i7 and Atom chips and + auto-configures itself appropriately for the features of these chips.
    • + +
    • The JIT now supports exception handling constructs on Linux/X86-64 and + Darwin/x86-64.
    • + +
    • The JIT supports Thread Local Storage (TLS) on Linux/X86-32 but not yet on + X86-64.
    • +
    + +
    + + + + +
    +

    New features of the PIC16 target include: +

    + +
      +
    • Both direct and indirect load/stores work now.
    • +
    • Logical, bitwise and conditional operations now work for integer data + types.
    • +
    • Function calls involving basic types work now.
    • +
    • Support for integer arrays.
    • +
    • The compiler can now emit libcalls for operations not supported by m/c + instructions.
    • +
    • Support for both data and ROM address spaces.
    • +
    + +

    Things not yet supported:

    + +
      +
    • Floating point.
    • +
    • Passing/returning aggregate types to and from functions.
    • +
    • Variable arguments.
    • +
    • Indirect function calls.
    • +
    • Interrupts/programs.
    • +
    • Debug info.
    • +
    + +
    + + + + + +
    +

    New features include:

    + +
      +
    • Beginning with LLVM 2.5, llvmc2 is known as + just llvmc. The old llvmc driver was removed.
    • + +
    • The Clang plugin was substantially improved and is now enabled + by default. The command llvmc --clang can be now used as a + synonym to ccc.
    • + +
    • There is now a --check-graph option, which is supposed to catch + common errors like multiple default edges, mismatched output/input language + names and cycles. In general, these checks can't be done at compile-time + because of the need to support plugins.
    • + +
    • Plugins are now more flexible and can refer to compilation graph nodes and + options defined in other plugins. To manage dependencies, a priority-sorting + mechanism was introduced. This change affects the TableGen file syntax. See the + documentation for details.
    • + +
    • Hooks can now be provided with arguments. The syntax is "$CALL(MyHook, + 'Arg1', 'Arg2', 'Arg3')".
    • + +
    • A new option type: multi-valued option, for options that take more than one + argument (for example, "-foo a b c").
    • + +
    • New option properties: 'one_or_more', 'zero_or_more', + 'hidden' and 'really_hidden'.
    • + +
    • The 'case' expression gained an 'error' action and + an 'empty' test (equivalent to "(not (not_empty ...))").
    • + +
    • Documentation now looks more consistent to the rest of the LLVM + docs. There is also a man page now.
    • + +
    + +
    + + + + + +
    + +

    If you're already an LLVM user or developer with out-of-tree changes based + on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading + from the previous release.

    + +
      + +
    • llvm-gcc defaults to -fno-math-errno on all X86 targets.
    • + +
    + + +

    In addition, many APIs have changed in this release. Some of the major LLVM + API changes are:

    + +
      +
    • Some deprecated interfaces to create Instruction subclasses, that + were spelled with lower case "create," have been removed.
    • +
    + +
    + + + + + + + +
    + +

    LLVM is known to work on the following platforms:

    + +
      +
    • Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat + Linux, Fedora Core and FreeBSD (and probably other unix-like systems).
    • +
    • PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit + and 64-bit modes.
    • +
    • Intel and AMD machines running on Win32 using MinGW libraries (native).
    • +
    • Intel and AMD machines running on Win32 with the Cygwin libraries (limited + support is available for native builds with Visual C++).
    • +
    • Sun UltraSPARC workstations running Solaris 10.
    • +
    • Alpha-based machines running Debian GNU/Linux.
    • +
    • Itanium-based (IA64) machines running Linux and HP-UX.
    • +
    + +

    The core LLVM infrastructure uses GNU autoconf to adapt itself + to the machine and operating system on which it is built. However, minor + porting may be required to get LLVM to work on new platforms. We welcome your + portability patches and reports of successful builds or error messages.

    + +
    + + + + + +
    + +

    This section contains significant known problems with the LLVM system, + listed by component. If you run into a problem, please check the LLVM bug database and submit a bug if + there isn't already one.

    + +
    + + + + +
    + +

    The following components of this LLVM release are either untested, known to + be broken or unreliable, or are in early development. These components should + not be relied on, and bugs should not be filed against them, but they may be + useful to some people. In particular, if you would like to work on one of these + components, please contact us on the LLVMdev list.

    + +
      +
    • The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.
    • +
    • The llc "-filetype=asm" (the default) is the only + supported value for this option.
    • +
    + +
    + + + + +
    + +
      +
    • The X86 backend does not yet support + all inline assembly that uses the X86 + floating point stack. It supports the 'f' and 't' constraints, but not + 'u'.
    • +
    • The X86 backend generates inefficient floating point code when configured + to generate code for systems that don't have SSE2.
    • +
    • Win64 code generation wasn't widely tested. Everything should work, but we + expect small issues to happen. Also, llvm-gcc cannot build the mingw64 + runtime currently due + to several + bugs and due to lack of support for + the + 'u' inline assembly constraint and for X87 floating point inline assembly.
    • +
    • The X86-64 backend does not yet support the LLVM IR instruction + va_arg. Currently, the llvm-gcc and front-ends support variadic + argument constructs on X86-64 by lowering them manually.
    • +
    + +
    + + + + +
    + +
      +
    • The Linux PPC32/ABI support needs testing for the interpreter and static + compilation, and lacks support for debug information.
    • +
    + +
    + + + + +
    + +
      +
    • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 + processors, thumb programs can crash or produce wrong + results (PR1388).
    • +
    • Compilation for ARM Linux OABI (old ABI) is supported but not fully tested. +
    • +
    • There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly + execute + programs compiled with LLVM. Please use more recent versions of QEMU.
    • +
    + +
    + + + + +
    + +
      +
    • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not + support the 64-bit SPARC ABI (-m64).
    • +
    + +
    + + + + +
    + +
      +
    • The O32 ABI is not fully supported.
    • +
    • 64-bit MIPS targets are not supported yet.
    • +
    + +
    + + + + +
    + +
      + +
    • On 21164s, some rare FP arithmetic sequences which may trap do not have the + appropriate nops inserted to ensure restartability.
    • + +
    +
    + + + + +
    + +
      +
    • The Itanium backend is highly experimental and has a number of known + issues. We are looking for a maintainer for the Itanium backend. If you + are interested, please contact the LLVMdev mailing list.
    • +
    + +
    + + + + +
    + + + +
    + + + + + +
    + +

    llvm-gcc does not currently support Link-Time + Optimization on most platforms "out-of-the-box". Please inquire on the + LLVMdev mailing list if you are interested.

    + +

    The only major language feature of GCC not supported by llvm-gcc is + the __builtin_apply family of builtins. However, some extensions + are only supported on some targets. For example, trampolines are only + supported on some targets (these are used when you take the address of a + nested function).

    + +

    If you run into GCC extensions which are not supported, please let us know. +

    + +
    + + + + +
    + +

    The C++ front-end is considered to be fully + tested and works for a number of non-trivial programs, including LLVM + itself, Qt, Mozilla, etc.

    + +
      +
    • Exception handling works well on the X86 and PowerPC targets. Currently + only Linux and Darwin targets are supported (both 32 and 64 bit).
    • +
    + +
    + + + + +
    +
      +
    • Fortran support generally works, but there are still several unresolved bugs + in Bugzilla. Please see the tools/gfortran component for details.
    • +
    +
    + + + + +
    + The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature + technology, and problems should be expected. +
      +
    • The Ada front-end currently only builds on X86-32. This is mainly due + to lack of trampoline support (pointers to nested functions) on other platforms. + However, it also fails to build on X86-64 + which does support trampolines.
    • +
    • The Ada front-end fails to bootstrap. + This is due to lack of LLVM support for setjmp/longjmp style + exception handling, which is used internally by the compiler. + Workaround: configure with --disable-bootstrap.
    • +
    • The c380004, c393010 + and cxg2021 ACATS tests fail + (c380004 also fails with gcc-4.2 mainline). + If the compiler is built with checks disabled then c393010 + causes the compiler to go into an infinite loop, using up all system memory.
    • +
    • Some GCC specific Ada tests continue to crash the compiler.
    • +
    • The -E binder option (exception backtraces) + does not work and will result in programs + crashing if an exception is raised. Workaround: do not use -E.
    • +
    • Only discrete types are allowed to start + or finish at a non-byte offset in a record. Workaround: do not pack records + or use representation clauses that result in a field of a non-discrete type + starting or finishing in the middle of a byte.
    • +
    • The lli interpreter considers + 'main' as generated by the Ada binder to be invalid. + Workaround: hand edit the file to use pointers for argv and + envp rather than integers.
    • +
    • The -fstack-check option is + ignored.
    • +
    +
    + + + + + +
    + +

    A wide variety of additional information is available on the LLVM web page, in particular in the documentation section. The web page also + contains versions of the API documentation which is up-to-date with the + Subversion version of the source code. + You can access versions of these documents specific to this release by going + into the "llvm/doc/" directory in the LLVM tree.

    + +

    If you have any questions or comments about LLVM, please feel free to contact + us via the mailing + lists.

    + +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/SourceLevelDebugging.html diff -c /dev/null llvm-www/releases/2.5/docs/SourceLevelDebugging.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/SourceLevelDebugging.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,1812 ---- + + + + Source Level Debugging with LLVM + + + + +
    Source Level Debugging with LLVM
    + + + + + +
    + + + A leafy and green bug eater +
    + +
    +

    Written by Chris Lattner + and Jim Laskey

    +
    + + + + + + +
    + +

    This document is the central repository for all information pertaining to + debug information in LLVM. It describes the actual format + that the LLVM debug information takes, which is useful for those interested + in creating front-ends or dealing directly with the information. Further, this + document provides specifc examples of what debug information for C/C++.

    + +
    + + + + +
    + +

    The idea of the LLVM debugging information is to capture how the important + pieces of the source-language's Abstract Syntax Tree map onto LLVM code. + Several design aspects have shaped the solution that appears here. The + important ones are:

    + +
      +
    • Debugging information should have very little impact on the rest of the + compiler. No transformations, analyses, or code generators should need to be + modified because of debugging information.
    • + +
    • LLVM optimizations should interact in well-defined and + easily described ways with the debugging information.
    • + +
    • Because LLVM is designed to support arbitrary programming languages, + LLVM-to-LLVM tools should not need to know anything about the semantics of the + source-level-language.
    • + +
    • Source-level languages are often widely different from one another. + LLVM should not put any restrictions of the flavor of the source-language, and + the debugging information should work with any language.
    • + +
    • With code generator support, it should be possible to use an LLVM compiler + to compile a program to native machine code and standard debugging formats. + This allows compatibility with traditional machine-code level debuggers, like + GDB or DBX.
    • + +
    + +

    The approach used by the LLVM implementation is to use a small set of intrinsic functions to define a mapping + between LLVM program objects and the source-level objects. The description of + the source-level program is maintained in LLVM global variables in an implementation-defined format (the C/C++ front-end + currently uses working draft 7 of the Dwarf 3 standard).

    + +

    When a program is being debugged, a debugger interacts with the user and + turns the stored debug information into source-language specific information. + As such, a debugger must be aware of the source-language, and is thus tied to + a specific language or family of languages.

    + +
    + + + + +
    +

    The role of debug information is to provide meta information normally + stripped away during the compilation process. This meta information provides an + LLVM user a relationship between generated code and the original program source + code.

    + +

    Currently, debug information is consumed by the DwarfWriter to produce dwarf + information used by the gdb debugger. Other targets could use the same + information to produce stabs or other debug forms.

    + +

    It would also be reasonable to use debug information to feed profiling tools + for analysis of generated code, or, tools for reconstructing the original source + from generated code.

    + +

    TODO - expound a bit more.

    + +
    + + + + +
    + +

    An extremely high priority of LLVM debugging information is to make it + interact well with optimizations and analysis. In particular, the LLVM debug + information provides the following guarantees:

    + +
      + +
    • LLVM debug information always provides information to accurately read the + source-level state of the program, regardless of which LLVM optimizations + have been run, and without any modification to the optimizations themselves. + However, some optimizations may impact the ability to modify the current state + of the program with a debugger, such as setting program variables, or calling + functions that have been deleted.
    • + +
    • LLVM optimizations gracefully interact with debugging information. If they + are not aware of debug information, they are automatically disabled as necessary + in the cases that would invalidate the debug info. This retains the LLVM + features, making it easy to write new transformations.
    • + +
    • As desired, LLVM optimizations can be upgraded to be aware of the LLVM + debugging information, allowing them to update the debugging information as they + perform aggressive optimizations. This means that, with effort, the LLVM + optimizers could optimize debug code just as well as non-debug code.
    • + +
    • LLVM debug information does not prevent many important optimizations from + happening (for example inlining, basic block reordering/merging/cleanup, tail + duplication, etc), further reducing the amount of the compiler that eventually + is "aware" of debugging information.
    • + +
    • LLVM debug information is automatically optimized along with the rest of the + program, using existing facilities. For example, duplicate information is + automatically merged by the linker, and unused information is automatically + removed.
    • + +
    + +

    Basically, the debug information allows you to compile a program with + "-O0 -g" and get full debug information, allowing you to arbitrarily + modify the program as it executes from a debugger. Compiling a program with + "-O3 -g" gives you full debug information that is always available and + accurate for reading (e.g., you get accurate stack traces despite tail call + elimination and inlining), but you might lose the ability to modify the program + and call functions where were optimized out of the program, or inlined away + completely.

    + +

    LLVM test suite provides a + framework to test optimizer's handling of debugging information. It can be run + like this:

    + +
    +
    + % cd llvm/projects/test-suite/MultiSource/Benchmarks  # or some other level
    + % make TEST=dbgopt
    + 
    +
    + +

    + This will test impact of debugging information on optimization passes. If + debugging information influences optimization passes then it will be reported + as a failure. See TestingGuide + for more information on LLVM test infrastructure and how to run various tests. +

    + +
    + + + + + +
    + +

    LLVM debugging information has been carefully designed to make it possible + for the optimizer to optimize the program and debugging information without + necessarily having to know anything about debugging information. In particular, + the global constant merging pass automatically eliminates duplicated debugging + information (often caused by header files), the global dead code elimination + pass automatically deletes debugging information for a function if it decides to + delete the function, and the linker eliminates debug information when it merges + linkonce functions.

    + +

    To do this, most of the debugging information (descriptors for types, + variables, functions, source files, etc) is inserted by the language front-end + in the form of LLVM global variables. These LLVM global variables are no + different from any other global variables, except that they have a web of LLVM + intrinsic functions that point to them. If the last references to a particular + piece of debugging information are deleted (for example, by the + -globaldce pass), the extraneous debug information will automatically + become dead and be removed by the optimizer.

    + +

    Debug information is designed to be agnostic about the target debugger and + debugging information representation (e.g. DWARF/Stabs/etc). It uses a generic + machine debug information pass to decode the information that represents + variables, types, functions, namespaces, etc: this allows for arbitrary + source-language semantics and type-systems to be used, as long as there is a + module written for the target debugger to interpret the information. In + addition, debug global variables are declared in the "llvm.metadata" + section. All values declared in this section are stripped away after target + debug information is constructed and before the program object is emitted.

    + +

    To provide basic functionality, the LLVM debugger does have to make some + assumptions about the source-level language being debugged, though it keeps + these to a minimum. The only common features that the LLVM debugger assumes + exist are source files, and program objects. These abstract objects are + used by a debugger to form stack traces, show information about local + variables, etc.

    + +

    This section of the documentation first describes the representation aspects + common to any source-language. The next section + describes the data layout conventions used by the C and C++ front-ends.

    + +
    + + + + +
    +

    In consideration of the complexity and volume of debug information, LLVM + provides a specification for well formed debug global variables. The constant + value of each of these globals is one of a limited set of structures, known as + debug descriptors.

    + +

    Consumers of LLVM debug information expect the descriptors for program + objects to start in a canonical format, but the descriptors can include + additional information appended at the end that is source-language specific. All + LLVM debugging information is versioned, allowing backwards compatibility in the + case that the core structures need to change in some way. Also, all debugging + information objects start with a tag to indicate what type of object it is. The + source-language is allowed to define its own objects, by using unreserved tag + numbers. We recommend using with tags in the range 0x1000 thru 0x2000 (there is + a defined enum DW_TAG_user_base = 0x1000.)

    + +

    The fields of debug descriptors used internally by LLVM (MachineModuleInfo) + are restricted to only the simple data types int, uint, + bool, float, double, sbyte* and { }* + . References to arbitrary values are handled using a { }* and a + cast to { }* expression; typically references to other field + descriptors, arrays of descriptors or global variables.

    + +
    +   %llvm.dbg.object.type = type {
    +     uint,   ;; A tag
    +     ...
    +   }
    + 
    + +

    The first field of a descriptor is always an + uint containing a tag value identifying the content of the descriptor. + The remaining fields are specific to the descriptor. The values of tags are + loosely bound to the tag values of Dwarf information entries. However, that + does not restrict the use of the information supplied to Dwarf targets. To + facilitate versioning of debug information, the tag is augmented with the + current debug version (LLVMDebugVersion = 4 << 16 or 0x40000 or 262144.)

    + +

    The details of the various descriptors follow.

    + +
    + + + + +
    + +
    +   %llvm.dbg.anchor.type = type {
    +     uint,   ;; Tag = 0 + LLVMDebugVersion
    +     uint    ;; Tag of descriptors grouped by the anchor
    +   }
    + 
    + +

    One important aspect of the LLVM debug representation is that it allows the + LLVM debugger to efficiently index all of the global objects without having the + scan the program. To do this, all of the global objects use "anchor" + descriptors with designated names. All of the global objects of a particular + type (e.g., compile units) contain a pointer to the anchor. This pointer allows + a debugger to use def-use chains to find all global objects of that type.

    + +

    The following names are recognized as anchors by LLVM:

    + +
    +   %llvm.dbg.compile_units       = linkonce constant %llvm.dbg.anchor.type  { uint 0, uint 17 } ;; DW_TAG_compile_unit
    +   %llvm.dbg.global_variables    = linkonce constant %llvm.dbg.anchor.type  { uint 0, uint 52 } ;; DW_TAG_variable
    +   %llvm.dbg.subprograms         = linkonce constant %llvm.dbg.anchor.type  { uint 0, uint 46 } ;; DW_TAG_subprogram
    + 
    + +

    Using anchors in this way (where the compile unit descriptor points to the + anchors, as opposed to having a list of compile unit descriptors) allows for the + standard dead global elimination and merging passes to automatically remove + unused debugging information. If the globals were kept track of through lists, + there would always be an object pointing to the descriptors, thus would never be + deleted.

    + +
    + + + + +
    + +
    +   %llvm.dbg.compile_unit.type = type {
    +     uint,   ;; Tag = 17 + LLVMDebugVersion (DW_TAG_compile_unit)
    +     {  }*,  ;; Compile unit anchor = cast = (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to {  }*)
    +     uint,   ;; Dwarf language identifier (ex. DW_LANG_C89) 
    +     sbyte*, ;; Source file name
    +     sbyte*, ;; Source file directory (includes trailing slash)
    +     sbyte*  ;; Producer (ex. "4.0.1 LLVM (LLVM research group)")
    +     bool    ;; True if this is a main compile unit. 
    +   }
    + 
    + +

    These descriptors contain a source language ID for the file (we use the Dwarf + 3.0 ID numbers, such as DW_LANG_C89, DW_LANG_C_plus_plus, + DW_LANG_Cobol74, etc), three strings describing the filename, working + directory of the compiler, and an identifier string for the compiler that + produced it.

    + +

    Compile unit descriptors provide the root context for objects declared in a + specific source file. Global variables and top level functions would be defined + using this context. Compile unit descriptors also provide context for source + line correspondence.

    + +

    Each input file is encoded as a separate compile unit in LLVM debugging + information output. However, many target specific tool chains prefer to encode + only one compile unit in an object file. In this situation, the LLVM code + generator will include debugging information entities in the compile unit + that is marked as main compile unit. The code generator accepts maximum one main + compile unit per module. If a module does not contain any main compile unit + then the code generator will emit multiple compile units in the output object + file. +

    + + + + +
    + +
    +   %llvm.dbg.global_variable.type = type {
    +     uint,   ;; Tag = 52 + LLVMDebugVersion (DW_TAG_variable)
    +     {  }*,  ;; Global variable anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.global_variables to {  }*),  
    +     {  }*,  ;; Reference to context descriptor
    +     sbyte*, ;; Name
    +     sbyte*, ;; Display name (fully qualified C++ name)
    +     sbyte*, ;; MIPS linkage name (for C++)
    +     {  }*,  ;; Reference to compile unit where defined
    +     uint,   ;; Line number where defined
    +     {  }*,  ;; Reference to type descriptor
    +     bool,   ;; True if the global is local to compile unit (static)
    +     bool,   ;; True if the global is defined in the compile unit (not extern)
    +     {  }*   ;; Reference to the global variable
    +   }
    + 
    + +

    These descriptors provide debug information about globals variables. The + provide details such as name, type and where the variable is defined.

    + +
    + + + + +
    + +
    +   %llvm.dbg.subprogram.type = type {
    +     uint,   ;; Tag = 46 + LLVMDebugVersion (DW_TAG_subprogram)
    +     {  }*,  ;; Subprogram anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.subprograms to {  }*),  
    +     {  }*,  ;; Reference to context descriptor
    +     sbyte*, ;; Name
    +     sbyte*, ;; Display name (fully qualified C++ name)
    +     sbyte*, ;; MIPS linkage name (for C++)
    +     {  }*,  ;; Reference to compile unit where defined
    +     uint,   ;; Line number where defined
    +     {  }*,  ;; Reference to type descriptor
    +     bool,   ;; True if the global is local to compile unit (static)
    +     bool    ;; True if the global is defined in the compile unit (not extern)
    +   }
    + 
    + +

    These descriptors provide debug information about functions, methods and + subprograms. They provide details such as name, return types and the source + location where the subprogram is defined.

    + +
    + + + +
    + +
    +   %llvm.dbg.block = type {
    +     uint,   ;; Tag = 13 + LLVMDebugVersion (DW_TAG_lexical_block)
    +     {  }*   ;; Reference to context descriptor
    +   }
    + 
    + +

    These descriptors provide debug information about nested blocks within a + subprogram. The array of member descriptors is used to define local variables + and deeper nested blocks.

    + +
    + + + + +
    + +
    +   %llvm.dbg.basictype.type = type {
    +     uint,   ;; Tag = 36 + LLVMDebugVersion (DW_TAG_base_type)
    +     {  }*,  ;; Reference to context (typically a compile unit)
    +     sbyte*, ;; Name (may be "" for anonymous types)
    +     {  }*,  ;; Reference to compile unit where defined (may be NULL)
    +     uint,   ;; Line number where defined (may be 0)
    +     uint,   ;; Size in bits
    +     uint,   ;; Alignment in bits
    +     uint,   ;; Offset in bits
    +     uint    ;; Dwarf type encoding
    +   }
    + 
    + +

    These descriptors define primitive types used in the code. Example int, bool + and float. The context provides the scope of the type, which is usually the top + level. Since basic types are not usually user defined the compile unit and line + number can be left as NULL and 0. The size, alignment and offset are expressed + in bits and can be 64 bit values. The alignment is used to round the offset + when embedded in a composite type + (example to keep float doubles on 64 bit boundaries.) The offset is the bit + offset if embedded in a composite + type.

    + +

    The type encoding provides the details of the type. The values are typically + one of the following:

    + +
    +   DW_ATE_address = 1
    +   DW_ATE_boolean = 2
    +   DW_ATE_float = 4
    +   DW_ATE_signed = 5
    +   DW_ATE_signed_char = 6
    +   DW_ATE_unsigned = 7
    +   DW_ATE_unsigned_char = 8
    + 
    + +
    + + + + +
    + +
    +   %llvm.dbg.derivedtype.type = type {
    +     uint,   ;; Tag (see below)
    +     {  }*,  ;; Reference to context
    +     sbyte*, ;; Name (may be "" for anonymous types)
    +     {  }*,  ;; Reference to compile unit where defined (may be NULL)
    +     uint,   ;; Line number where defined (may be 0)
    +     uint,   ;; Size in bits
    +     uint,   ;; Alignment in bits
    +     uint,   ;; Offset in bits
    +     {  }*   ;; Reference to type derived from
    +   }
    + 
    + +

    These descriptors are used to define types derived from other types. The + value of the tag varies depending on the meaning. The following are possible + tag values:

    + +
    +   DW_TAG_formal_parameter = 5
    +   DW_TAG_member = 13
    +   DW_TAG_pointer_type = 15
    +   DW_TAG_reference_type = 16
    +   DW_TAG_typedef = 22
    +   DW_TAG_const_type = 38
    +   DW_TAG_volatile_type = 53
    +   DW_TAG_restrict_type = 55
    + 
    + +

    DW_TAG_member is used to define a member of a composite type or subprogram. The type of the member is the derived type. DW_TAG_formal_parameter + is used to define a member which is a formal argument of a subprogram.

    + +

    DW_TAG_typedef is used to + provide a name for the derived type.

    + +

    DW_TAG_pointer_type, + DW_TAG_reference_type, DW_TAG_const_type, + DW_TAG_volatile_type and DW_TAG_restrict_type are used to + qualify the derived type.

    + +

    Derived type location can be determined + from the compile unit and line number. The size, alignment and offset are + expressed in bits and can be 64 bit values. The alignment is used to round the + offset when embedded in a composite type + (example to keep float doubles on 64 bit boundaries.) The offset is the bit + offset if embedded in a composite + type.

    + +

    Note that the void * type is expressed as a + llvm.dbg.derivedtype.type with tag of DW_TAG_pointer_type and + NULL derived type.

    + +
    + + + + +
    + +
    +   %llvm.dbg.compositetype.type = type {
    +     uint,   ;; Tag (see below)
    +     {  }*,  ;; Reference to context
    +     sbyte*, ;; Name (may be "" for anonymous types)
    +     {  }*,  ;; Reference to compile unit where defined (may be NULL)
    +     uint,   ;; Line number where defined (may be 0)
    +     uint,   ;; Size in bits
    +     uint,   ;; Alignment in bits
    +     uint,   ;; Offset in bits
    +     {  }*   ;; Reference to array of member descriptors
    +   }
    + 
    + +

    These descriptors are used to define types that are composed of 0 or more + elements. The value of the tag varies depending on the meaning. The following + are possible tag values:

    + +
    +   DW_TAG_array_type = 1
    +   DW_TAG_enumeration_type = 4
    +   DW_TAG_structure_type = 19
    +   DW_TAG_union_type = 23
    +   DW_TAG_vector_type = 259
    +   DW_TAG_subroutine_type = 46
    +   DW_TAG_inheritance = 26
    + 
    + +

    The vector flag indicates that an array type is a native packed vector.

    + +

    The members of array types (tag = DW_TAG_array_type) or vector types + (tag = DW_TAG_vector_type) are subrange + descriptors, each representing the range of subscripts at that level of + indexing.

    + +

    The members of enumeration types (tag = DW_TAG_enumeration_type) are + enumerator descriptors, each representing the + definition of enumeration value + for the set.

    + +

    The members of structure (tag = DW_TAG_structure_type) or union (tag + = DW_TAG_union_type) types are any one of the basic, derived + or composite type descriptors, each + representing a field member of the structure or union.

    + +

    For C++ classes (tag = DW_TAG_structure_type), member descriptors + provide information about base classes, static members and member functions. If + a member is a derived type descriptor and has + a tag of DW_TAG_inheritance, then the type represents a base class. If + the member of is a global variable + descriptor then it represents a static member. And, if the member is a subprogram descriptor then it represents a member + function. For static members and member functions, getName() returns + the members link or the C++ mangled name. getDisplayName() the + simplied version of the name.

    + +

    The first member of subroutine (tag = DW_TAG_subroutine_type) + type elements is the return type for the subroutine. The remaining + elements are the formal arguments to the subroutine.

    + +

    Composite type location can be + determined from the compile unit and line number. The size, alignment and + offset are expressed in bits and can be 64 bit values. The alignment is used to + round the offset when embedded in a composite + type (as an example, to keep float doubles on 64 bit boundaries.) The offset + is the bit offset if embedded in a composite + type.

    + +
    + + + + +
    + +
    +   %llvm.dbg.subrange.type = type {
    +     uint,   ;; Tag = 33 + LLVMDebugVersion (DW_TAG_subrange_type)
    +     uint,   ;; Low value
    +     uint    ;; High value
    +   }
    + 
    + +

    These descriptors are used to define ranges of array subscripts for an array + composite type. The low value defines the + lower bounds typically zero for C/C++. The high value is the upper bounds. + Values are 64 bit. High - low + 1 is the size of the array. If + low == high the array will be unbounded.

    + +
    + + + + +
    + +
    +   %llvm.dbg.enumerator.type = type {
    +     uint,   ;; Tag = 40 + LLVMDebugVersion (DW_TAG_enumerator)
    +     sbyte*, ;; Name
    +     uint    ;; Value
    +   }
    + 
    + +

    These descriptors are used to define members of an enumeration composite type, it associates the name to the + value.

    + +
    + + + + +
    +
    +   %llvm.dbg.variable.type = type {
    +     uint,    ;; Tag (see below)
    +     {  }*,   ;; Context
    +     sbyte*,  ;; Name
    +     {  }*,   ;; Reference to compile unit where defined
    +     uint,    ;; Line number where defined
    +     {  }*    ;; Type descriptor
    +   }
    + 
    + +

    These descriptors are used to define variables local to a sub program. The + value of the tag depends on the usage of the variable:

    + +
    +   DW_TAG_auto_variable = 256
    +   DW_TAG_arg_variable = 257
    +   DW_TAG_return_variable = 258
    + 
    + +

    An auto variable is any variable declared in the body of the function. An + argument variable is any variable that appears as a formal argument to the + function. A return variable is used to track the result of a function and has + no source correspondent.

    + +

    The context is either the subprogram or block where the variable is defined. + Name the source variable name. Compile unit and line indicate where the + variable was defined. Type descriptor defines the declared type of the + variable.

    + +
    + + + + +
    + +

    LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to + provide debug information at various points in generated code.

    + +
    + + + + +
    +
    +   void %llvm.dbg.stoppoint( uint, uint, { }* )
    + 
    + +

    This intrinsic is used to provide correspondence between the source file and + the generated code. The first argument is the line number (base 1), second + argument is the column number (0 if unknown) and the third argument the source + %llvm.dbg.compile_unit* cast to a + { }*. Code following a call to this intrinsic will have been defined + in close proximity of the line, column and file. This information holds until + the next call to %lvm.dbg.stoppoint.

    + +
    + + + + +
    +
    +   void %llvm.dbg.func.start( { }* )
    + 
    + +

    This intrinsic is used to link the debug information in %llvm.dbg.subprogram to the function. It + defines the beginning of the function's declarative region (scope). It also + implies a call to %llvm.dbg.stoppoint which defines a + source line "stop point". The intrinsic should be called early in the function + after the all the alloca instructions. It should be paired off with a closing + %llvm.dbg.region.end. The function's + single argument is the %llvm.dbg.subprogram.type.

    + +
    + + + + +
    +
    +   void %llvm.dbg.region.start( { }* )
    + 
    + +

    This intrinsic is used to define the beginning of a declarative scope (ex. + block) for local language elements. It should be paired off with a closing + %llvm.dbg.region.end. The + function's single argument is the %llvm.dbg.block which is starting.

    + + +
    + + + + +
    +
    +   void %llvm.dbg.region.end( { }* )
    + 
    + +

    This intrinsic is used to define the end of a declarative scope (ex. block) + for local language elements. It should be paired off with an opening %llvm.dbg.region.start or %llvm.dbg.func.start. The function's + single argument is either the %llvm.dbg.block or the %llvm.dbg.subprogram.type which is + ending.

    + +
    + + + + +
    +
    +   void %llvm.dbg.declare( { } *, { }* )
    + 
    + +

    This intrinsic provides information about a local element (ex. variable.) The + first argument is the alloca for the variable, cast to a { }*. The + second argument is the %llvm.dbg.variable containing the description + of the variable, also cast to a { }*.

    + +
    + + + + +
    + +

    LLVM debugger "stop points" are a key part of the debugging representation + that allows the LLVM to maintain simple semantics for debugging optimized code. The basic idea is that the + front-end inserts calls to the %llvm.dbg.stoppoint intrinsic + function at every point in the program where a debugger should be able to + inspect the program (these correspond to places a debugger stops when you + "step" through it). The front-end can choose to place these as + fine-grained as it would like (for example, before every subexpression + evaluated), but it is recommended to only put them after every source statement + that includes executable code.

    + +

    Using calls to this intrinsic function to demark legal points for the + debugger to inspect the program automatically disables any optimizations that + could potentially confuse debugging information. To non-debug-information-aware + transformations, these calls simply look like calls to an external function, + which they must assume to do anything (including reading or writing to any part + of reachable memory). On the other hand, it does not impact many optimizations, + such as code motion of non-trapping instructions, nor does it impact + optimization of subexpressions, code duplication transformations, or basic-block + reordering transformations.

    + +
    + + + + + +
    +

    In many languages, the local variables in functions can have their lifetime + or scope limited to a subset of a function. In the C family of languages, for + example, variables are only live (readable and writable) within the source block + that they are defined in. In functional languages, values are only readable + after they have been defined. Though this is a very obvious concept, it is also + non-trivial to model in LLVM, because it has no notion of scoping in this sense, + and does not want to be tied to a language's scoping rules.

    + +

    In order to handle this, the LLVM debug format uses the notion of "regions" + of a function, delineated by calls to intrinsic functions. These intrinsic + functions define new regions of the program and indicate when the region + lifetime expires. Consider the following C fragment, for example:

    + +
    + 1.  void foo() {
    + 2.    int X = ...;
    + 3.    int Y = ...;
    + 4.    {
    + 5.      int Z = ...;
    + 6.      ...
    + 7.    }
    + 8.    ...
    + 9.  }
    + 
    + +

    Compiled to LLVM, this function would be represented like this:

    + +
    + void %foo() {
    + entry:
    +     %X = alloca int
    +     %Y = alloca int
    +     %Z = alloca int
    +     
    +     ...
    +     
    +     call void %llvm.dbg.func.start( %llvm.dbg.subprogram.type* %llvm.dbg.subprogram )
    +     
    +     call void %llvm.dbg.stoppoint( uint 2, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
    +     
    +     call void %llvm.dbg.declare({}* %X, ...)
    +     call void %llvm.dbg.declare({}* %Y, ...)
    +     
    +     ;; Evaluate expression on line 2, assigning to X.
    +     
    +     call void %llvm.dbg.stoppoint( uint 3, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
    +     
    +     ;; Evaluate expression on line 3, assigning to Y.
    +     
    +     call void %llvm.region.start()
    +     call void %llvm.dbg.stoppoint( uint 5, uint 4, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
    +     call void %llvm.dbg.declare({}* %X, ...)
    +     
    +     ;; Evaluate expression on line 5, assigning to Z.
    +     
    +     call void %llvm.dbg.stoppoint( uint 7, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
    +     call void %llvm.region.end()
    +     
    +     call void %llvm.dbg.stoppoint( uint 9, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
    +     
    +     call void %llvm.region.end()
    +     
    +     ret void
    + }
    + 
    + +

    This example illustrates a few important details about the LLVM debugging + information. In particular, it shows how the various intrinsics are applied + together to allow a debugger to analyze the relationship between statements, + variable definitions, and the code used to implement the function.

    + +

    The first intrinsic %llvm.dbg.func.start provides + a link with the subprogram descriptor + containing the details of this function. This call also defines the beginning + of the function region, bounded by the %llvm.region.end at the end of + the function. This region is used to bracket the lifetime of variables declared + within. For a function, this outer region defines a new stack frame whose + lifetime ends when the region is ended.

    + +

    It is possible to define inner regions for short term variables by using the + %llvm.region.start and %llvm.region.end to bound a + region. The inner region in this example would be for the block containing the + declaration of Z.

    + +

    Using regions to represent the boundaries of source-level functions allow + LLVM interprocedural optimizations to arbitrarily modify LLVM functions without + having to worry about breaking mapping information between the LLVM code and the + and source-level program. In particular, the inliner requires no modification + to support inlining with debugging information: there is no explicit correlation + drawn between LLVM functions and their source-level counterparts (note however, + that if the inliner inlines all instances of a non-strong-linkage function into + its caller that it will not be possible for the user to manually invoke the + inlined function from a debugger).

    + +

    Once the function has been defined, the stopping point corresponding to + line #2 (column #2) of the function is encountered. At this point in the + function, no local variables are live. As lines 2 and 3 of the example + are executed, their variable definitions are introduced into the program using + %llvm.dbg.declare, without the + need to specify a new region. These variables do not require new regions to be + introduced because they go out of scope at the same point in the program: line + 9.

    + +

    In contrast, the Z variable goes out of scope at a different time, + on line 7. For this reason, it is defined within the inner region, which kills + the availability of Z before the code for line 8 is executed. In this + way, regions can support arbitrary source-language scoping rules, as long as + they can only be nested (ie, one scope cannot partially overlap with a part of + another scope).

    + +

    It is worth noting that this scoping mechanism is used to control scoping of + all declarations, not just variable declarations. For example, the scope of a + C++ using declaration is controlled with this and could change how name lookup is + performed.

    + +
    + + + + + + + +
    + +

    The C and C++ front-ends represent information about the program in a format + that is effectively identical to Dwarf 3.0 in terms of + information content. This allows code generators to trivially support native + debuggers by generating standard dwarf information, and contains enough + information for non-dwarf targets to translate it as needed.

    + +

    This section describes the forms used to represent C and C++ programs. Other + languages could pattern themselves after this (which itself is tuned to + representing programs in the same way that Dwarf 3 does), or they could choose + to provide completely different forms if they don't fit into the Dwarf model. + As support for debugging information gets added to the various LLVM + source-language front-ends, the information used should be documented here.

    + +

    The following sections provide examples of various C/C++ constructs and the + debug information that would best describe those constructs.

    + +
    + + + + +
    + +

    Given the source files "MySource.cpp" and "MyHeader.h" located in the + directory "/Users/mine/sources", the following code:

    + +
    + #include "MyHeader.h"
    + 
    + int main(int argc, char *argv[]) {
    +   return 0;
    + }
    + 
    + +

    a C/C++ front-end would generate the following descriptors:

    + +
    + ...
    + ;;
    + ;; Define types used.  In this case we need one for compile unit anchors and one
    + ;; for compile units.
    + ;;
    + %llvm.dbg.anchor.type = type { uint, uint }
    + %llvm.dbg.compile_unit.type = type { uint, {  }*, uint, uint, sbyte*, sbyte*, sbyte* }
    + ...
    + ;;
    + ;; Define the anchor for compile units.  Note that the second field of the
    + ;; anchor is 17, which is the same as the tag for compile units
    + ;; (17 = DW_TAG_compile_unit.)
    + ;;
    + %llvm.dbg.compile_units = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 17 }, section "llvm.metadata"
    + 
    + ;;
    + ;; Define the compile unit for the source file "/Users/mine/sources/MySource.cpp".
    + ;;
    + %llvm.dbg.compile_unit1 = internal constant %llvm.dbg.compile_unit.type {
    +     uint add(uint 17, uint 262144), 
    +     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to {  }*), 
    +     uint 1, 
    +     uint 1, 
    +     sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0), 
    +     sbyte* getelementptr ([21 x sbyte]* %str2, int 0, int 0), 
    +     sbyte* getelementptr ([33 x sbyte]* %str3, int 0, int 0) }, section "llvm.metadata"
    +     
    + ;;
    + ;; Define the compile unit for the header file "/Users/mine/sources/MyHeader.h".
    + ;;
    + %llvm.dbg.compile_unit2 = internal constant %llvm.dbg.compile_unit.type {
    +     uint add(uint 17, uint 262144), 
    +     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to {  }*), 
    +     uint 1, 
    +     uint 1, 
    +     sbyte* getelementptr ([11 x sbyte]* %str4, int 0, int 0), 
    +     sbyte* getelementptr ([21 x sbyte]* %str2, int 0, int 0), 
    +     sbyte* getelementptr ([33 x sbyte]* %str3, int 0, int 0) }, section "llvm.metadata"
    + 
    + ;;
    + ;; Define each of the strings used in the compile units.
    + ;;
    + %str1 = internal constant [13 x sbyte] c"MySource.cpp\00", section "llvm.metadata";
    + %str2 = internal constant [21 x sbyte] c"/Users/mine/sources/\00", section "llvm.metadata";
    + %str3 = internal constant [33 x sbyte] c"4.0.1 LLVM (LLVM research group)\00", section "llvm.metadata";
    + %str4 = internal constant [11 x sbyte] c"MyHeader.h\00", section "llvm.metadata";
    + ...
    + 
    + +
    + + + + +
    + +

    Given an integer global variable declared as follows:

    + +
    + int MyGlobal = 100;
    + 
    + +

    a C/C++ front-end would generate the following descriptors:

    + +
    + ;;
    + ;; Define types used. One for global variable anchors, one for the global
    + ;; variable descriptor, one for the global's basic type and one for the global's
    + ;; compile unit.
    + ;;
    + %llvm.dbg.anchor.type = type { uint, uint }
    + %llvm.dbg.global_variable.type = type { uint, {  }*, {  }*, sbyte*, {  }*, uint, {  }*, bool, bool, {  }*, uint }
    + %llvm.dbg.basictype.type = type { uint, {  }*, sbyte*, {  }*, int, uint, uint, uint, uint }
    + %llvm.dbg.compile_unit.type = ...
    + ...
    + ;;
    + ;; Define the global itself.
    + ;;
    + %MyGlobal = global int 100
    + ...
    + ;;
    + ;; Define the anchor for global variables.  Note that the second field of the
    + ;; anchor is 52, which is the same as the tag for global variables
    + ;; (52 = DW_TAG_variable.)
    + ;;
    + %llvm.dbg.global_variables = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 52 }, section "llvm.metadata"
    + 
    + ;;
    + ;; Define the global variable descriptor.  Note the reference to the global
    + ;; variable anchor and the global variable itself.
    + ;;
    + %llvm.dbg.global_variable = internal constant %llvm.dbg.global_variable.type {
    +     uint add(uint 52, uint 262144), 
    +     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.global_variables to {  }*), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([9 x sbyte]* %str1, int 0, int 0), 
    +     sbyte* getelementptr ([1 x sbyte]* %str2, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     uint 1,
    +     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*), 
    +     bool false, 
    +     bool true, 
    +     {  }* cast (int* %MyGlobal to {  }*) }, section "llvm.metadata"
    +     
    + ;;
    + ;; Define the basic type of 32 bit signed integer.  Note that since int is an
    + ;; intrinsic type the source file is NULL and line 0.
    + ;;    
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     uint 5 }, section "llvm.metadata"
    + 
    + ;;
    + ;; Define the names of the global variable and basic type.
    + ;;
    + %str1 = internal constant [9 x sbyte] c"MyGlobal\00", section "llvm.metadata"
    + %str2 = internal constant [1 x sbyte] c"\00", section "llvm.metadata"
    + %str3 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
    + 
    + +
    + + + + +
    + +

    Given a function declared as follows:

    + +
    + int main(int argc, char *argv[]) {
    +   return 0;
    + }
    + 
    + +

    a C/C++ front-end would generate the following descriptors:

    + +
    + ;;
    + ;; Define types used. One for subprogram anchors, one for the subprogram
    + ;; descriptor, one for the global's basic type and one for the subprogram's
    + ;; compile unit.
    + ;;
    + %llvm.dbg.subprogram.type = type { uint, {  }*, {  }*, sbyte*, {  }*, bool, bool }
    + %llvm.dbg.anchor.type = type { uint, uint }
    + %llvm.dbg.compile_unit.type = ...
    + 	
    + ;;
    + ;; Define the anchor for subprograms.  Note that the second field of the
    + ;; anchor is 46, which is the same as the tag for subprograms
    + ;; (46 = DW_TAG_subprogram.)
    + ;;
    + %llvm.dbg.subprograms = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 46 }, section "llvm.metadata"
    + 
    + ;;
    + ;; Define the descriptor for the subprogram.  TODO - more details.
    + ;;
    + %llvm.dbg.subprogram = internal constant %llvm.dbg.subprogram.type {
    +     uint add(uint 46, uint 262144), 
    +     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.subprograms to {  }*), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0), 
    +     sbyte* getelementptr ([1 x sbyte]* %str2, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*),
    +     uint 1,
    +     {  }* null, 
    +     bool false, 
    +     bool true }, section "llvm.metadata"
    + 
    + ;;
    + ;; Define the name of the subprogram.
    + ;;
    + %str1 = internal constant [5 x sbyte] c"main\00", section "llvm.metadata"
    + %str2 = internal constant [1 x sbyte] c"\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define the subprogram itself.
    + ;;
    + int %main(int %argc, sbyte** %argv) {
    + ...
    + }
    + 
    + +
    + + + + +
    + +

    The following are the basic type descriptors for C/C++ core types:

    + +
    + + +
    + bool +
    + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     uint 2 }, section "llvm.metadata"
    + %str1 = internal constant [5 x sbyte] c"bool\00", section "llvm.metadata"
    + 
    + +
    + + +
    + char +
    + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 8, 
    +     uint 8, 
    +     uint 0, 
    +     uint 6 }, section "llvm.metadata"
    + %str1 = internal constant [5 x sbyte] c"char\00", section "llvm.metadata"
    + 
    + +
    + + + + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([14 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 8, 
    +     uint 8, 
    +     uint 0, 
    +     uint 8 }, section "llvm.metadata"
    + %str1 = internal constant [14 x sbyte] c"unsigned char\00", section "llvm.metadata"
    + 
    + +
    + + +
    + short +
    + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([10 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 16, 
    +     uint 16, 
    +     uint 0, 
    +     uint 5 }, section "llvm.metadata"
    + %str1 = internal constant [10 x sbyte] c"short int\00", section "llvm.metadata"
    + 
    + +
    + + + + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([19 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 16, 
    +     uint 16, 
    +     uint 0, 
    +     uint 7 }, section "llvm.metadata"
    + %str1 = internal constant [19 x sbyte] c"short unsigned int\00", section "llvm.metadata"
    + 
    + +
    + + +
    + int +
    + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([4 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     uint 5 }, section "llvm.metadata"
    + %str1 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
    + 
    + +
    + + + + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     uint 7 }, section "llvm.metadata"
    + %str1 = internal constant [13 x sbyte] c"unsigned int\00", section "llvm.metadata"
    + 
    + +
    + + +
    + long long +
    + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([14 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 64, 
    +     uint 64, 
    +     uint 0, 
    +     uint 5 }, section "llvm.metadata"
    + %str1 = internal constant [14 x sbyte] c"long long int\00", section "llvm.metadata"
    + 
    + +
    + + + + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([23 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 64, 
    +     uint 64, 
    +     uint 0, 
    +     uint 7 }, section "llvm.metadata"
    + %str1 = internal constant [23 x sbyte] c"long long unsigned int\00", section "llvm.metadata"
    + 
    + +
    + + +
    + float +
    + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([6 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     uint 4 }, section "llvm.metadata"
    + %str1 = internal constant [6 x sbyte] c"float\00", section "llvm.metadata"
    + 
    + +
    + + +
    + double +
    + +
    + +
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([7 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 64, 
    +     uint 64, 
    +     uint 0, 
    +     uint 4 }, section "llvm.metadata"
    + %str1 = internal constant [7 x sbyte] c"double\00", section "llvm.metadata"
    + 
    + +
    + + + + +
    + +

    Given the following as an example of C/C++ derived type:

    + +
    + typedef const int *IntPtr;
    + 
    + +

    a C/C++ front-end would generate the following descriptors:

    + +
    + ;;
    + ;; Define the typedef "IntPtr".
    + ;;
    + %llvm.dbg.derivedtype1 = internal constant %llvm.dbg.derivedtype.type {
    +     uint add(uint 22, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([7 x sbyte]* %str1, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     int 1, 
    +     uint 0, 
    +     uint 0, 
    +     uint 0, 
    +     {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype2 to {  }*) }, section "llvm.metadata"
    + %str1 = internal constant [7 x sbyte] c"IntPtr\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define the pointer type.
    + ;;
    + %llvm.dbg.derivedtype2 = internal constant %llvm.dbg.derivedtype.type {
    +     uint add(uint 15, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* null, 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype3 to {  }*) }, section "llvm.metadata"
    + 
    + ;;
    + ;; Define the const type.
    + ;;
    + %llvm.dbg.derivedtype3 = internal constant %llvm.dbg.derivedtype.type {
    +     uint add(uint 38, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* null, 
    +     {  }* null, 
    +     int 0, 
    +     uint 0, 
    +     uint 0, 
    +     uint 0, 
    +     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype1 to {  }*) }, section "llvm.metadata"	
    + 
    + ;;
    + ;; Define the int type.
    + ;;
    + %llvm.dbg.basictype1 = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([4 x sbyte]* %str2, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     uint 5 }, section "llvm.metadata"
    + %str2 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
    + 
    + +
    + + + + +
    + +

    Given the following as an example of C/C++ struct type:

    + +
    + struct Color {
    +   unsigned Red;
    +   unsigned Green;
    +   unsigned Blue;
    + };
    + 
    + +

    a C/C++ front-end would generate the following descriptors:

    + +
    + ;;
    + ;; Define basic type for unsigned int.
    + ;;
    + %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
    +     uint add(uint 36, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0), 
    +     {  }* null, 
    +     int 0, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     uint 7 }, section "llvm.metadata"
    + %str1 = internal constant [13 x sbyte] c"unsigned int\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define composite type for struct Color.
    + ;;
    + %llvm.dbg.compositetype = internal constant %llvm.dbg.compositetype.type {
    +     uint add(uint 19, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([6 x sbyte]* %str2, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     int 1, 
    +     uint 96, 
    +     uint 32, 
    +     uint 0, 
    +     {  }* null,
    +     {  }* cast ([3 x {  }*]* %llvm.dbg.array to {  }*) }, section "llvm.metadata"
    + %str2 = internal constant [6 x sbyte] c"Color\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define the Red field.
    + ;;
    + %llvm.dbg.derivedtype1 = internal constant %llvm.dbg.derivedtype.type {
    +     uint add(uint 13, uint 262144), 
    +     {  }* null, 
    +     sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     int 2, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*) }, section "llvm.metadata"
    + %str3 = internal constant [4 x sbyte] c"Red\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define the Green field.
    + ;;
    + %llvm.dbg.derivedtype2 = internal constant %llvm.dbg.derivedtype.type {
    +     uint add(uint 13, uint 262144), 
    +     {  }* null, 
    +     sbyte* getelementptr ([6 x sbyte]* %str4, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     int 3, 
    +     uint 32, 
    +     uint 32, 
    +     uint 32, 
    +     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*) }, section "llvm.metadata"
    + %str4 = internal constant [6 x sbyte] c"Green\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define the Blue field.
    + ;;
    + %llvm.dbg.derivedtype3 = internal constant %llvm.dbg.derivedtype.type {
    +     uint add(uint 13, uint 262144), 
    +     {  }* null, 
    +     sbyte* getelementptr ([5 x sbyte]* %str5, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     int 4, 
    +     uint 32, 
    +     uint 32, 
    +     uint 64, 
    +     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*) }, section "llvm.metadata"
    + %str5 = internal constant [5 x sbyte] c"Blue\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define the array of fields used by the composite type Color.
    + ;;
    + %llvm.dbg.array = internal constant [3 x {  }*] [
    +       {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype1 to {  }*),
    +       {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype2 to {  }*),
    +       {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype3 to {  }*) ], section "llvm.metadata"
    + 
    + +
    + + + + +
    + +

    Given the following as an example of C/C++ enumeration type:

    + +
    + enum Trees {
    +   Spruce = 100,
    +   Oak = 200,
    +   Maple = 300
    + };
    + 
    + +

    a C/C++ front-end would generate the following descriptors:

    + +
    + ;;
    + ;; Define composite type for enum Trees
    + ;;
    + %llvm.dbg.compositetype = internal constant %llvm.dbg.compositetype.type {
    +     uint add(uint 4, uint 262144), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     sbyte* getelementptr ([6 x sbyte]* %str1, int 0, int 0), 
    +     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
    +     int 1, 
    +     uint 32, 
    +     uint 32, 
    +     uint 0, 
    +     {  }* null, 
    +     {  }* cast ([3 x {  }*]* %llvm.dbg.array to {  }*) }, section "llvm.metadata"
    + %str1 = internal constant [6 x sbyte] c"Trees\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define Spruce enumerator.
    + ;;
    + %llvm.dbg.enumerator1 = internal constant %llvm.dbg.enumerator.type {
    +     uint add(uint 40, uint 262144), 
    +     sbyte* getelementptr ([7 x sbyte]* %str2, int 0, int 0), 
    +     int 100 }, section "llvm.metadata"
    + %str2 = internal constant [7 x sbyte] c"Spruce\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define Oak enumerator.
    + ;;
    + %llvm.dbg.enumerator2 = internal constant %llvm.dbg.enumerator.type {
    +     uint add(uint 40, uint 262144), 
    +     sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0), 
    +     int 200 }, section "llvm.metadata"
    + %str3 = internal constant [4 x sbyte] c"Oak\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define Maple enumerator.
    + ;;
    + %llvm.dbg.enumerator3 = internal constant %llvm.dbg.enumerator.type {
    +     uint add(uint 40, uint 262144), 
    +     sbyte* getelementptr ([6 x sbyte]* %str4, int 0, int 0), 
    +     int 300 }, section "llvm.metadata"
    + %str4 = internal constant [6 x sbyte] c"Maple\00", section "llvm.metadata"
    + 
    + ;;
    + ;; Define the array of enumerators used by composite type Trees.
    + ;;
    + %llvm.dbg.array = internal constant [3 x {  }*] [
    +   {  }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator1 to {  }*),
    +   {  }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator2 to {  }*),
    +   {  }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator3 to {  }*) ], section "llvm.metadata"
    + 
    + +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Chris Lattner
    + LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/SystemLibrary.html diff -c /dev/null llvm-www/releases/2.5/docs/SystemLibrary.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/SystemLibrary.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,344 ---- + + + + System Library + + + + +
    System Library
    + + +
    +

    Written by Reid Spencer

    +
    + + + + +
    +

    This document provides some details on LLVM's System Library, located in + the source at lib/System and include/llvm/System. The + library's purpose is to shield LLVM from the differences between operating + systems for the few services LLVM needs from the operating system. Much of + LLVM is written using portability features of standard C++. However, in a few + areas, system dependent facilities are needed and the System Library is the + wrapper around those system calls.

    +

    By centralizing LLVM's use of operating system interfaces, we make it + possible for the LLVM tool chain and runtime libraries to be more easily + ported to new platforms since (theoretically) only lib/System needs + to be ported. This library also unclutters the rest of LLVM from #ifdef use + and special cases for specific operating systems. Such uses are replaced + with simple calls to the interfaces provided in include/llvm/System. +

    +

    Note that the System Library is not intended to be a complete operating + system wrapper (such as the Adaptive Communications Environment (ACE) or + Apache Portable Runtime (APR)), but only provides the functionality necessary + to support LLVM. +

    The System Library was written by Reid Spencer who formulated the + design based on similar work originating from the eXtensible Programming + System (XPS). Several people helped with the effort; especially, + Jeff Cohen and Henrik Bach on the Win32 port.

    +
    + + + +
    +

    In order to keep LLVM portable, LLVM developers should adhere to a set of + portability rules associated with the System Library. Adherence to these rules + should help the System Library achieve its goal of shielding LLVM from the + variations in operating system interfaces and doing so efficiently. The + following sections define the rules needed to fulfill this objective.

    +
    + + + +
    +

    Except in lib/System, no LLVM source code should directly + #include a system header. Care has been taken to remove all such + #includes from LLVM while lib/System was being + developed. Specifically this means that header files like "unistd.h", + "windows.h", "stdio.h", and "string.h" are forbidden to be included by LLVM + source code outside the implementation of lib/System.

    +

    To obtain system-dependent functionality, existing interfaces to the system + found in include/llvm/System should be used. If an appropriate + interface is not available, it should be added to include/llvm/System + and implemented in lib/System for all supported platforms.

    +
    + + + +
    +

    The System Library must shield LLVM from all system headers. To + obtain system level functionality, LLVM source must + #include "llvm/System/Thing.h" and nothing else. This means that + Thing.h cannot expose any system header files. This protects LLVM + from accidentally using system specific functionality and only allows it + via the lib/System interface.

    +
    + + + +
    +

    The standard C headers (the ones beginning with "c") are allowed + to be exposed through the lib/System interface. These headers and + the things they declare are considered to be platform agnostic. LLVM source + files may include them directly or obtain their inclusion through + lib/System interfaces.

    +
    + + + +
    +

    The standard C++ headers from the standard C++ library and + standard template library may be exposed through the lib/System + interface. These headers and the things they declare are considered to be + platform agnostic. LLVM source files may include them or obtain their + inclusion through lib/System interfaces.

    +
    + + + +
    +

    The entry points specified in the interface of lib/System must be aimed at + completing some reasonably high level task needed by LLVM. We do not want to + simply wrap each operating system call. It would be preferable to wrap several + operating system calls that are always used in conjunction with one another by + LLVM.

    +

    For example, consider what is needed to execute a program, wait for it to + complete, and return its result code. On Unix, this involves the following + operating system calls: getenv, fork, execve, and wait. The + correct thing for lib/System to provide is a function, say + ExecuteProgramAndWait, that implements the functionality completely. + what we don't want is wrappers for the operating system calls involved.

    +

    There must not be a one-to-one relationship between operating + system calls and the System library's interface. Any such interface function + will be suspicious.

    +
    + + + +
    +

    There must be no functionality specified in the interface of lib/System + that isn't actually used by LLVM. We're not writing a general purpose + operating system wrapper here, just enough to satisfy LLVM's needs. And, LLVM + doesn't need much. This design goal aims to keep the lib/System interface + small and understandable which should foster its actual use and adoption.

    +
    + + + +
    +

    The implementation of a function for a given platform must be written + exactly once. This implies that it must be possible to apply a function's + implementation to multiple operating systems if those operating systems can + share the same implementation. This rule applies to the set of operating + systems supported for a given class of operating system (e.g. Unix, Win32). +

    +
    + + + +
    +

    The System Library interfaces can be called quite frequently by LLVM. In + order to make those calls as efficient as possible, we discourage the use of + virtual methods. There is no need to use inheritance for implementation + differences, it just adds complexity. The #include mechanism works + just fine.

    +
    + + + +
    +

    Any functions defined by system libraries (i.e. not defined by lib/System) + must not be exposed through the lib/System interface, even if the header file + for that function is not exposed. This prevents inadvertent use of system + specific functionality.

    +

    For example, the stat system call is notorious for having + variations in the data it provides. lib/System must not declare + stat nor allow it to be declared. Instead it should provide its own + interface to discovering information about files and directories. Those + interfaces may be implemented in terms of stat but that is strictly + an implementation detail. The interface provided by the System Library must + be implemented on all platforms (even those without stat).

    +
    + + + +
    +

    Any data defined by system libraries (i.e. not defined by lib/System) must + not be exposed through the lib/System interface, even if the header file for + that function is not exposed. As with functions, this prevents inadvertent use + of data that might not exist on all platforms.

    +
    + + + +
    +

    Operating system interfaces will generally provide error results for every + little thing that could go wrong. In almost all cases, you can divide these + error results into two groups: normal/good/soft and abnormal/bad/hard. That + is, some of the errors are simply information like "file not found", + "insufficient privileges", etc. while other errors are much harder like + "out of space", "bad disk sector", or "system call interrupted". We'll call + the first group "soft" errors and the second group "hard" + errors.

    +

    lib/System must always attempt to minimize soft errors and always just + throw a std::string on hard errors. This is a design requirement because the + minimization of soft errors can affect the granularity and the nature of the + interface. In general, if you find that you're wanting to throw soft errors, + you must review the granularity of the interface because it is likely you're + trying to implement something that is too low level. The rule of thumb is to + provide interface functions that can't fail, except when faced with + hard errors.

    +

    For a trivial example, suppose we wanted to add an "OpenFileForWriting" + function. For many operating systems, if the file doesn't exist, attempting + to open the file will produce an error. However, lib/System should not + simply throw that error if it occurs because its a soft error. The problem + is that the interface function, OpenFileForWriting is too low level. It should + be OpenOrCreateFileForWriting. In the case of the soft "doesn't exist" error, + this function would just create it and then open it for writing.

    +

    This design principle needs to be maintained in lib/System because it + avoids the propagation of soft error handling throughout the rest of LLVM. + Hard errors will generally just cause a termination for an LLVM tool so don't + be bashful about throwing them.

    +

    Rules of thumb:

    +
      +
    1. Don't throw soft errors, only hard errors.
    2. +
    3. If you're tempted to throw a soft error, re-think the interface.
    4. +
    5. Handle internally the most common normal/good/soft error conditions + so the rest of LLVM doesn't have to.
    6. +
    +
    + + + +
    +

    If an error occurs that lib/System cannot handle, the only action taken by + lib/System is to throw an instance of std:string. The contents of the string + must explain both what happened and the context in which it happened. The + format of the string should be a (possibly empty) list of contexts each + terminated with a : and a space, followed by the error message, optionally + followed by a reason, and optionally followed by a suggestion.

    +

    For example, failure to open a file named "foo" could result in a message + like:

    +
    • foo: Unable to open file because it doesn't exist."
    +

    The "foo:" part is the context. The "Unable to open file" part is the error + message. The "because it doesn't exist." part is the reason. This message has + no suggestion. Where possible, the implementation of lib/System should use + operating system specific facilities for converting the error code returned by + a system call into an error message. This will help to make the error message + more familiar to users of that type of operating system.

    +

    Note that this requirement precludes the throwing of any other exceptions. + For example, various C++ standard library functions can cause exceptions to be + thrown (e.g. out of memory situation). In all cases, if there is a possibility + that non-string exceptions could be thrown, the lib/System library must ensure + that the exceptions are translated to std::string form.

    +
    + + + +
    +

    None of the lib/System interface functions may be declared with C++ + throw() specifications on them. This requirement makes sure that the + compiler does not insert additional exception handling code into the interface + functions. This is a performance consideration: lib/System functions are at + the bottom of many call chains and as such can be frequently called. We + need them to be as efficient as possible.

    +
    + + + +
    +

    Implementations of the System Library interface are separated by their + general class of operating system. Currently only Unix and Win32 classes are + defined but more could be added for other operating system classifications. + To distinguish which implementation to compile, the code in lib/System uses + the LLVM_ON_UNIX and LLVM_ON_WIN32 #defines provided via configure through the + llvm/Config/config.h file. Each source file in lib/System, after implementing + the generic (operating system independent) functionality needs to include the + correct implementation using a set of #if defined(LLVM_ON_XYZ) + directives. For example, if we had lib/System/File.cpp, we'd expect to see in + that file:

    +
    
    +   #if defined(LLVM_ON_UNIX)
    +   #include "Unix/File.cpp"
    +   #endif
    +   #if defined(LLVM_ON_WIN32)
    +   #include "Win32/File.cpp"
    +   #endif
    +   
    +

    The implementation in lib/System/Unix/File.cpp should handle all Unix + variants. The implementation in lib/System/Win32/File.cpp should handle all + Win32 variants. What this does is quickly differentiate the basic class of + operating system that will provide the implementation. The specific details + for a given platform must still be determined through the use of + #ifdef.

    +
    + + + +
    +

    The implementation of a lib/System interface can vary drastically between + platforms. That's okay as long as the end result of the interface function + is the same. For example, a function to create a directory is pretty straight + forward on all operating system. System V IPC on the other hand isn't even + supported on all platforms. Instead of "supporting" System V IPC, lib/System + should provide an interface to the basic concept of inter-process + communications. The implementations might use System V IPC if that was + available or named pipes, or whatever gets the job done effectively for a + given operating system. In all cases, the interface and the implementation + must be semantically consistent.

    +
    + + + +
    +

    See bug 351 + for further details on the progress of this work

    +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Reid Spencer
    + LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + Index: llvm-www/releases/2.5/docs/TableGenFundamentals.html diff -c /dev/null llvm-www/releases/2.5/docs/TableGenFundamentals.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/TableGenFundamentals.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,753 ---- + + + + TableGen Fundamentals + + + + +
    TableGen Fundamentals
    + + + +
    +

    Written by Chris Lattner

    +
    + + + + + +
    + +

    TableGen's purpose is to help a human develop and maintain records of + domain-specific information. Because there may be a large number of these + records, it is specifically designed to allow writing flexible descriptions and + for common features of these records to be factored out. This reduces the + amount of duplication in the description, reduces the chance of error, and + makes it easier to structure domain specific information.

    + +

    The core part of TableGen parses a file, instantiates + the declarations, and hands the result off to a domain-specific "TableGen backend" for processing. The current major user + of TableGen is the LLVM code generator.

    + +

    Note that if you work on TableGen much, and use emacs or vim, that you can + find an emacs "TableGen mode" and a vim language file in the + llvm/utils/emacs and llvm/utils/vim directories of your LLVM + distribution, respectively.

    + +
    + + + + +
    + +

    TableGen files consist of two key parts: 'classes' and 'definitions', both + of which are considered 'records'.

    + +

    TableGen records have a unique name, a list of values, and a list of + superclasses. The list of values is the main data that TableGen builds for each + record; it is this that holds the domain specific information for the + application. The interpretation of this data is left to a specific TableGen backend, but the structure and format rules are + taken care of and are fixed by TableGen.

    + +

    TableGen definitions are the concrete form of 'records'. These + generally do not have any undefined values, and are marked with the + 'def' keyword.

    + +

    TableGen classes are abstract records that are used to build and + describe other records. These 'classes' allow the end-user to build + abstractions for either the domain they are targeting (such as "Register", + "RegisterClass", and "Instruction" in the LLVM code generator) or for the + implementor to help factor out common properties of records (such as "FPInst", + which is used to represent floating point instructions in the X86 backend). + TableGen keeps track of all of the classes that are used to build up a + definition, so the backend can find all definitions of a particular class, such + as "Instruction".

    + +

    TableGen multiclasses are groups of abstract records that are + instantiated all at once. Each instantiation can result in multiple TableGen + definitions.

    + +
    + + + + +
    + +

    With no other arguments, TableGen parses the specified file and prints out + all of the classes, then all of the definitions. This is a good way to see what + the various definitions expand to fully. Running this on the X86.td + file prints this (at the time of this writing):

    + +
    +
    + ...
    + def ADD32rr {   // Instruction X86Inst I
    +   string Namespace = "X86";
    +   dag OutOperandList = (outs GR32:$dst);
    +   dag InOperandList = (ins GR32:$src1, GR32:$src2);
    +   string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
    +   list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
    +   list<Register> Uses = [];
    +   list<Register> Defs = [EFLAGS];
    +   list<Predicate> Predicates = [];
    +   int CodeSize = 3;
    +   int AddedComplexity = 0;
    +   bit isReturn = 0;
    +   bit isBranch = 0;
    +   bit isIndirectBranch = 0;
    +   bit isBarrier = 0;
    +   bit isCall = 0;
    +   bit canFoldAsLoad = 0;
    +   bit mayLoad = 0;
    +   bit mayStore = 0;
    +   bit isImplicitDef = 0;
    +   bit isTwoAddress = 1;
    +   bit isConvertibleToThreeAddress = 1;
    +   bit isCommutable = 1;
    +   bit isTerminator = 0;
    +   bit isReMaterializable = 0;
    +   bit isPredicable = 0;
    +   bit hasDelaySlot = 0;
    +   bit usesCustomDAGSchedInserter = 0;
    +   bit hasCtrlDep = 0;
    +   bit isNotDuplicable = 0;
    +   bit hasSideEffects = 0;
    +   bit mayHaveSideEffects = 0;
    +   bit neverHasSideEffects = 0;
    +   InstrItinClass Itinerary = NoItinerary;
    +   string Constraints = "";
    +   string DisableEncoding = "";
    +   bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
    +   Format Form = MRMDestReg;
    +   bits<6> FormBits = { 0, 0, 0, 0, 1, 1 };
    +   ImmType ImmT = NoImm;
    +   bits<3> ImmTypeBits = { 0, 0, 0 };
    +   bit hasOpSizePrefix = 0;
    +   bit hasAdSizePrefix = 0;
    +   bits<4> Prefix = { 0, 0, 0, 0 };
    +   bit hasREX_WPrefix = 0;
    +   FPFormat FPForm = ?;
    +   bits<3> FPFormBits = { 0, 0, 0 };
    + }
    + ...
    + 
    +
    + +

    This definition corresponds to a 32-bit register-register add instruction in + the X86. The string after the 'def' string indicates the name of the + record—"ADD32rr" in this case—and the comment at the end of + the line indicates the superclasses of the definition. The body of the record + contains all of the data that TableGen assembled for the record, indicating that + the instruction is part of the "X86" namespace, the pattern indicating how the + the instruction should be emitted into the assembly file, that it is a + two-address instruction, has a particular encoding, etc. The contents and + semantics of the information in the record is specific to the needs of the X86 + backend, and is only shown as an example.

    + +

    As you can see, a lot of information is needed for every instruction + supported by the code generator, and specifying it all manually would be + unmaintainble, prone to bugs, and tiring to do in the first place. Because we + are using TableGen, all of the information was derived from the following + definition:

    + +
    +
    + let Defs = [EFLAGS],
    +     isCommutable = 1,                  // X = ADD Y,Z --> X = ADD Z,Y
    +     isConvertibleToThreeAddress = 1 in // Can transform into LEA.
    + def ADD32rr  : I<0x01, MRMDestReg, (outs GR32:$dst),
    +                                    (ins GR32:$src1, GR32:$src2),
    +                  "add{l}\t{$src2, $dst|$dst, $src2}",
    +                  [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
    + 
    +
    + +

    This definition makes use of the custom class I (extended from the + custom class X86Inst), which is defined in the X86-specific TableGen + file, to factor out the common features that instructions of its class share. A + key feature of TableGen is that it allows the end-user to define the + abstractions they prefer to use when describing their information.

    + +
    + + + + +
    + +

    TableGen runs just like any other LLVM tool. The first (optional) argument + specifies the file to read. If a filename is not specified, tblgen + reads from standard input.

    + +

    To be useful, one of the TableGen backends must be + used. These backends are selectable on the command line (type 'tblgen + -help' for a list). For example, to get a list of all of the definitions + that subclass a particular type (which can be useful for building up an enum + list of these records), use the -print-enums option:

    + +
    +
    + $ tblgen X86.td -print-enums -class=Register
    + AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
    + ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
    + MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
    + R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
    + R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
    + RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
    + XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
    + XMM6, XMM7, XMM8, XMM9,
    + 
    + $ tblgen X86.td -print-enums -class=Instruction 
    + ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
    + ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
    + ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
    + ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
    + ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
    + 
    +
    + +

    The default backend prints out all of the records, as described above.

    + +

    If you plan to use TableGen, you will most likely have to write a backend that extracts the information specific to + what you need and formats it in the appropriate way.

    + +
    + + + + + + +
    + +

    TableGen doesn't care about the meaning of data (that is up to the backend to + define), but it does care about syntax, and it enforces a simple type system. + This section describes the syntax and the constructs allowed in a TableGen file. +

    + +
    + + + + + + + +
    + +

    TableGen supports BCPL style "//" comments, which run to the end of + the line, and it also supports nestable "/* */" comments.

    + +
    + + + + +
    + +

    TableGen files are strongly typed, in a simple (but complete) type-system. + These types are used to perform automatic conversions, check for errors, and to + help interface designers constrain the input that they allow. Every value definition is required to have an associated type. +

    + +

    TableGen supports a mixture of very low-level types (such as bit) + and very high-level types (such as dag). This flexibility is what + allows it to describe a wide range of information conveniently and compactly. + The TableGen types are:

    + +
    +
    bit
    +
    A 'bit' is a boolean value that can hold either 0 or 1.
    + +
    int
    +
    The 'int' type represents a simple 32-bit integer value, such as 5.
    + +
    string
    +
    The 'string' type represents an ordered sequence of characters of + arbitrary length.
    + +
    bits<n>
    +
    A 'bits' type is an arbitrary, but fixed, size integer that is broken up + into individual bits. This type is useful because it can handle some bits + being defined while others are undefined.
    + +
    list<ty>
    +
    This type represents a list whose elements are some other type. The + contained type is arbitrary: it can even be another list type.
    + +
    Class type
    +
    Specifying a class name in a type context means that the defined value + must be a subclass of the specified class. This is useful in conjunction with + the list type, for example, to constrain the elements of the + list to a common base class (e.g., a list<Register> can + only contain definitions derived from the "Register" class).
    + +
    dag
    +
    This type represents a nestable directed graph of elements.
    + +
    code
    +
    This represents a big hunk of text. NOTE: I don't remember why this is + distinct from string!
    +
    + +

    To date, these types have been sufficient for describing things that + TableGen has been used for, but it is straight-forward to extend this list if + needed.

    + +
    + + + + +
    + +

    TableGen allows for a pretty reasonable number of different expression forms + when building up values. These forms allow the TableGen file to be written in a + natural syntax and flavor for the application. The current expression forms + supported include:

    + +
    +
    ?
    +
    uninitialized field
    +
    0b1001011
    +
    binary integer value
    +
    07654321
    +
    octal integer value (indicated by a leading 0)
    +
    7
    +
    decimal integer value
    +
    0x7F
    +
    hexadecimal integer value
    +
    "foo"
    +
    string value
    +
    [{ ... }]
    +
    code fragment
    +
    [ X, Y, Z ]
    +
    list value.
    +
    { a, b, c }
    +
    initializer for a "bits<3>" value
    +
    value
    +
    value reference
    +
    value{17}
    +
    access to one bit of a value
    +
    value{15-17}
    +
    access to multiple bits of a value
    +
    DEF
    +
    reference to a record definition
    +
    CLASS<val list>
    +
    reference to a new anonymous definition of CLASS with the specified + template arguments.
    +
    X.Y
    +
    reference to the subfield of a value
    +
    list[4-7,17,2-3]
    +
    A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from + it. Elements may be included multiple times.
    +
    (DEF a, b)
    +
    a dag value. The first element is required to be a record definition, the + remaining elements in the list may be arbitrary other values, including nested + `dag' values.
    +
    !strconcat(a, b)
    +
    A string value that is the result of concatenating the 'a' and 'b' + strings.
    +
    + +

    Note that all of the values have rules specifying how they convert to values + for different types. These rules allow you to assign a value like "7" + to a "bits<4>" value, for example.

    + +
    + + + + +
    + +

    As mentioned in the intro, classes and definitions + (collectively known as 'records') in TableGen are the main high-level unit of + information that TableGen collects. Records are defined with a def or + class keyword, the record name, and an optional list of "template arguments". If the record has superclasses, + they are specified as a comma separated list that starts with a colon character + (":"). If value definitions or let expressions are needed for the class, they are + enclosed in curly braces ("{}"); otherwise, the record ends with a + semicolon.

    + +

    Here is a simple TableGen file:

    + +
    +
    + class C { bit V = 1; }
    + def X : C;
    + def Y : C {
    +   string Greeting = "hello";
    + }
    + 
    +
    + +

    This example defines two definitions, X and Y, both of + which derive from the C class. Because of this, they both get the + V bit value. The Y definition also gets the Greeting member + as well.

    + +

    In general, classes are useful for collecting together the commonality + between a group of records and isolating it in a single place. Also, classes + permit the specification of default values for their subclasses, allowing the + subclasses to override them as they wish.

    + +
    + + + + +
    + +

    Value definitions define named entries in records. A value must be defined + before it can be referred to as the operand for another value definition or + before the value is reset with a let expression. A + value is defined by specifying a TableGen type and a name. + If an initial value is available, it may be specified after the type with an + equal sign. Value definitions require terminating semicolons.

    + +
    + + + + +
    + +

    A record-level let expression is used to change the value of a value + definition in a record. This is primarily useful when a superclass defines a + value that a derived class or definition wants to override. Let expressions + consist of the 'let' keyword followed by a value name, an equal sign + ("="), and a new value. For example, a new class could be added to the + example above, redefining the V field for all of its subclasses:

    + +
    +
    + class D : C { let V = 0; }
    + def Z : D;
    + 
    +
    + +

    In this case, the Z definition will have a zero value for its "V" + value, despite the fact that it derives (indirectly) from the C class, + because the D class overrode its value.

    + +
    + + + + +
    + +

    TableGen permits the definition of parameterized classes as well as normal + concrete classes. Parameterized TableGen classes specify a list of variable + bindings (which may optionally have defaults) that are bound when used. Here is + a simple example:

    + +
    +
    + class FPFormat<bits<3> val> {
    +   bits<3> Value = val;
    + }
    + def NotFP      : FPFormat<0>;
    + def ZeroArgFP  : FPFormat<1>;
    + def OneArgFP   : FPFormat<2>;
    + def OneArgFPRW : FPFormat<3>;
    + def TwoArgFP   : FPFormat<4>;
    + def CompareFP  : FPFormat<5>;
    + def CondMovFP  : FPFormat<6>;
    + def SpecialFP  : FPFormat<7>;
    + 
    +
    + +

    In this case, template arguments are used as a space efficient way to specify + a list of "enumeration values", each with a "Value" field set to the + specified integer.

    + +

    The more esoteric forms of TableGen expressions are + useful in conjunction with template arguments. As an example:

    + +
    +
    + class ModRefVal<bits<2> val> {
    +   bits<2> Value = val;
    + }
    + 
    + def None   : ModRefVal<0>;
    + def Mod    : ModRefVal<1>;
    + def Ref    : ModRefVal<2>;
    + def ModRef : ModRefVal<3>;
    + 
    + class Value<ModRefVal MR> {
    +   // Decode some information into a more convenient format, while providing
    +   // a nice interface to the user of the "Value" class.
    +   bit isMod = MR.Value{0};
    +   bit isRef = MR.Value{1};
    + 
    +   // other stuff...
    + }
    + 
    + // Example uses
    + def bork : Value<Mod>;
    + def zork : Value<Ref>;
    + def hork : Value<ModRef>;
    + 
    +
    + +

    This is obviously a contrived example, but it shows how template arguments + can be used to decouple the interface provided to the user of the class from the + actual internal data representation expected by the class. In this case, + running tblgen on the example prints the following definitions:

    + +
    +
    + def bork {      // Value
    +   bit isMod = 1;
    +   bit isRef = 0;
    + }
    + def hork {      // Value
    +   bit isMod = 1;
    +   bit isRef = 1;
    + }
    + def zork {      // Value
    +   bit isMod = 0;
    +   bit isRef = 1;
    + }
    + 
    +
    + +

    This shows that TableGen was able to dig into the argument and extract a + piece of information that was requested by the designer of the "Value" class. + For more realistic examples, please see existing users of TableGen, such as the + X86 backend.

    + +
    + + + + +
    + +

    + While classes with template arguments are a good way to factor commonality + between two instances of a definition, multiclasses allow a convenient notation + for defining multiple definitions at once (instances of implicitly constructed + classes). For example, consider an 3-address instruction set whose instructions + come in two forms: "reg = reg op reg" and "reg = reg op imm" + (e.g. SPARC). In this case, you'd like to specify in one place that this + commonality exists, then in a separate place indicate what all the ops are. +

    + +

    + Here is an example TableGen fragment that shows this idea: +

    + +
    +
    + def ops;
    + def GPR;
    + def Imm;
    + class inst<int opc, string asmstr, dag operandlist>;
    + 
    + multiclass ri_inst<int opc, string asmstr> {
    +   def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
    +                  (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
    +   def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
    +                  (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
    + }
    + 
    + // Instantiations of the ri_inst multiclass.
    + defm ADD : ri_inst<0b111, "add">;
    + defm SUB : ri_inst<0b101, "sub">;
    + defm MUL : ri_inst<0b100, "mul">;
    + ...
    + 
    +
    + +

    The name of the resultant definitions has the multidef fragment names + appended to them, so this defines ADD_rr, ADD_ri, + SUB_rr, etc. Using a multiclass this way is exactly equivalent to + instantiating the classes multiple times yourself, e.g. by writing:

    + +
    +
    + def ops;
    + def GPR;
    + def Imm;
    + class inst<int opc, string asmstr, dag operandlist>;
    + 
    + class rrinst<int opc, string asmstr>
    +   : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
    +          (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
    + 
    + class riinst<int opc, string asmstr>
    +   : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
    +          (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
    + 
    + // Instantiations of the ri_inst multiclass.
    + def ADD_rr : rrinst<0b111, "add">;
    + def ADD_ri : riinst<0b111, "add">;
    + def SUB_rr : rrinst<0b101, "sub">;
    + def SUB_ri : riinst<0b101, "sub">;
    + def MUL_rr : rrinst<0b100, "mul">;
    + def MUL_ri : riinst<0b100, "mul">;
    + ...
    + 
    +
    + +
    + + + + + + + +
    +

    TableGen supports the 'include' token, which textually substitutes + the specified file in place of the include directive. The filename should be + specified as a double quoted string immediately after the 'include' + keyword. Example:

    + +
    +
    + include "foo.td"
    + 
    +
    + +
    + + + + +
    + +

    "Let" expressions at file scope are similar to "let" + expressions within a record, except they can specify a value binding for + multiple records at a time, and may be useful in certain other cases. + File-scope let expressions are really just another way that TableGen allows the + end-user to factor out commonality from the records.

    + +

    File-scope "let" expressions take a comma-separated list of bindings to + apply, and one or more records to bind the values in. Here are some + examples:

    + +
    +
    + let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
    +   def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
    + 
    + let isCall = 1 in
    +   // All calls clobber the non-callee saved registers...
    +   let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
    +               MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
    +               XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] in {
    +     def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
    +                            "call\t${dst:call}", []>;
    +     def CALL32r     : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
    +                         "call\t{*}$dst", [(X86call GR32:$dst)]>;
    +     def CALL32m     : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
    +                         "call\t{*}$dst", []>;
    +   }
    + 
    +
    + +

    File-scope "let" expressions are often useful when a couple of definitions + need to be added to several records, and the records do not otherwise need to be + opened, as in the case with the CALL* instructions above.

    + +
    + + + + + +
    + +

    TODO: How they work, how to write one. This section should not contain + details about any particular backend, except maybe -print-enums as an example. + This should highlight the APIs in TableGen/Record.h.

    + +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Chris Lattner
    + LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/TestingGuide.html diff -c /dev/null llvm-www/releases/2.5/docs/TestingGuide.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/TestingGuide.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,963 ---- + + + + LLVM Testing Infrastructure Guide + + + + +
    + LLVM Testing Infrastructure Guide +
    + +
      +
    1. Overview
    2. +
    3. Requirements
    4. +
    5. LLVM testing infrastructure organization + +
    6. +
    7. Quick start + +
    8. +
    9. DejaGNU structure + +
    10. +
    11. Test suite structure
    12. +
    13. Running the test suite + +
    14. +
    15. Running the nightly tester
    16. +
    + +
    +

    Written by John T. Criswell, Reid Spencer, and Tanya Lattner

    +
    + + + + + +
    + +

    This document is the reference manual for the LLVM testing infrastructure. It documents + the structure of the LLVM testing infrastructure, the tools needed to use it, + and how to add and run tests.

    + +
    + + + + + +
    + +

    In order to use the LLVM testing infrastructure, you will need all of the software + required to build LLVM, plus the following:

    + +
    +
    DejaGNU
    +
    The Feature and Regressions tests are organized and run by DejaGNU.
    +
    Expect
    +
    Expect is required by DejaGNU.
    +
    tcl
    +
    Tcl is required by DejaGNU.
    + +
      +
    • ./configure --with-f2c=$DIR
      + This will specify a new $DIR for the above-described search + process. This will only work if the binary, header, and library are in their + respective subdirectories of $DIR.
    • + +
    • ./configure --with-f2c-bin=/binary/path --with-f2c-inc=/include/path + --with-f2c-lib=/lib/path
      + This allows you to specify the F2C components separately. Note: if you choose + this route, you MUST specify all three components, and you need to only specify + directories where the files are located; do NOT include the + filenames themselves on the configure line.
    • +
    +
    + +

    Darwin (Mac OS X) developers can simplify the installation of Expect and tcl + by using fink. fink install expect will install both. Alternatively, + Darwinports users can use sudo port install expect to install Expect + and tcl.

    + +
    + + + + + +
    + +

    The LLVM testing infrastructure contains two major categories of tests: code + fragments and whole programs. Code fragments are referred to as the "DejaGNU + tests" and are in the llvm module in subversion under the + llvm/test directory. The whole programs tests are referred to as the + "Test suite" and are in the test-suite module in subversion. +

    + +
    + + + + + +
    + +

    Code fragments are small pieces of code that test a specific feature of LLVM + or trigger a specific bug in LLVM. They are usually written in LLVM assembly + language, but can be written in other languages if the test targets a particular + language front end. These tests are driven by the DejaGNU testing framework, + which is hidden behind a few simple makefiles.

    + +

    These code fragments are not complete programs. The code generated from them is + never executed to determine correct behavior.

    + +

    These code fragment tests are located in the llvm/test + directory.

    + +

    Typically when a bug is found in LLVM, a regression test containing + just enough code to reproduce the problem should be written and placed + somewhere underneath this directory. In most cases, this will be a small + piece of LLVM assembly language code, often distilled from an actual + application or benchmark.

    + +
    + + + + + +
    + +

    The test suite contains whole programs, which are pieces of + code which can be compiled and linked into a stand-alone program that can be + executed. These programs are generally written in high level languages such as + C or C++, but sometimes they are written straight in LLVM assembly.

    + +

    These programs are compiled and then executed using several different + methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation, + etc). The output of these programs is compared to ensure that LLVM is compiling + the program correctly.

    + +

    In addition to compiling and executing programs, whole program tests serve as + a way of benchmarking LLVM performance, both in terms of the efficiency of the + programs generated as well as the speed with which LLVM compiles, optimizes, and + generates code.

    + +

    The test-suite is located in the test-suite Subversion module.

    + +
    + + + + + +
    + +

    The tests are located in two separate Subversion modules. The + DejaGNU tests are in the main "llvm" module under the directory + llvm/test (so you get these tests for free with the main llvm tree). + The more comprehensive test suite that includes whole + programs in C and C++ is in the test-suite module. This module should + be checked out to the llvm/projects directory (don't use another name + then the default "test-suite", for then the test suite will be run every time + you run make in the main llvm directory). + When you configure the llvm module, + the test-suite directory will be automatically configured. + Alternatively, you can configure the test-suite module manually.

    + + + + +

    To run all of the simple tests in LLVM using DejaGNU, use the master Makefile + in the llvm/test directory:

    + +
    +
    + % gmake -C llvm/test
    + 
    +
    + +

    or

    + +
    +
    + % gmake check
    + 
    +
    + +

    To run only a subdirectory of tests in llvm/test using DejaGNU (ie. + Transforms), just set the TESTSUITE variable to the path of the + subdirectory (relative to llvm/test):

    + +
    +
    + % gmake TESTSUITE=Transforms check
    + 
    +
    + +

    Note: If you are running the tests with objdir != subdir, you + must have run the complete testsuite before you can specify a + subdirectory.

    + +

    To run only a single test, set TESTONE to its path (relative to + llvm/test) and make the check-one target:

    + +
    +
    + % gmake TESTONE=Feature/basictest.ll check-one
    + 
    +
    + +

    To run the tests with Valgrind (Memcheck by default), just append + VG=1 to the commands above, e.g.:

    + +
    +
    + % gmake check VG=1
    + 
    +
    + + + + + +

    To run the comprehensive test suite (tests that compile and execute whole + programs), first checkout and setup the test-suite module:

    + +
    +
    + % cd llvm/projects
    + % svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
    + % cd ..
    + % ./configure --with-llvmgccdir=$LLVM_GCC_DIR
    + 
    +

    where $LLVM_GCC_DIR is the directory where you installed + llvm-gcc, not it's src or obj dir.

    +
    + +

    Then, run the entire test suite by running make in the test-suite + directory:

    + +
    +
    + % cd projects/test-suite
    + % gmake
    + 
    +
    + +

    Usually, running the "nightly" set of tests is a good idea, and you can also + let it generate a report by running:

    + +
    +
    + % cd projects/test-suite
    + % gmake TEST=nightly report report.html
    + 
    +
    + +

    Any of the above commands can also be run in a subdirectory of + projects/test-suite to run the specified test only on the programs in + that subdirectory.

    + +
    + + + + +
    +

    The LLVM DejaGNU tests are driven by DejaGNU together with GNU Make and are + located in the llvm/test directory. + +

    This directory contains a large array of small tests + that exercise various features of LLVM and to ensure that regressions do not + occur. The directory is broken into several sub-directories, each focused on + a particular area of LLVM. A few of the important ones are:

    + +
      +
    • Analysis: checks Analysis passes.
    • +
    • Archive: checks the Archive library.
    • +
    • Assembler: checks Assembly reader/writer functionality.
    • +
    • Bitcode: checks Bitcode reader/writer functionality.
    • +
    • CodeGen: checks code generation and each target.
    • +
    • Features: checks various features of the LLVM language.
    • +
    • Linker: tests bitcode linking.
    • +
    • Transforms: tests each of the scalar, IPO, and utility + transforms to ensure they make the right transformations.
    • +
    • Verifier: tests the IR verifier.
    • +
    + +
    + + + + +
    +

    The DejaGNU structure is very simple, but does require some information to + be set. This information is gathered via configure and is written + to a file, site.exp in llvm/test. The llvm/test + Makefile does this work for you.

    + +

    In order for DejaGNU to work, each directory of tests must have a + dg.exp file. DejaGNU looks for this file to determine how to run the + tests. This file is just a Tcl script and it can do anything you want, but + we've standardized it for the LLVM regression tests. If you're adding a + directory of tests, just copy dg.exp from another directory to get + running. The standard dg.exp simply loads a Tcl + library (test/lib/llvm.exp) and calls the llvm_runtests + function defined in that library with a list of file names to run. The names + are obtained by using Tcl's glob command. Any directory that contains only + directories does not need the dg.exp file.

    + +

    The llvm-runtests function lookas at each file that is passed to + it and gathers any lines together that match "RUN:". This are the "RUN" lines + that specify how the test is to be run. So, each test script must contain + RUN lines if it is to do anything. If there are no RUN lines, the + llvm-runtests function will issue an error and the test will + fail.

    + +

    RUN lines are specified in the comments of the test program using the + keyword RUN followed by a colon, and lastly the command (pipeline) + to execute. Together, these lines form the "script" that + llvm-runtests executes to run the test case. The syntax of the + RUN lines is similar to a shell's syntax for pipelines including I/O + redirection and variable substitution. However, even though these lines + may look like a shell script, they are not. RUN lines are interpreted + directly by the Tcl exec command. They are never executed by a + shell. Consequently the syntax differs from normal shell script syntax in a + few ways. You can specify as many RUN lines as needed.

    + +

    Each RUN line is executed on its own, distinct from other lines unless + its last character is \. This continuation character causes the RUN + line to be concatenated with the next one. In this way you can build up long + pipelines of commands without making huge line lengths. The lines ending in + \ are concatenated until a RUN line that doesn't end in \ is + found. This concatenated set of RUN lines then constitutes one execution. + Tcl will substitute variables and arrange for the pipeline to be executed. If + any process in the pipeline fails, the entire line (and test case) fails too. +

    + +

    Below is an example of legal RUN lines in a .ll file:

    + +
    +
    + ; RUN: llvm-as < %s | llvm-dis > %t1
    + ; RUN: llvm-dis < %s.bc-13 > %t2
    + ; RUN: diff %t1 %t2
    + 
    +
    + +

    As with a Unix shell, the RUN: lines permit pipelines and I/O redirection + to be used. However, the usage is slightly different than for Bash. To check + what's legal, see the documentation for the + Tcl exec + command and the + tutorial. + The major differences are:

    +
      +
    • You can't do 2>&1. That will cause Tcl to write to a + file named &1. Usually this is done to get stderr to go through + a pipe. You can do that in tcl with |& so replace this idiom: + ... 2>&1 | grep with ... |& grep
    • +
    • You can only redirect to a file, not to another descriptor and not from + a here document.
    • +
    • tcl supports redirecting to open files with the @ syntax but you + shouldn't use that here.
    • +
    + +

    There are some quoting rules that you must pay attention to when writing + your RUN lines. In general nothing needs to be quoted. Tcl won't strip off any + ' or " so they will get passed to the invoked program. For example:

    + +
    +
    + ... | grep 'find this string'
    + 
    +
    + +

    This will fail because the ' characters are passed to grep. This would + instruction grep to look for 'find in the files this and + string'. To avoid this use curly braces to tell Tcl that it should + treat everything enclosed as one value. So our example would become:

    + +
    +
    + ... | grep {find this string}
    + 
    +
    + +

    Additionally, the characters [ and ] are treated + specially by Tcl. They tell Tcl to interpret the content as a command to + execute. Since these characters are often used in regular expressions this can + have disastrous results and cause the entire test run in a directory to fail. + For example, a common idiom is to look for some basicblock number:

    + +
    +
    + ... | grep bb[2-8]
    + 
    +
    + +

    This, however, will cause Tcl to fail because its going to try to execute + a program named "2-8". Instead, what you want is this:

    + +
    +
    + ... | grep {bb\[2-8\]}
    + 
    +
    + +

    Finally, if you need to pass the \ character down to a program, + then it must be doubled. This is another Tcl special character. So, suppose + you had: + +

    +
    + ... | grep 'i32\*'
    + 
    +
    + +

    This will fail to match what you want (a pointer to i32). First, the + ' do not get stripped off. Second, the \ gets stripped off + by Tcl so what grep sees is: 'i32*'. That's not likely to match + anything. To resolve this you must use \\ and the {}, like + this:

    + +
    +
    + ... | grep {i32\\*}
    + 
    +
    + +
    + + + + +
    +

    With a RUN line there are a number of substitutions that are permitted. In + general, any Tcl variable that is available in the substitute + function (in test/lib/llvm.exp) can be substituted into a RUN line. + To make a substitution just write the variable's name preceded by a $. + Additionally, for compatibility reasons with previous versions of the test + library, certain names can be accessed with an alternate syntax: a % prefix. + These alternates are deprecated and may go away in a future version. +

    +

    Here are the available variable names. The alternate syntax is listed in + parentheses.

    + +
    +
    $test (%s)
    +
    The full path to the test case's source. This is suitable for passing + on the command line as the input to an llvm tool.
    + +
    $srcdir
    +
    The source directory from where the "make check" was run.
    + +
    objdir
    +
    The object directory that corresponds to the $srcdir.
    + +
    subdir
    +
    A partial path from the test directory that contains the + sub-directory that contains the test source being executed.
    + +
    srcroot
    +
    The root directory of the LLVM src tree.
    + +
    objroot
    +
    The root directory of the LLVM object tree. This could be the same + as the srcroot.
    + +
    path
    +
    The path to the directory that contains the test case source. This is + for locating any supporting files that are not generated by the test, but + used by the test.
    + +
    tmp
    +
    The path to a temporary file name that could be used for this test case. + The file name won't conflict with other test cases. You can append to it if + you need multiple temporaries. This is useful as the destination of some + redirected output.
    + +
    llvmlibsdir (%llvmlibsdir)
    +
    The directory where the LLVM libraries are located.
    + +
    target_triplet (%target_triplet)
    +
    The target triplet that corresponds to the current host machine (the one + running the test cases). This should probably be called "host".
    + +
    prcontext (%prcontext)
    +
    Path to the prcontext tcl script that prints some context around a + line that matches a pattern. This isn't strictly necessary as the test suite + is run with its PATH altered to include the test/Scripts directory where + the prcontext script is located. Note that this script is similar to + grep -C but you should use the prcontext script because + not all platforms support grep -C.
    + +
    llvmgcc (%llvmgcc)
    +
    The full path to the llvm-gcc executable as specified in the + configured LLVM environment
    + +
    llvmgxx (%llvmgxx)
    +
    The full path to the llvm-gxx executable as specified in the + configured LLVM environment
    + +
    llvmgcc_version (%llvmgcc_version)
    +
    The full version number of the llvm-gcc executable.
    + +
    llvmgccmajvers (%llvmgccmajvers)
    +
    The major version number of the llvm-gcc executable.
    + +
    gccpath
    +
    The full path to the C compiler used to build LLVM. Note that + this might not be gcc.
    + +
    gxxpath
    +
    The full path to the C++ compiler used to build LLVM. Note that + this might not be g++.
    + +
    compile_c (%compile_c)
    +
    The full command line used to compile LLVM C source code. This has all + the configured -I, -D and optimization options.
    + +
    compile_cxx (%compile_cxx)
    +
    The full command used to compile LLVM C++ source code. This has + all the configured -I, -D and optimization options.
    + +
    link (%link)
    +
    This full link command used to link LLVM executables. This has all the + configured -I, -L and -l options.
    + +
    shlibext (%shlibext)
    +
    The suffix for the host platforms share library (dll) files. This + includes the period as the first character.
    +
    +

    To add more variables, two things need to be changed. First, add a line in + the test/Makefile that creates the site.exp file. This will + "set" the variable as a global in the site.exp file. Second, in the + test/lib/llvm.exp file, in the substitute proc, add the variable name + to the list of "global" declarations at the beginning of the proc. That's it, + the variable can then be used in test scripts.

    +
    + + + + +
    +

    To make RUN line writing easier, there are several shell scripts located + in the llvm/test/Scripts directory. This directory is in the PATH + when running tests, so you can just call these scripts using their name. For + example:

    +
    +
    ignore
    +
    This script runs its arguments and then always returns 0. This is useful + in cases where the test needs to cause a tool to generate an error (e.g. to + check the error output). However, any program in a pipeline that returns a + non-zero result will cause the test to fail. This script overcomes that + issue and nicely documents that the test case is purposefully ignoring the + result code of the tool
    + +
    not
    +
    This script runs its arguments and then inverts the result code from + it. Zero result codes become 1. Non-zero result codes become 0. This is + useful to invert the result of a grep. For example "not grep X" means + succeed only if you don't find X in the input.
    +
    + +

    Sometimes it is necessary to mark a test case as "expected fail" or XFAIL. + You can easily mark a test as XFAIL just by including XFAIL: on a + line near the top of the file. This signals that the test case should succeed + if the test fails. Such test cases are counted separately by DejaGnu. To + specify an expected fail, use the XFAIL keyword in the comments of the test + program followed by a colon and one or more regular expressions (separated by + a comma). The regular expressions allow you to XFAIL the test conditionally + by host platform. The regular expressions following the : are matched against + the target triplet or llvmgcc version number for the host machine. If there is + a match, the test is expected to fail. If not, the test is expected to + succeed. To XFAIL everywhere just specify XFAIL: *. When matching + the llvm-gcc version, you can specify the major (e.g. 3) or full version + (i.e. 3.4) number. Here is an example of an XFAIL line:

    + +
    +
    + ; XFAIL: darwin,sun,llvmgcc4
    + 
    +
    + +

    To make the output more useful, the llvm_runtest function wil + scan the lines of the test case for ones that contain a pattern that matches + PR[0-9]+. This is the syntax for specifying a PR (Problem Report) number that + is related to the test case. The number after "PR" specifies the LLVM bugzilla + number. When a PR number is specified, it will be used in the pass/fail + reporting. This is useful to quickly get some context when a test fails.

    + +

    Finally, any line that contains "END." will cause the special + interpretation of lines to terminate. This is generally done right after the + last RUN: line. This has two side effects: (a) it prevents special + interpretation of lines that are part of the test program, not the + instructions to the test case, and (b) it speeds things up for really big test + cases by avoiding interpretation of the remainder of the file.

    + +
    + + + + + +
    + +

    The test-suite module contains a number of programs that can be compiled + with LLVM and executed. These programs are compiled using the native compiler + and various LLVM backends. The output from the program compiled with the + native compiler is assumed correct; the results from the other programs are + compared to the native program output and pass if they match.

    + +

    When executing tests, it is usually a good idea to start out with a subset of + the available tests or programs. This makes test run times smaller at first and + later on this is useful to investigate individual test failures. To run some + test only on a subset of programs, simply change directory to the programs you + want tested and run gmake there. Alternatively, you can run a different + test using the TEST variable to change what tests or run on the + selected programs (see below for more info).

    + +

    In addition for testing correctness, the llvm-test directory also + performs timing tests of various LLVM optimizations. It also records + compilation times for the compilers and the JIT. This information can be + used to compare the effectiveness of LLVM's optimizations and code + generation.

    + +

    llvm-test tests are divided into three types of tests: MultiSource, + SingleSource, and External.

    + +
      +
    • llvm-test/SingleSource +

      The SingleSource directory contains test programs that are only a single + source file in size. These are usually small benchmark programs or small + programs that calculate a particular value. Several such programs are grouped + together in each directory.

    • + +
    • llvm-test/MultiSource +

      The MultiSource directory contains subdirectories which contain entire + programs with multiple source files. Large benchmarks and whole applications + go here.

    • + +
    • llvm-test/External +

      The External directory contains Makefiles for building code that is external + to (i.e., not distributed with) LLVM. The most prominent members of this + directory are the SPEC 95 and SPEC 2000 benchmark suites. The External + directory does not contain these actual tests,but only the Makefiles that know + how to properly compile these programs from somewhere else. The presence and + location of these external programs is configured by the llvm-test + configure script.

    • +
    + +

    Each tree is then subdivided into several categories, including applications, + benchmarks, regression tests, code that is strange grammatically, etc. These + organizations should be relatively self explanatory.

    + +

    Some tests are known to fail. Some are bugs that we have not fixed yet; + others are features that we haven't added yet (or may never add). In DejaGNU, + the result for such tests will be XFAIL (eXpected FAILure). In this way, you + can tell the difference between an expected and unexpected failure.

    + +

    The tests in the test suite have no such feature at this time. If the + test passes, only warnings and other miscellaneous output will be generated. If + a test fails, a large <program> FAILED message will be displayed. This + will help you separate benign warnings from actual test failures.

    + +
    + + + + + +
    + +

    First, all tests are executed within the LLVM object directory tree. They + are not executed inside of the LLVM source tree. This is because the + test suite creates temporary files during execution.

    + +

    To run the test suite, you need to use the following steps:

    + +
      +
    1. cd into the llvm/projects directory
    2. + +
    3. Check out the test-suite module with:

      + +
      +
      + % svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
      + 
      +
      + +

      This will get the test suite into llvm/projects/llvm-test

      + +
    4. Configure the test suite using llvm configure. This will automatically + configure test-suite. You must do it from the top level otherwise llvm-gcc + will not be set which is required to run llvm-test:

      +
      +
      + % cd $LLVM_OBJ_ROOT ; $LLVM_SRC_ROOT/configure --with-llvmgccdir=$LLVM_GCC_DIR
      + 
      +
      +

      Note that that $LLVM_GCC_DIR is the directory where you + installed llvm-gcc, not its src or obj directory.

      +
    5. + +
    6. Change back to the llvm/projects/test-suite directory you created before + and run gmake (or just "make" on systems where GNU make is + the default, such as linux.

    7. +
    +

    Note that the second and third steps only need to be done once. After you + have the suite checked out and configured, you don't need to do it again (unless + the test code or configure script changes).

    + + + + + +
    +

    Note, when configuring the test-suite module, you might want to + specify the following configuration option:

    +
    +
    --with-externals
    +
    --with-externals=<directory>
    +
    + This tells LLVM where to find any external tests. They are expected to be + in specifically named subdirectories of <directory>. + If directory is left unspecified, + configure uses the default value + /home/vadve/shared/benchmarks/speccpu2000/benchspec. + Subdirectory names known to LLVM include: +
    +
    spec95
    +
    speccpu2000
    +
    speccpu2006
    +
    povray31
    +
    + Others are added from time to time, and can be determined from + configure. +
    + + + + +
    +

    In addition to the regular "whole program" tests, the test-suite + module also provides a mechanism for compiling the programs in different ways. + If the variable TEST is defined on the gmake command line, the test system will + include a Makefile named TEST.<value of TEST variable>.Makefile. + This Makefile can modify build rules to yield different results.

    + +

    For example, the LLVM nightly tester uses TEST.nightly.Makefile to + create the nightly test reports. To run the nightly tests, run gmake + TEST=nightly.

    + +

    There are several TEST Makefiles available in the tree. Some of them are + designed for internal LLVM research and will not work outside of the LLVM + research group. They may still be valuable, however, as a guide to writing your + own TEST Makefile for any optimization or analysis passes that you develop with + LLVM.

    + +
    + + + + +
    +

    There are a number of ways to run the tests and generate output. The most + simple one is simply running gmake with no arguments. This will + compile and run all programs in the tree using a number of different methods + and compare results. Any failures are reported in the output, but are likely + drowned in the other output. Passes are not reported explicitely.

    + +

    Somewhat better is running gmake TEST=sometest test, which runs + the specified test and usually adds per-program summaries to the output + (depending on which sometest you use). For example, the nightly test + explicitely outputs TEST-PASS or TEST-FAIL for every test after each program. + Though these lines are still drowned in the output, it's easy to grep the + output logs in the Output directories.

    + +

    Even better are the report and report.format targets + (where format is one of html, csv, text or + graphs). The exact contents of the report are dependent on which + TEST you are running, but the text results are always shown at the + end of the run and the results are always stored in the + report.<type>.format file (when running with + TEST=<type>). + + The report also generate a file called + report.<type>.raw.out containing the output of the entire test + run. +

    + + + + + +
    + +

    Assuming you can run the test suite, (e.g. "gmake TEST=nightly report" + should work), it is really easy to run optimizations or code generator + components against every program in the tree, collecting statistics or running + custom checks for correctness. At base, this is how the nightly tester works, + it's just one example of a general framework.

    + +

    Lets say that you have an LLVM optimization pass, and you want to see how + many times it triggers. First thing you should do is add an LLVM + statistic to your pass, which + will tally counts of things you care about.

    + +

    Following this, you can set up a test and a report that collects these and + formats them for easy viewing. This consists of two files, an + "test-suite/TEST.XXX.Makefile" fragment (where XXX is the name of your + test) and an "llvm-test/TEST.XXX.report" file that indicates how to + format the output into a table. There are many example reports of various + levels of sophistication included with the test suite, and the framework is very + general.

    + +

    If you are interested in testing an optimization pass, check out the + "libcalls" test as an example. It can be run like this:

    + +

    +
    + % cd llvm/projects/test-suite/MultiSource/Benchmarks  # or some other level
    + % make TEST=libcalls report
    + 
    +
    + +

    This will do a bunch of stuff, then eventually print a table like this:

    + +
    +
    + Name                                  | total | #exit |
    + ...
    + FreeBench/analyzer/analyzer           | 51    | 6     | 
    + FreeBench/fourinarow/fourinarow       | 1     | 1     | 
    + FreeBench/neural/neural               | 19    | 9     | 
    + FreeBench/pifft/pifft                 | 5     | 3     | 
    + MallocBench/cfrac/cfrac               | 1     | *     | 
    + MallocBench/espresso/espresso         | 52    | 12    | 
    + MallocBench/gs/gs                     | 4     | *     | 
    + Prolangs-C/TimberWolfMC/timberwolfmc  | 302   | *     | 
    + Prolangs-C/agrep/agrep                | 33    | 12    | 
    + Prolangs-C/allroots/allroots          | *     | *     | 
    + Prolangs-C/assembler/assembler        | 47    | *     | 
    + Prolangs-C/bison/mybison              | 74    | *     | 
    + ...
    + 
    +
    + +

    This basically is grepping the -stats output and displaying it in a table. + You can also use the "TEST=libcalls report.html" target to get the table in HTML + form, similarly for report.csv and report.tex.

    + +

    The source for this is in test-suite/TEST.libcalls.*. The format is pretty + simple: the Makefile indicates how to run the test (in this case, + "opt -simplify-libcalls -stats"), and the report contains one line for + each column of the output. The first value is the header for the column and the + second is the regex to grep the output of the command for. There are lots of + example reports that can do fancy stuff.

    + +
    + + + + + + +
    + +

    + The LLVM Nightly Testers + automatically check out an LLVM tree, build it, run the "nightly" + program test (described above), run all of the DejaGNU tests, + delete the checked out tree, and then submit the results to + http://llvm.org/nightlytest/. + After test results are submitted to + http://llvm.org/nightlytest/, + they are processed and displayed on the tests page. An email to + + llvm-testresults at cs.uiuc.edu summarizing the results is also generated. + This testing scheme is designed to ensure that programs don't break as well + as keep track of LLVM's progress over time.

    + +

    If you'd like to set up an instance of the nightly tester to run on your + machine, take a look at the comments at the top of the + utils/NewNightlyTest.pl file. If you decide to set up a nightly tester + please choose a unique nickname and invoke utils/NewNightlyTest.pl + with the "-nickname [yournickname]" command line option. + +

    You can create a shell script to encapsulate the running of the script. + The optimized x86 Linux nightly test is run from just such a script:

    + +
    +
    + #!/bin/bash
    + BASE=/proj/work/llvm/nightlytest
    + export BUILDDIR=$BASE/build 
    + export WEBDIR=$BASE/testresults 
    + export LLVMGCCDIR=/proj/work/llvm/cfrontend/install
    + export PATH=/proj/install/bin:$LLVMGCCDIR/bin:$PATH
    + export LD_LIBRARY_PATH=/proj/install/lib
    + cd $BASE
    + cp /proj/work/llvm/llvm/utils/NewNightlyTest.pl .
    + nice ./NewNightlyTest.pl -nice -release -verbose -parallel -enable-linscan \
    +    -nickname NightlyTester -noexternals > output.log 2>&1 
    + 
    +
    + +

    It is also possible to specify the the location your nightly test results + are submitted. You can do this by passing the command line option + "-submit-server [server_address]" and "-submit-script [script_on_server]" to + utils/NewNightlyTest.pl. For example, to submit to the llvm.org + nightly test results page, you would invoke the nightly test script with + "-submit-server llvm.org -submit-script /nightlytest/NightlyTestAccept.cgi". + If these options are not specified, the nightly test script sends the results + to the llvm.org nightly test results page.

    + +

    Take a look at the NewNightlyTest.pl file to see what all of the + flags and strings do. If you start running the nightly tests, please let us + know. Thanks!

    + +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + John T. Criswell, Reid Spencer, and Tanya Lattner
    + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + Index: llvm-www/releases/2.5/docs/UsingLibraries.html diff -c /dev/null llvm-www/releases/2.5/docs/UsingLibraries.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/UsingLibraries.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,449 ---- + + + + Using The LLVM Libraries + + + +
    Using The LLVM Libraries
    +
      +
    1. Abstract
    2. +
    3. Introduction
    4. +
    5. Library Descriptions
    6. +
    7. Library Dependencies
    8. +
    9. Linkage Rules Of Thumb +
        +
      1. Always link LLVMCore, LLVMSupport, LLVMSystem +
      2. Never link both archive and re-linked +
      +
    10. +
    + +
    +

    Written by Reid Spencer

    +
    + +

    Warning: This document is out of date, please see llvm-config for more information.

    + + + +
    +

    Amongst other things, LLVM is a toolkit for building compilers, linkers, + runtime executives, virtual machines, and other program execution related + tools. In addition to the LLVM tool set, the functionality of LLVM is + available through a set of libraries. To use LLVM as a toolkit for + constructing tools, a developer needs to understand what is contained in the + various libraries, what they depend on, and how to use them. Fortunately, + there is a tool, llvm-config to aid with this. This document + describes the contents of the libraries and how to use llvm-config + to generate command line options. +

    +
    + + + +
    +

    If you're writing a compiler, virtual machine, or any other utility based + on LLVM, you'll need to figure out which of the many libraries files you will + need to link with to be successful. An understanding of the contents of these + libraries will be useful in coming up with an optimal specification for the + libraries to link with. The purpose of this document is to reduce some of + the trial and error that the author experienced in using LLVM.

    +

    LLVM produces two types of libraries: archives (ending in .a) and + objects (ending in .o). However, both are libraries. Libraries ending + in .o are known as re-linked libraries because they contain all the + compilation units of the library linked together as a single .o file. + Furthermore, several of the libraries have both forms of library. The + re-linked libraries are used whenever you want to include all symbols from the + library. The archive libraries are used whenever you want to only resolve + outstanding symbols at that point in the link without including everything in + the library.

    +

    If you're using the LLVM Makefile system to link your tools,you will use + the LLVMLIBS make variable. + (see the Makefile Guide for + details). This variable specifies which LLVM libraries to link into your tool + and the order in which they will be linked. You specify re-linked libraries by + naming the library without a suffix. You specify archive libraries by naming + the library with a .a suffix but without the lib prefix. The + order in which the libraries appear in the LLVMLIBS variable + definition is the order in which they will be linked. Getting this order + correct for your tool can sometimes be challenging. +

    + +
    Library Descriptions
    +
    +

    The table below categorizes each library + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    LibraryFormsDescription
    Core Libraries
    LLVMArchive.aLLVM archive reading and writing
    LLVMAsmParser.aLLVM assembly parsing
    LLVMBCReader.aLLVM bitcode reading
    LLVMBCWriter.aLLVM bitcode writing
    LLVMCore.aLLVM core intermediate representation
    LLVMDebugger.aSource level debugging support
    LLVMLinker.aBitcode and archive linking interface
    LLVMSupport.aGeneral support utilities
    LLVMSystem.aOperating system abstraction layer
    LLVMbzip2.aBZip2 compression library
    Analysis Libraries
    LLVMAnalysis.aVarious analysis passes.
    LLVMDataStructure.oData structure analysis passes.
    LLVMipa.aInter-procedural analysis passes.
    Transformation Libraries
    LLVMInstrumentation.aInstrumentation passes.
    LLVMipo.aAll inter-procedural optimization passes.
    LLVMScalarOpts.aAll scalar optimization passes.
    LLVMTransformUtils.aTransformation utilities used by many passes.
    Code Generation Libraries
    LLVMCodeGen.oNative code generation infrastructure
    LLVMSelectionDAG.oAggressive instruction selector for directed acyclic graphs
    Target Libraries
    LLVMAlpha.oCode generation for Alpha architecture
    LLVMARM.oCode generation for ARM architecture
    LLVMCBackend.o'C' language code generator.
    LLVMIA64.oCode generation for IA64 architecture
    LLVMPowerPC.oCode generation for PowerPC architecture
    LLVMSparc.oCode generation for Sparc architecture
    LLVMTarget.aGeneric code generation utilities.
    LLVMX86.oCode generation for Intel x86 architecture
    Runtime Libraries
    LLVMInterpreter.oBitcode Interpreter
    LLVMJIT.oBitcode JIT Compiler
    LLVMExecutionEngine.oVirtual machine engine
    +

    + + +
    Using llvm-config
    +
    +

    The llvm-config tool is a perl script that produces on its output + various kinds of information. For example, the source or object directories + used to build LLVM can be accessed by passing options to llvm-config. + For complete details on this tool, please see the + manual page.

    +

    To understand the relationships between libraries, the llvm-config + can be very useful. If all you know is that you want certain libraries to + be available, you can generate the complete set of libraries to link with + using one of four options, as below:

    +
      +
    1. --ldflags. This generates the command line options necessary to + be passed to the ld tool in order to link with LLVM. Most notably, + the -L option is provided to specify a library search directory + that contains the LLVM libraries.
    2. +
    3. --libs. This generates command line options suitable for + use with a gcc-style linker. That is, libraries are given with a -l option + and object files are given with a full path.
    4. +
    5. --libnames. This generates a list of just the library file + names. If you know the directory in which these files reside (see --ldflags) + then you can find the libraries there.
    6. +
    7. --libfiles. This generates the full path names of the + LLVM library files.
    8. +
    +

    If you wish to delve further into how llvm-config generates the + correct order (based on library dependencies), please see the tool named + GenLibDeps.pl in the utils source directory of LLVM.

    + + + + + + + +

    Dependency Relationships Of Libraries

    +

    This graph shows the dependency of archive libraries on other archive + libraries or objects. Where a library has both archive and object forms, only + the archive form is shown.

    + Library Dependencies +

    Dependency Relationships Of Object Files

    +

    This graph shows the dependency of object files on archive libraries or + other objects. Where a library has both object and archive forms, only the + dependency to the archive form is shown.

    + Object File Dependencies +

    The following list shows the dependency relationships between libraries in + textual form. The information is the same as shown on the graphs but arranged + alphabetically.

    +
    +
    libLLVMAnalysis.a
      +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    libLLVMArchive.a
      +
    • libLLVMBCReader.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMAsmParser.a
      +
    • libLLVMCore.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMBCReader.a
      +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMBCWriter.a
      +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMCodeGen.a
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMScalarOpts.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    • libLLVMTransformUtils.a
    • +
    +
    libLLVMCore.a
      +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMDebugger.a
      +
    • libLLVMBCReader.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMInstrumentation.a
      +
    • libLLVMCore.a
    • +
    • libLLVMScalarOpts.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMTransformUtils.a
    • +
    +
    libLLVMLinker.a
      +
    • libLLVMArchive.a
    • +
    • libLLVMBCReader.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMScalarOpts.a
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    • libLLVMTransformUtils.a
    • +
    +
    libLLVMSelectionDAG.a
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    • libLLVMTransformUtils.a
    • +
    +
    libLLVMSupport.a
      +
    • libLLVMSystem.a
    • +
    • libLLVMbzip2.a
    • +
    +
    libLLVMSystem.a
      +
    +
    libLLVMTarget.a
      +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMTransformUtils.a
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    • libLLVMipa.a
    • +
    +
    libLLVMbzip2.a
      +
    +
    libLLVMipa.a
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    +
    libLLVMipo.a
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    • libLLVMTransformUtils.a
    • +
    • libLLVMipa.a
    • +
    +
    libLLVMlto.a
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMBCReader.a
    • +
    • libLLVMBCWriter.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMLinker.a
    • +
    • libLLVMScalarOpts.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    • libLLVMipa.a
    • +
    • libLLVMipo.a
    • +
    +
    LLVMARM.o
      +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSelectionDAG.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMAlpha.o
      +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSelectionDAG.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMCBackend.o
      +
    • libLLVMAnalysis.a
    • +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMScalarOpts.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    • libLLVMTransformUtils.a
    • +
    • libLLVMipa.a
    • +
    +
    LLVMExecutionEngine.o
      +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMIA64.o
      +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSelectionDAG.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMInterpreter.o
      +
    • LLVMExecutionEngine.o
    • +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMJIT.o
      +
    • LLVMExecutionEngine.o
    • +
    • libLLVMCore.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMPowerPC.o
      +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSelectionDAG.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMSparc.o
      +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSelectionDAG.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    LLVMX86.o
      +
    • libLLVMCodeGen.a
    • +
    • libLLVMCore.a
    • +
    • libLLVMSelectionDAG.a
    • +
    • libLLVMSupport.a
    • +
    • libLLVMSystem.a
    • +
    • libLLVMTarget.a
    • +
    +
    +
    + + + +
    +

    This section contains various "rules of thumb" about what files you + should link into your programs.

    +
    + + +
    +

    No matter what you do with LLVM, the last three entries in the value of + your LLVMLIBS make variable should always be: + LLVMCore LLVMSupport.a LLVMSystem.a. There are no LLVM + programs that don't depend on these three.

    +
    + + +
    +

    There is never any point to linking both the re-linked (.o) and + the archive (.a) versions of a library. Since the re-linked version + includes the entire library, the archive version will not resolve any symbols. + You could even end up with link error if you place the archive version before + the re-linked version on the linker's command line.

    +
    + +
    + + + + Index: llvm-www/releases/2.5/docs/WritingAnLLVMBackend.html diff -c /dev/null llvm-www/releases/2.5/docs/WritingAnLLVMBackend.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/WritingAnLLVMBackend.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,2162 ---- + + + + Writing an LLVM Compiler Backend + + + + + +
    + Writing an LLVM Compiler Backend +
    + +
      +
    1. Introduction + +
    2. Target Machine
    3. +
    4. Register Set and Register Classes +
    5. +
    6. Instruction Set +
    7. +
    8. Instruction Selector +
    9. +
    10. Assembly Printer
    11. +
    12. Subtarget Support
    13. +
    14. JIT Support +
    15. +
    + +
    +

    Written by Mason Woo and Misha Brukman

    +
    + + + + + +
    +

    This document describes techniques for writing compiler backends + that convert the LLVM IR (intermediate representation) to code for a specified + machine or other languages. Code intended for a specific machine can take the + form of either assembly code or binary code (usable for a JIT compiler).

    + +

    The backend of LLVM features a target-independent code generator + that may create output for several types of target CPUs, including X86, + PowerPC, Alpha, and SPARC. The backend may also be used to generate code + targeted at SPUs of the Cell processor or GPUs to support the execution of + compute kernels.

    + +

    The document focuses on existing examples found in subdirectories + of llvm/lib/Target in a downloaded LLVM release. In particular, this document + focuses on the example of creating a static compiler (one that emits text + assembly) for a SPARC target, because SPARC has fairly standard + characteristics, such as a RISC instruction set and straightforward calling + conventions.

    +
    + +
    + Audience +
    + +
    +

    The audience for this document is anyone who needs to write an + LLVM backend to generate code for a specific hardware or software target.

    +
    + + + +
    + These essential documents must be read before reading this document: +
      +
    • + LLVM Language Reference Manual - + a reference manual for the LLVM assembly language +
    • +
    • + The LLVM Target-Independent Code Generator - + a guide to the components (classes and code generation algorithms) for translating + the LLVM internal representation to the machine code for a specified target. + Pay particular attention to the descriptions of code generation stages: + Instruction Selection, Scheduling and Formation, SSA-based Optimization, + Register Allocation, Prolog/Epilog Code Insertion, Late Machine Code Optimizations, + and Code Emission. +
    • +
    • + TableGen Fundamentals - + a document that describes the TableGen (tblgen) application that manages domain-specific + information to support LLVM code generation. TableGen processes input from a + target description file (.td suffix) and generates C++ code that can be used + for code generation. +
    • +
    • + Writing an LLVM Pass - + The assembly printer is a FunctionPass, as are several SelectionDAG processing steps. +
    • +
    + To follow the SPARC examples in this document, have a copy of + The SPARC Architecture Manual, Version 8 + for reference. For details about the ARM instruction set, refer to the + ARM Architecture Reference Manual + For more about the GNU Assembler format (GAS), see + Using As + especially for the assembly printer. Using As contains lists of target machine dependent features. +
    + + +
    +

    To write a compiler + backend for LLVM that converts the LLVM IR (intermediate representation) + to code for a specified target (machine or other language), follow these steps:

    + +
      +
    • + Create a subclass of the TargetMachine class that describes + characteristics of your target machine. Copy existing examples of specific + TargetMachine class and header files; for example, start with SparcTargetMachine.cpp + and SparcTargetMachine.h, but change the file names for your target. Similarly, + change code that references "Sparc" to reference your target.
    • + +
    • Describe the register set of the target. Use TableGen to generate + code for register definition, register aliases, and register classes from a + target-specific RegisterInfo.td input file. You should also write additional + code for a subclass of TargetRegisterInfo class that represents the class + register file data used for register allocation and also describes the + interactions between registers.
    • + +
    • Describe the instruction set of the target. Use TableGen to + generate code for target-specific instructions from target-specific versions of + TargetInstrFormats.td and TargetInstrInfo.td. You should write additional code + for a subclass of the TargetInstrInfo + class to represent machine + instructions supported by the target machine.
    • + +
    • Describe the selection and conversion of the LLVM IR from a DAG (directed + acyclic graph) representation of instructions to native target-specific + instructions. Use TableGen to generate code that matches patterns and selects + instructions based on additional information in a target-specific version of + TargetInstrInfo.td. Write code for XXXISelDAGToDAG.cpp + (where XXX identifies the specific target) to perform pattern + matching and DAG-to-DAG instruction selection. Also write code in XXXISelLowering.cpp + to replace or remove operations and data types that are not supported natively + in a SelectionDAG.
    • + +
    • Write code for an + assembly printer that converts LLVM IR to a GAS format for your target machine. + You should add assembly strings to the instructions defined in your + target-specific version of TargetInstrInfo.td. You should also write code for a + subclass of AsmPrinter that performs the LLVM-to-assembly conversion and a + trivial subclass of TargetAsmInfo.
    • + +
    • Optionally, add support for subtargets (that is, variants with + different capabilities). You should also write code for a subclass of the + TargetSubtarget class, which allows you to use the -mcpu= + and -mattr= command-line options.
    • + +
    • Optionally, add JIT support and create a machine code emitter (subclass + of TargetJITInfo) that is used to emit binary code directly into memory.
    • +
    + +

    In the .cpp and .h files, initially stub up these methods and + then implement them later. Initially, you may not know which private members + that the class will need and which components will need to be subclassed.

    +
    + + +
    +

    To actually create + your compiler backend, you need to create and modify a few files. The absolute + minimum is discussed here, but to actually use the LLVM target-independent code + generator, you must perform the steps described in the LLVM + Target-Independent Code Generator document.

    + +

    First, you should + create a subdirectory under lib/Target to hold all the files related to your + target. If your target is called "Dummy", create the directory + lib/Target/Dummy.

    + +

    In this new + directory, create a Makefile. It is easiest to copy a Makefile of another + target and modify it. It should at least contain the LEVEL, LIBRARYNAME and + TARGET variables, and then include $(LEVEL)/Makefile.common. The library can be + named LLVMDummy (for example, see the MIPS target). Alternatively, you can + split the library into LLVMDummyCodeGen and LLVMDummyAsmPrinter, the latter of + which should be implemented in a subdirectory below lib/Target/Dummy (for + example, see the PowerPC target).

    + +

    Note that these two + naming schemes are hardcoded into llvm-config. Using any other naming scheme + will confuse llvm-config and produce lots of (seemingly unrelated) linker + errors when linking llc.

    + +

    To make your target + actually do something, you need to implement a subclass of TargetMachine. This + implementation should typically be in the file + lib/Target/DummyTargetMachine.cpp, but any file in the lib/Target directory will + be built and should work. To use LLVM's target + independent code generator, you should do what all current machine backends do: create a subclass + of LLVMTargetMachine. (To create a target from scratch, create a subclass of + TargetMachine.)

    + +

    To get LLVM to + actually build and link your target, you need to add it to the TARGETS_TO_BUILD + variable. To do this, you modify the configure script to know about your target + when parsing the --enable-targets option. Search the configure script for TARGETS_TO_BUILD, + add your target to the lists there (some creativity required) and then + reconfigure. Alternatively, you can change autotools/configure.ac and + regenerate configure by running ./autoconf/AutoRegen.sh

    +
    + + + + +
    +

    LLVMTargetMachine is designed as a base class for targets + implemented with the LLVM target-independent code generator. The + LLVMTargetMachine class should be specialized by a concrete target class that + implements the various virtual methods. LLVMTargetMachine is defined as a + subclass of TargetMachine in include/llvm/Target/TargetMachine.h. The + TargetMachine class implementation (TargetMachine.cpp) also processes numerous + command-line options.

    + +

    To create a concrete target-specific subclass of + LLVMTargetMachine, start by copying an existing TargetMachine class and header. + You should name the files that you create to reflect your specific target. For + instance, for the SPARC target, name the files SparcTargetMachine.h and + SparcTargetMachine.cpp

    + +

    For a target machine XXX, the implementation of XXXTargetMachine + must have access methods to obtain objects that represent target components. + These methods are named get*Info and are intended to obtain the instruction set + (getInstrInfo), register set (getRegisterInfo), stack frame layout + (getFrameInfo), and similar information. XXXTargetMachine must also implement + the getTargetData method to access an object with target-specific data + characteristics, such as data type size and alignment requirements.

    + +

    For instance, for the SPARC target, the header file SparcTargetMachine.h + declares prototypes for several get*Info and getTargetData methods that simply + return a class member.

    +
    + +
    +
    namespace llvm {
    + 
    + class Module;
    + 
    + class SparcTargetMachine : public LLVMTargetMachine {
    +   const TargetData DataLayout;       // Calculates type size & alignment
    +   SparcSubtarget Subtarget;
    +   SparcInstrInfo InstrInfo;
    +   TargetFrameInfo FrameInfo;
    +   
    + protected:
    +   virtual const TargetAsmInfo *createTargetAsmInfo()
    + const;
    +   
    + public:
    +   SparcTargetMachine(const Module &M, const std::string &FS);
    + 
    +   virtual const SparcInstrInfo *getInstrInfo() const {return &InstrInfo; }
    +   virtual const TargetFrameInfo *getFrameInfo() const {return &FrameInfo; }
    +   virtual const TargetSubtarget *getSubtargetImpl() const{return &Subtarget; }
    +   virtual const TargetRegisterInfo *getRegisterInfo() const {
    +     return &InstrInfo.getRegisterInfo();
    +   }
    +   virtual const TargetData *getTargetData() const { return &DataLayout; }
    +   static unsigned getModuleMatchQuality(const Module &M);
    + 
    +   // Pass Pipeline Configuration
    +   virtual bool addInstSelector(PassManagerBase &PM, bool Fast);
    +   virtual bool addPreEmitPass(PassManagerBase &PM, bool Fast);
    +   virtual bool addAssemblyEmitter(PassManagerBase &PM, bool Fast, 
    +                                   std::ostream &Out);
    + };
    + 
    + } // end namespace llvm
    + 
    +
    + +
    +
      +
    • getInstrInfo
    • +
    • getRegisterInfo
    • +
    • getFrameInfo
    • +
    • getTargetData
    • +
    • getSubtargetImpl
    • +
    +

    For some targets, you also need to support the following methods: +

    + +
      +
    • getTargetLowering
    • +
    • getJITInfo
    • +
    +

    In addition, the XXXTargetMachine constructor should specify a + TargetDescription string that determines the data layout for the target machine, + including characteristics such as pointer size, alignment, and endianness. For + example, the constructor for SparcTargetMachine contains the following:

    +
    + +
    +
    + SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &FS)
    +   : DataLayout("E-p:32:32-f128:128:128"),
    +     Subtarget(M, FS), InstrInfo(Subtarget),
    +     FrameInfo(TargetFrameInfo::StackGrowsDown, 8, 0) {
    + }
    + 
    +
    + +
    +

    Hyphens separate portions of the TargetDescription string.

    +
      +
    • The "E" in the string indicates a big-endian target data model; a + lower-case "e" would indicate little-endian.
    • +
    • "p:" is followed by pointer information: size, ABI alignment, and + preferred alignment. If only two figures follow "p:", then the first value is + pointer size, and the second value is both ABI and preferred alignment.
    • +
    • then a letter for numeric type alignment: "i", "f", "v", or "a" + (corresponding to integer, floating point, vector, or aggregate). "i", "v", or + "a" are followed by ABI alignment and preferred alignment. "f" is followed by + three values, the first indicates the size of a long double, then ABI alignment + and preferred alignment.
    • +
    +

    You must also register your target using the RegisterTarget + template. (See the TargetMachineRegistry class.) For example, in SparcTargetMachine.cpp, + the target is registered with:

    +
    + +
    +
    + namespace {
    +   // Register the target.
    +   RegisterTarget<SparcTargetMachine>X("sparc", "SPARC");
    + }
    + 
    +
    + + + + +
    +

    You should describe + a concrete target-specific class + that represents the register file of a target machine. This class is + called XXXRegisterInfo (where XXX identifies the target) and represents the + class register file data that is used for register allocation and also + describes the interactions between registers.

    + +

    You also need to + define register classes to categorize related registers. A register class + should be added for groups of registers that are all treated the same way for + some instruction. Typical examples are register classes that include integer, + floating-point, or vector registers. A register allocator allows an + instruction to use any register in a specified register class to perform the + instruction in a similar manner. Register classes allocate virtual registers to + instructions from these sets, and register classes let the target-independent + register allocator automatically choose the actual registers.

    + +

    Much of the code for registers, including register definition, + register aliases, and register classes, is generated by TableGen from + XXXRegisterInfo.td input files and placed in XXXGenRegisterInfo.h.inc and + XXXGenRegisterInfo.inc output files. Some of the code in the implementation of + XXXRegisterInfo requires hand-coding.

    +
    + + + +
    +

    The XXXRegisterInfo.td file typically starts with register definitions + for a target machine. The Register class (specified in Target.td) is used to + define an object for each register. The specified string n becomes the Name of + the register. The basic Register object does not have any subregisters and does + not specify any aliases.

    +
    +
    +
    + class Register<string n> {
    +   string Namespace = "";
    +   string AsmName = n;
    +   string Name = n;
    +   int SpillSize = 0;
    +   int SpillAlignment = 0;
    +   list<Register> Aliases = [];
    +   list<Register> SubRegs = [];
    +   list<int> DwarfNumbers = [];
    + }
    + 
    +
    + +
    +

    For example, in the X86RegisterInfo.td file, there are register + definitions that utilize the Register class, such as:

    +
    +
    +
    + def AL : Register<"AL">,
    + DwarfRegNum<[0, 0, 0]>;
    + 
    +
    + +
    +

    This defines the register AL and assigns it values (with + DwarfRegNum) that are used by gcc, gdb, or a debug information writer (such as + DwarfWriter in llvm/lib/CodeGen) to identify a register. For register AL, + DwarfRegNum takes an array of 3 values, representing 3 different modes: the + first element is for X86-64, the second for EH (exception handling) on X86-32, + and the third is generic. -1 is a special Dwarf number that indicates the gcc + number is undefined, and -2 indicates the register number is invalid for this + mode.

    + +

    From the previously described line in the X86RegisterInfo.td + file, TableGen generates this code in the X86GenRegisterInfo.inc file:

    +
    +
    +
    +   static const unsigned GR8[] = { X86::AL, ... };
    +  
    +   const unsigned AL_AliasSet[] = { X86::AX, X86::EAX, X86::RAX, 0 };
    +  
    +   const TargetRegisterDesc RegisterDescriptors[] = { 
    +     ...
    +     { "AL", "AL", AL_AliasSet, Empty_SubRegsSet, Empty_SubRegsSet, AL_SuperRegsSet }, ...
    + 
    +
    + +
    +

    From the register info file, TableGen generates a + TargetRegisterDesc object for each register. TargetRegisterDesc is defined in + include/llvm/Target/TargetRegisterInfo.h with the following fields:

    +
    + +
    +
    + struct TargetRegisterDesc {
    +   const char     *AsmName;      // Assembly language name for the register
    +   const char     *Name;         // Printable name for the reg (for debugging)
    +   const unsigned *AliasSet;     // Register Alias Set
    +   const unsigned *SubRegs;      // Sub-register set
    +   const unsigned *ImmSubRegs;   // Immediate sub-register set
    +   const unsigned *SuperRegs;    // Super-register set
    + };
    +
    + +
    +

    TableGen uses the entire target description file (.td) to + determine text names for the register (in the AsmName and Name fields of + TargetRegisterDesc) and the relationships of other registers to the defined + register (in the other TargetRegisterDesc fields). In this example, other + definitions establish the registers "AX", "EAX", and "RAX" as aliases for one + another, so TableGen generates a null-terminated array (AL_AliasSet) for this + register alias set.

    + +

    The Register class is commonly used as a base class for more + complex classes. In Target.td, the Register class is the base for the + RegisterWithSubRegs class that is used to define registers that need to specify + subregisters in the SubRegs list, as shown here:

    +
    +
    +
    + class RegisterWithSubRegs<string n,
    + list<Register> subregs> : Register<n> {
    +   let SubRegs = subregs;
    + }
    +
    + +
    +

    In SparcRegisterInfo.td, additional register classes are defined + for SPARC: a Register subclass, SparcReg, and further subclasses: Ri, Rf, and + Rd. SPARC registers are identified by 5-bit ID numbers, which is a feature + common to these subclasses. Note the use of ‘let’ expressions to override values + that are initially defined in a superclass (such as SubRegs field in the Rd + class).

    +
    +
    +
    + class SparcReg<string n> : Register<n> {
    +   field bits<5> Num;
    +   let Namespace = "SP";
    + }
    + // Ri - 32-bit integer registers
    + class Ri<bits<5> num, string n> :
    + SparcReg<n> {
    +   let Num = num;
    + }
    + // Rf - 32-bit floating-point registers
    + class Rf<bits<5> num, string n> :
    + SparcReg<n> {
    +   let Num = num;
    + }
    + // Rd - Slots in the FP register file for 64-bit
    + floating-point values.
    + class Rd<bits<5> num, string n,
    + list<Register> subregs> : SparcReg<n> {
    +   let Num = num;
    +   let SubRegs = subregs;
    + }
    +
    +
    +

    In the SparcRegisterInfo.td file, there are register definitions + that utilize these subclasses of Register, such as:

    +
    +
    +
    + def G0 : Ri< 0, "G0">,
    + DwarfRegNum<[0]>;
    + def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>;
    + ...
    + def F0 : Rf< 0, "F0">,
    + DwarfRegNum<[32]>;
    + def F1 : Rf< 1, "F1">,
    + DwarfRegNum<[33]>;
    + ...
    + def D0 : Rd< 0, "F0", [F0, F1]>,
    + DwarfRegNum<[32]>;
    + def D1 : Rd< 2, "F2", [F2, F3]>,
    + DwarfRegNum<[34]>;
    + 
    +
    +
    +

    The last two registers shown above (D0 and D1) are double-precision + floating-point registers that are aliases for pairs of single-precision + floating-point sub-registers. In addition to aliases, the sub-register and + super-register relationships of the defined register are in fields of a + register’s TargetRegisterDesc.

    +
    + + + +
    +

    The RegisterClass class (specified in Target.td) is used to + define an object that represents a group of related registers and also defines + the default allocation order of the registers. A target description file + XXXRegisterInfo.td that uses Target.td can construct register classes using the + following class:

    +
    + +
    +
    + class RegisterClass<string namespace,
    + list<ValueType> regTypes, int alignment,
    +                     list<Register> regList> {
    +   string Namespace = namespace;
    +   list<ValueType> RegTypes = regTypes;
    +   int Size = 0;  // spill size, in bits; zero lets tblgen pick the size
    +   int Alignment = alignment;
    +  
    +   // CopyCost is the cost of copying a value between two registers
    +   // default value 1 means a single instruction
    +   // A negative value means copying is extremely expensive or impossible
    +   int CopyCost = 1;  
    +   list<Register> MemberList = regList;
    +   
    +   // for register classes that are subregisters of this class
    +   list<RegisterClass> SubRegClassList = [];  
    +   
    +   code MethodProtos = [{}];  // to insert arbitrary code
    +   code MethodBodies = [{}];
    + }
    +
    +
    +

    To define a RegisterClass, use the following 4 arguments:

    +
      +
    • The first argument of the definition is the name of the + namespace.
    • + +
    • The second argument is a list of ValueType register type values + that are defined in include/llvm/CodeGen/ValueTypes.td. Defined values include + integer types (such as i16, i32, and i1 for Boolean), floating-point types + (f32, f64), and vector types (for example, v8i16 for an 8 x i16 vector). All + registers in a RegisterClass must have the same ValueType, but some registers + may store vector data in different configurations. For example a register that + can process a 128-bit vector may be able to handle 16 8-bit integer elements, 8 + 16-bit integers, 4 32-bit integers, and so on.
    • + +
    • The third argument of the RegisterClass definition specifies the + alignment required of the registers when they are stored or loaded to memory.
    • + +
    • The final argument, regList, specifies which registers are in + this class. If an allocation_order_* method is not specified, then regList also + defines the order of allocation used by the register allocator.
    • +
    + +

    In SparcRegisterInfo.td, three RegisterClass objects are defined: + FPRegs, DFPRegs, and IntRegs. For all three register classes, the first + argument defines the namespace with the string “SP”. FPRegs defines a group of 32 + single-precision floating-point registers (F0 to F31); DFPRegs defines a group + of 16 double-precision registers (D0-D15). For IntRegs, the MethodProtos and + MethodBodies methods are used by TableGen to insert the specified code into generated + output.

    +
    +
    +
    + def FPRegs : RegisterClass<"SP", [f32], 32, [F0, F1, F2, F3, F4, F5, F6, F7,   
    +   F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F18, F19, F20, F21, F22,
    +   F23, F24, F25, F26, F27, F28, F29, F30, F31]>;
    +  
    + def DFPRegs : RegisterClass<"SP", [f64], 64, [D0, D1, D2, D3, D4, D5, D6, D7,
    +   D8, D9, D10, D11, D12, D13, D14, D15]>;
    +  
    + def IntRegs : RegisterClass<"SP", [i32], 32, [L0, L1, L2, L3, L4, L5, L6, L7,
    +                                      I0, I1, I2, I3, I4, I5,
    +                                      O0, O1, O2, O3, O4, O5, O7,
    +                                      G1,
    +                                      // Non-allocatable regs:
    +                                      G2, G3, G4, 
    +                                      O6, // stack ptr
    +                                      I6, // frame ptr
    +                                      I7, // return address
    +                                      G0, // constant zero
    +                                      G5, G6, G7 // reserved for kernel
    +                                      ]> {
    +   let MethodProtos = [{
    +     iterator allocation_order_end(const MachineFunction &MF) const;
    +   }];
    +   let MethodBodies = [{
    +     IntRegsClass::iterator
    +     IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
    +       return end()-10  // Don't allocate special registers
    +          -1;  
    +     }
    +   }];
    + }
    + 
    +
    + +
    +

    Using SparcRegisterInfo.td with TableGen generates several output + files that are intended for inclusion in other source code that you write. + SparcRegisterInfo.td generates SparcGenRegisterInfo.h.inc, which should be + included in the header file for the implementation of the SPARC register + implementation that you write (SparcRegisterInfo.h). In + SparcGenRegisterInfo.h.inc a new structure is defined called + SparcGenRegisterInfo that uses TargetRegisterInfo as its base. It also + specifies types, based upon the defined register classes: DFPRegsClass, FPRegsClass, + and IntRegsClass.

    + +

    SparcRegisterInfo.td also generates SparcGenRegisterInfo.inc, + which is included at the bottom of SparcRegisterInfo.cpp, the SPARC register + implementation. The code below shows only the generated integer registers and + associated register classes. The order of registers in IntRegs reflects the + order in the definition of IntRegs in the target description file. Take special + note of the use of MethodBodies in SparcRegisterInfo.td to create code in + SparcGenRegisterInfo.inc. MethodProtos generates similar code in + SparcGenRegisterInfo.h.inc.

    +
    + +
    +
      // IntRegs Register Class...
    +   static const unsigned IntRegs[] = {
    +     SP::L0, SP::L1, SP::L2, SP::L3, SP::L4, SP::L5,
    + SP::L6, SP::L7, SP::I0, SP::I1, SP::I2, SP::I3, SP::I4, SP::I5, SP::O0, SP::O1,
    + SP::O2, SP::O3, SP::O4, SP::O5, SP::O7, SP::G1, SP::G2, SP::G3, SP::G4, SP::O6,
    + SP::I6, SP::I7, SP::G0, SP::G5, SP::G6, SP::G7, 
    +   };
    +  
    +   // IntRegsVTs Register Class Value Types...
    +   static const MVT::ValueType IntRegsVTs[] = {
    +     MVT::i32, MVT::Other
    +   };
    + namespace SP {   // Register class instances
    +   DFPRegsClass    DFPRegsRegClass;
    +   FPRegsClass     FPRegsRegClass;
    +   IntRegsClass    IntRegsRegClass;
    + ...
    +  
    + // IntRegs Sub-register Classess...
    +   static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
    +     NULL
    +   };
    + ...
    + // IntRegs Super-register Classess...
    +   static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
    +     NULL
    +   };
    +  
    + // IntRegs Register Class sub-classes...
    +   static const TargetRegisterClass* const IntRegsSubclasses [] = {
    +     NULL
    +   };
    + ...
    +  
    + // IntRegs Register Class super-classes...
    +   static const TargetRegisterClass* const IntRegsSuperclasses [] = {
    +     NULL
    +   };
    + ...
    +  
    +   IntRegsClass::iterator
    +   IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
    + 
    +      return end()-10  // Don't allocate special registers
    +          -1; 
    +   }
    +   
    + IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID, 
    +    IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses, 
    +    IntRegsSuperRegClasses, 4, 4, 1, IntRegs, IntRegs + 32) {}
    + }
    + 
    +
    + + +
    +

    The final step is to hand code portions of XXXRegisterInfo, which + implements the interface described in TargetRegisterInfo.h. These functions + return 0, NULL, or false, unless overridden. Here’s a list of functions that + are overridden for the SPARC implementation in SparcRegisterInfo.cpp:

    +
      +
    • getCalleeSavedRegs (returns a list of callee-saved registers in + the order of the desired callee-save stack frame offset)
    • + +
    • getCalleeSavedRegClasses (returns a list of preferred register + classes with which to spill each callee saved register)
    • + +
    • getReservedRegs (returns a bitset indexed by physical register + numbers, indicating if a particular register is unavailable)
    • + +
    • hasFP (return a Boolean indicating if a function should have a + dedicated frame pointer register)
    • + +
    • eliminateCallFramePseudoInstr (if call frame setup or destroy + pseudo instructions are used, this can be called to eliminate them)
    • + +
    • eliminateFrameIndex (eliminate abstract frame indices from + instructions that may use them)
    • + +
    • emitPrologue (insert prologue code into the function)
    • + +
    • emitEpilogue (insert epilogue code into the function)
    • +
    +
    + + + + +
    +

    During the early stages of code generation, the LLVM IR code is + converted to a SelectionDAG with nodes that are instances of the SDNode class + containing target instructions. An SDNode has an opcode, operands, type + requirements, and operation properties (for example, is an operation + commutative, does an operation load from memory). The various operation node + types are described in the include/llvm/CodeGen/SelectionDAGNodes.h file (values + of the NodeType enum in the ISD namespace).

    + +

    TableGen uses the following target description (.td) input files + to generate much of the code for instruction definition:

    +
      +
    • Target.td, where the Instruction, Operand, InstrInfo, and other + fundamental classes are defined
    • + +
    • TargetSelectionDAG.td, used by SelectionDAG instruction selection + generators, contains SDTC* classes (selection DAG type constraint), definitions + of SelectionDAG nodes (such as imm, cond, bb, add, fadd, sub), and pattern + support (Pattern, Pat, PatFrag, PatLeaf, ComplexPattern)
    • + +
    • XXXInstrFormats.td, patterns for definitions of target-specific + instructions
    • + +
    • XXXInstrInfo.td, target-specific definitions of instruction + templates, condition codes, and instructions of an instruction set. (For architecture + modifications, a different file name may be used. For example, for Pentium with + SSE instruction, this file is X86InstrSSE.td, and for Pentium with MMX, this + file is X86InstrMMX.td.)
    • +
    +

    There is also a target-specific XXX.td file, where XXX is the + name of the target. The XXX.td file includes the other .td input files, but its + contents are only directly important for subtargets.

    + +

    You should describe + a concrete target-specific class + XXXInstrInfo that represents machine + instructions supported by a target machine. XXXInstrInfo contains an array of + XXXInstrDescriptor objects, each of which describes one instruction. An + instruction descriptor defines:

    +
      +
    • opcode mnemonic
    • + +
    • number of operands
    • + +
    • list of implicit register definitions and uses
    • + +
    • target-independent properties (such as memory access, is + commutable)
    • + +
    • target-specific flags
    • +
    + +

    The Instruction class (defined in Target.td) is mostly used as a + base for more complex instruction classes.

    +
    + +
    +
    class Instruction {
    +   string Namespace = "";
    +   dag OutOperandList;       // An dag containing the MI def operand list.
    +   dag InOperandList;        // An dag containing the MI use operand list.
    +   string AsmString = "";    // The .s format to print the instruction with.
    +   list<dag> Pattern;  // Set to the DAG pattern for this instruction
    +   list<Register> Uses = []; 
    +   list<Register> Defs = [];
    +   list<Predicate> Predicates = [];  // predicates turned into isel match code
    +   ... remainder not shown for space ...
    + }
    + 
    +
    +
    +

    A SelectionDAG node (SDNode) should contain an object + representing a target-specific instruction that is defined in XXXInstrInfo.td. The + instruction objects should represent instructions from the architecture manual + of the target machine (such as the + SPARC Architecture Manual for the SPARC target).

    + +

    A single + instruction from the architecture manual is often modeled as multiple target + instructions, depending upon its operands.  For example, a manual might + describe an add instruction that takes a register or an immediate operand. An + LLVM target could model this with two instructions named ADDri and ADDrr.

    + +

    You should define a + class for each instruction category and define each opcode as a subclass of the + category with appropriate parameters such as the fixed binary encoding of + opcodes and extended opcodes. You should map the register bits to the bits of + the instruction in which they are encoded (for the JIT). Also you should specify + how the instruction should be printed when the automatic assembly printer is + used.

    + +

    As is described in + the SPARC Architecture Manual, Version 8, there are three major 32-bit formats + for instructions. Format 1 is only for the CALL instruction. Format 2 is for + branch on condition codes and SETHI (set high bits of a register) instructions. + Format 3 is for other instructions.

    + +

    Each of these + formats has corresponding classes in SparcInstrFormat.td. InstSP is a base + class for other instruction classes. Additional base classes are specified for + more precise formats: for example in SparcInstrFormat.td, F2_1 is for SETHI, + and F2_2 is for branches. There are three other base classes: F3_1 for + register/register operations, F3_2 for register/immediate operations, and F3_3 for + floating-point operations. SparcInstrInfo.td also adds the base class Pseudo for + synthetic SPARC instructions.

    + +

    SparcInstrInfo.td + largely consists of operand and instruction definitions for the SPARC target. In + SparcInstrInfo.td, the following target description file entry, LDrr, defines + the Load Integer instruction for a Word (the LD SPARC opcode) from a memory + address to a register. The first parameter, the value 3 (112), is + the operation value for this category of operation. The second parameter + (0000002) is the specific operation value for LD/Load Word. The + third parameter is the output destination, which is a register operand and + defined in the Register target description file (IntRegs).

    +
    +
    +
    def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
    +                  "ld [$addr], $dst",
    +                  [(set IntRegs:$dst, (load ADDRrr:$addr))]>;
    + 
    +
    + +
    +

    The fourth + parameter is the input source, which uses the address operand MEMrr that is + defined earlier in SparcInstrInfo.td:

    +
    +
    +
    def MEMrr : Operand<i32> {
    +   let PrintMethod = "printMemOperand";
    +   let MIOperandInfo = (ops IntRegs, IntRegs);
    + }
    + 
    +
    +
    +

    The fifth parameter is a string that is used by the assembly + printer and can be left as an empty string until the assembly printer interface + is implemented. The sixth and final parameter is the pattern used to match the + instruction during the SelectionDAG Select Phase described in + (The LLVM Target-Independent Code Generator). + This parameter is detailed in the next section, Instruction Selector.

    + +

    Instruction class definitions are not overloaded for different + operand types, so separate versions of instructions are needed for register, + memory, or immediate value operands. For example, to perform a + Load Integer instruction for a Word + from an immediate operand to a register, the following instruction class is + defined:

    +
    +
    +
    def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
    +                  "ld [$addr], $dst",
    +                  [(set IntRegs:$dst, (load ADDRri:$addr))]>;
    + 
    +
    +
    +

    Writing these definitions for so many similar instructions can + involve a lot of cut and paste. In td files, the multiclass directive enables + the creation of templates to define several instruction classes at once (using + the defm directive). For example in + SparcInstrInfo.td, the multiclass pattern F3_12 is defined to create 2 + instruction classes each time F3_12 is invoked:

    +
    +
    +
    multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
    +   def rr  : F3_1 <2, Op3Val, 
    +                  (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
    +                  !strconcat(OpcStr, " $b, $c, $dst"),
    +                  [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>;
    +   def ri  : F3_2 <2, Op3Val,
    +                  (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
    +                  !strconcat(OpcStr, " $b, $c, $dst"),
    +                  [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>;
    + }
    + 
    +
    +
    +

    So when the defm directive is used for the XOR and ADD + instructions, as seen below, it creates four instruction objects: XORrr, XORri, + ADDrr, and ADDri.

    +
    +
    +
    defm XOR   : F3_12<"xor", 0b000011, xor>;
    + defm ADD   : F3_12<"add", 0b000000, add>;
    + 
    +
    + +
    +

    SparcInstrInfo.td + also includes definitions for condition codes that are referenced by branch + instructions. The following definitions in SparcInstrInfo.td indicate the bit location + of the SPARC condition code; for example, the 10th bit represents + the ‘greater than’ condition for integers, and the 22nd bit + represents the ‘greater than’ condition for floats.

    +
    + +
    +
    def ICC_NE  : ICC_VAL< 9>;  // Not Equal
    + def ICC_E   : ICC_VAL< 1>;  // Equal
    + def ICC_G   : ICC_VAL<10>;  // Greater
    + ...
    + def FCC_U   : FCC_VAL<23>;  // Unordered
    + def FCC_G   : FCC_VAL<22>;  // Greater
    + def FCC_UG  : FCC_VAL<21>;  // Unordered or Greater
    + ...
    + 
    +
    + +
    +

    (Note that Sparc.h + also defines enums that correspond to the same SPARC condition codes. Care must + be taken to ensure the values in Sparc.h correspond to the values in + SparcInstrInfo.td; that is, SPCC::ICC_NE = 9, SPCC::FCC_U = 23 and so on.)

    +
    + + + +
    +

    The code generator backend maps instruction operands to fields in + the instruction. Operands are assigned to unbound fields in the instruction in + the order they are defined. Fields are bound when they are assigned a value. + For example, the Sparc target defines the XNORrr instruction as a F3_1 format + instruction having three operands.

    +
    + +
    + def XNORrr  : F3_1<2, 0b000111,
    +                    (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
    +                    "xnor $b, $c, $dst",
    +                    [(set IntRegs:$dst, (not (xor IntRegs:$b, IntRegs:$c)))]>;
    + 
    + +
    +

    The instruction templates in SparcInstrFormats.td show the base class for F3_1 is InstSP.

    +
    + +
    + class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
    +   field bits<32> Inst;
    +   let Namespace = "SP";
    +   bits<2> op;
    +   let Inst{31-30} = op;       
    +   dag OutOperandList = outs;
    +   dag InOperandList = ins;
    +   let AsmString   = asmstr;
    +   let Pattern = pattern;
    + }
    + 
    +
    +

    + InstSP leaves the op field unbound. +

    +
    + +
    + class F3<dag outs, dag ins, string asmstr, list<dag> pattern>
    +     : InstSP<outs, ins, asmstr, pattern> {
    +   bits<5> rd;
    +   bits<6> op3;
    +   bits<5> rs1;
    +   let op{1} = 1;   // Op = 2 or 3
    +   let Inst{29-25} = rd;
    +   let Inst{24-19} = op3;
    +   let Inst{18-14} = rs1;
    + }
    + 
    +
    +

    + F3 binds the op field and defines the rd, op3, and rs1 fields. F3 format instructions will + bind the operands rd, op3, and rs1 fields. +

    +
    + +
    + class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins,
    +            string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> {
    +   bits<8> asi = 0; // asi not currently used
    +   bits<5> rs2;
    +   let op         = opVal;
    +   let op3        = op3val;
    +   let Inst{13}   = 0;     // i field = 0
    +   let Inst{12-5} = asi;   // address space identifier
    +   let Inst{4-0}  = rs2;
    + }
    + 
    +
    +

    + F3_1 binds the op3 field and defines the rs2 fields. F3_1 format instructions will + bind the operands to the rd, rs1, and rs2 fields. This results in the XNORrr instruction + binding $dst, $b, and $c operands to the rd, rs1, and rs2 fields respectively. +

    +
    + + + + + + +
    +

    The final step is to hand code portions of XXXInstrInfo, which + implements the interface described in TargetInstrInfo.h. These functions return + 0 or a Boolean or they assert, unless overridden. Here's a list of functions + that are overridden for the SPARC implementation in SparcInstrInfo.cpp:

    +
      +
    • isMoveInstr (return true if the instruction is a register to + register move; false, otherwise)
    • + +
    • isLoadFromStackSlot (if the specified machine instruction is a + direct load from a stack slot, return the register number of the destination + and the FrameIndex of the stack slot)
    • + +
    • isStoreToStackSlot (if the specified machine instruction is a + direct store to a stack slot, return the register number of the destination and + the FrameIndex of the stack slot)
    • + +
    • copyRegToReg (copy values between a pair of registers)
    • + +
    • storeRegToStackSlot (store a register value to a stack slot)
    • + +
    • loadRegFromStackSlot (load a register value from a stack slot)
    • + +
    • storeRegToAddr (store a register value to memory)
    • + +
    • loadRegFromAddr (load a register value from memory)
    • + +
    • foldMemoryOperand (attempt to combine instructions of any load or + store instruction for the specified operand(s))
    • +
    +
    + + + +
    +

    Performance can be improved by combining instructions or by eliminating + instructions that are never reached. The AnalyzeBranch method in XXXInstrInfo may + be implemented to examine conditional instructions and remove unnecessary + instructions. AnalyzeBranch looks at the end of a machine basic block (MBB) for + opportunities for improvement, such as branch folding and if conversion. The + BranchFolder and IfConverter machine function passes (see the source files + BranchFolding.cpp and IfConversion.cpp in the lib/CodeGen directory) call + AnalyzeBranch to improve the control flow graph that represents the + instructions.

    + +

    Several implementations of AnalyzeBranch (for ARM, Alpha, and + X86) can be examined as models for your own AnalyzeBranch implementation. Since + SPARC does not implement a useful AnalyzeBranch, the ARM target implementation + is shown below.

    + +

    AnalyzeBranch returns a Boolean value and takes four parameters:

    +
      +
    • MachineBasicBlock &MBB – the incoming block to be + examined
    • + +
    • MachineBasicBlock *&TBB – a destination block that is + returned; for a conditional branch that evaluates to true, TBB is the + destination
    • + +
    • MachineBasicBlock *&FBB – for a conditional branch that + evaluates to false, FBB is returned as the destination
    • + +
    • std::vector<MachineOperand> &Cond – list of + operands to evaluate a condition for a conditional branch
    • +
    + +

    In the simplest case, if a block ends without a branch, then it + falls through to the successor block. No destination blocks are specified for + either TBB or FBB, so both parameters return NULL. The start of the AnalyzeBranch + (see code below for the ARM target) shows the function parameters and the code + for the simplest case.

    +
    + +
    +
    bool ARMInstrInfo::AnalyzeBranch(MachineBasicBlock &MBB,
    +         MachineBasicBlock *&TBB, MachineBasicBlock *&FBB,
    +         std::vector<MachineOperand> &Cond) const
    + {
    +   MachineBasicBlock::iterator I = MBB.end();
    +   if (I == MBB.begin() || !isUnpredicatedTerminator(--I))
    +     return false;
    + 
    +
    + +
    +

    If a block ends with a single unconditional branch instruction, + then AnalyzeBranch (shown below) should return the destination of that branch + in the TBB parameter.

    +
    + +
    +
    if (LastOpc == ARM::B || LastOpc == ARM::tB) {
    +       TBB = LastInst->getOperand(0).getMBB();
    +       return false;
    +     }
    + 
    +
    + +
    +

    If a block ends with two unconditional branches, then the second + branch is never reached. In that situation, as shown below, remove the last + branch instruction and return the penultimate branch in the TBB parameter.

    +
    + +
    +
    if ((SecondLastOpc == ARM::B || SecondLastOpc==ARM::tB) &&
    +       (LastOpc == ARM::B || LastOpc == ARM::tB)) {
    +     TBB = SecondLastInst->getOperand(0).getMBB();
    +     I = LastInst;
    +     I->eraseFromParent();
    +     return false;
    +   }
    + 
    +
    +
    +

    A block may end with a single conditional branch instruction that + falls through to successor block if the condition evaluates to false. In that + case, AnalyzeBranch (shown below) should return the destination of that + conditional branch in the TBB parameter and a list of operands in the Cond + parameter to evaluate the condition.

    +
    + +
    +
    if (LastOpc == ARM::Bcc || LastOpc == ARM::tBcc) {
    +       // Block ends with fall-through condbranch.
    +       TBB = LastInst->getOperand(0).getMBB();
    +       Cond.push_back(LastInst->getOperand(1));
    +       Cond.push_back(LastInst->getOperand(2));
    +       return false;
    +     }
    + 
    +
    + +
    +

    If a block ends with both a conditional branch and an ensuing + unconditional branch, then AnalyzeBranch (shown below) should return the + conditional branch destination (assuming it corresponds to a conditional + evaluation of ‘true’) in the TBB parameter and the unconditional branch + destination in the FBB (corresponding to a conditional evaluation of ‘false’). + A list of operands to evaluate the condition should be returned in the Cond + parameter.

    +
    + +
    +
    unsigned SecondLastOpc = SecondLastInst->getOpcode();
    +   if ((SecondLastOpc == ARM::Bcc && LastOpc == ARM::B) ||
    +       (SecondLastOpc == ARM::tBcc && LastOpc == ARM::tB)) {
    +     TBB =  SecondLastInst->getOperand(0).getMBB();
    +     Cond.push_back(SecondLastInst->getOperand(1));
    +     Cond.push_back(SecondLastInst->getOperand(2));
    +     FBB = LastInst->getOperand(0).getMBB();
    +     return false;
    +   }
    + 
    +
    + +
    +

    For the last two cases (ending with a single conditional branch or + ending with one conditional and one unconditional branch), the operands returned + in the Cond parameter can be passed to methods of other instructions to create + new branches or perform other operations. An implementation of AnalyzeBranch + requires the helper methods RemoveBranch and InsertBranch to manage subsequent + operations.

    + +

    AnalyzeBranch should return false indicating success in most circumstances. + AnalyzeBranch should only return true when the method is stumped about what to + do, for example, if a block has three terminating branches. AnalyzeBranch may + return true if it encounters a terminator it cannot handle, such as an indirect + branch.

    +
    + + + + + +
    +

    LLVM uses a SelectionDAG to represent LLVM IR instructions, and nodes + of the SelectionDAG ideally represent native target instructions. During code + generation, instruction selection passes are performed to convert non-native + DAG instructions into native target-specific instructions. The pass described + in XXXISelDAGToDAG.cpp is used to match patterns and perform DAG-to-DAG + instruction selection. Optionally, a pass may be defined (in + XXXBranchSelector.cpp) to perform similar DAG-to-DAG operations for branch + instructions. Later, + the code in XXXISelLowering.cpp replaces or removes operations and data types + not supported natively (legalizes) in a Selection DAG.

    + +

    TableGen generates code for instruction selection using the + following target description input files:

    +
      +
    • XXXInstrInfo.td contains definitions of instructions in a + target-specific instruction set, generates XXXGenDAGISel.inc, which is included + in XXXISelDAGToDAG.cpp.
    • + +
    • XXXCallingConv.td contains the calling and return value conventions + for the target architecture, and it generates XXXGenCallingConv.inc, which is + included in XXXISelLowering.cpp.
    • +
    + +

    The implementation of an instruction selection pass must include + a header that declares the FunctionPass class or a subclass of FunctionPass. In + XXXTargetMachine.cpp, a Pass Manager (PM) should add each instruction selection + pass into the queue of passes to run.

    + +

    The LLVM static + compiler (llc) is an excellent tool for visualizing the contents of DAGs. To display + the SelectionDAG before or after specific processing phases, use the command + line options for llc, described at + SelectionDAG Instruction Selection Process. +

    + +

    To describe instruction selector behavior, you should add + patterns for lowering LLVM code into a SelectionDAG as the last parameter of + the instruction definitions in XXXInstrInfo.td. For example, in + SparcInstrInfo.td, this entry defines a register store operation, and the last + parameter describes a pattern with the store DAG operator.

    +
    + +
    +
    def STrr  : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
    +                  "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;
    + 
    +
    + +
    +

    ADDRrr is a memory mode that is also defined in SparcInstrInfo.td:

    +
    + +
    +
    def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
    + 
    +
    + +
    +

    The definition of ADDRrr refers to SelectADDRrr, which is a function defined in an + implementation of the Instructor Selector (such as SparcISelDAGToDAG.cpp).

    + +

    In lib/Target/TargetSelectionDAG.td, the DAG operator for store + is defined below:

    +
    + +
    +
    def store : PatFrag<(ops node:$val, node:$ptr),
    +                     (st node:$val, node:$ptr), [{
    +   if (StoreSDNode *ST = dyn_cast<StoreSDNode>(N))
    +     return !ST->isTruncatingStore() && 
    +            ST->getAddressingMode() == ISD::UNINDEXED;
    +   return false;
    + }]>;
    + 
    +
    +
    +

    XXXInstrInfo.td also generates (in XXXGenDAGISel.inc) the + SelectCode method that is used to call the appropriate processing method for an + instruction. In this example, SelectCode calls Select_ISD_STORE for the + ISD::STORE opcode.

    +
    + +
    +
    SDNode *SelectCode(SDValue N) {
    +   ... 
    +   MVT::ValueType NVT = N.getNode()->getValueType(0);
    +   switch (N.getOpcode()) {
    +   case ISD::STORE: {
    +     switch (NVT) {
    +     default:
    +       return Select_ISD_STORE(N);
    +       break;
    +     }
    +     break;
    +   }
    +   ...
    + 
    +
    +
    +

    The pattern for STrr is matched, so elsewhere in + XXXGenDAGISel.inc, code for STrr is created for Select_ISD_STORE. The Emit_22 method + is also generated in XXXGenDAGISel.inc to complete the processing of this + instruction.

    +
    + +
    +
    SDNode *Select_ISD_STORE(const SDValue &N) {
    +   SDValue Chain = N.getOperand(0);
    +   if (Predicate_store(N.getNode())) {
    +     SDValue N1 = N.getOperand(1);
    +     SDValue N2 = N.getOperand(2);
    +     SDValue CPTmp0;
    +     SDValue CPTmp1;
    +  
    +     // Pattern: (st:void IntRegs:i32:$src, 
    +     //           ADDRrr:i32:$addr)<<P:Predicate_store>>
    +     // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src)
    +     // Pattern complexity = 13  cost = 1  size = 0
    +     if (SelectADDRrr(N, N2, CPTmp0, CPTmp1) &&
    +         N1.getNode()->getValueType(0) == MVT::i32 &&
    +         N2.getNode()->getValueType(0) == MVT::i32) {
    +       return Emit_22(N, SP::STrr, CPTmp0, CPTmp1);
    +     }
    + ...
    + 
    +
    + + + +
    +

    The Legalize phase converts a DAG to use types and operations + that are natively supported by the target. For natively unsupported types and + operations, you need to add code to the target-specific XXXTargetLowering implementation + to convert unsupported types and operations to supported ones.

    + +

    In the constructor for the XXXTargetLowering class, first use the + addRegisterClass method to specify which types are supports and which register + classes are associated with them. The code for the register classes are generated + by TableGen from XXXRegisterInfo.td and placed in XXXGenRegisterInfo.h.inc. For + example, the implementation of the constructor for the SparcTargetLowering + class (in SparcISelLowering.cpp) starts with the following code:

    +
    + +
    +
    addRegisterClass(MVT::i32, SP::IntRegsRegisterClass);
    + addRegisterClass(MVT::f32, SP::FPRegsRegisterClass);
    + addRegisterClass(MVT::f64, SP::DFPRegsRegisterClass); 
    + 
    +
    + +
    +

    You should examine the node types in the ISD namespace + (include/llvm/CodeGen/SelectionDAGNodes.h) + and determine which operations the target natively supports. For operations + that do not have native support, add a callback to the constructor for + the XXXTargetLowering class, so the instruction selection process knows what to + do. The TargetLowering class callback methods (declared in + llvm/Target/TargetLowering.h) are:

    +
      +
    • setOperationAction (general operation)
    • + +
    • setLoadExtAction (load with extension)
    • + +
    • setTruncStoreAction (truncating store)
    • + +
    • setIndexedLoadAction (indexed load)
    • + +
    • setIndexedStoreAction (indexed store)
    • + +
    • setConvertAction (type conversion)
    • + +
    • setCondCodeAction (support for a given condition code)
    • +
    + +

    Note: on older releases, setLoadXAction is used instead of setLoadExtAction. + Also, on older releases, setCondCodeAction may not be supported. Examine your + release to see what methods are specifically supported.

    + +

    These callbacks are used to determine that an operation does or + does not work with a specified type (or types). And in all cases, the third + parameter is a LegalAction type enum value: Promote, Expand, + Custom, or Legal. SparcISelLowering.cpp + contains examples of all four LegalAction values.

    +
    + + +
    + Promote +
    + +
    +

    For an operation without native support for a given type, the + specified type may be promoted to a larger type that is supported. For example, + SPARC does not support a sign-extending load for Boolean values (i1 type), so + in SparcISelLowering.cpp the third + parameter below, Promote, changes i1 type + values to a large type before loading.

    +
    + +
    +
    setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
    + 
    +
    + + +
    + Expand +
    +
    +

    For a type without native support, a value may need to be broken + down further, rather than promoted. For an operation without native support, a + combination of other operations may be used to similar effect. In SPARC, the + floating-point sine and cosine trig operations are supported by expansion to + other operations, as indicated by the third parameter, Expand, to + setOperationAction:

    +
    + +
    +
    setOperationAction(ISD::FSIN, MVT::f32, Expand);
    + setOperationAction(ISD::FCOS, MVT::f32, Expand);
    + 
    +
    + + +
    + Custom +
    +
    +

    For some operations, simple type promotion or operation expansion + may be insufficient. In some cases, a special intrinsic function must be + implemented.

    + +

    For example, a constant value may require special treatment, or + an operation may require spilling and restoring registers in the stack and + working with register allocators.

    + +

    As seen in SparcISelLowering.cpp code below, to perform a type + conversion from a floating point value to a signed integer, first the + setOperationAction should be called with Custom as the third parameter:

    +
    + +
    +
    setOperationAction(ISD::FP_TO_SINT, MVT::i32, Custom);
    + 
    +
    +
    +

    In the LowerOperation method, for each Custom operation, a case + statement should be added to indicate what function to call. In the following + code, an FP_TO_SINT opcode will call the LowerFP_TO_SINT method:

    +
    + +
    +
    SDValue SparcTargetLowering::LowerOperation(
    +                                SDValue Op, SelectionDAG &DAG) {
    +   switch (Op.getOpcode()) {
    +   case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG);
    +   ...
    +   }
    + }
    + 
    +
    +
    +

    Finally, the LowerFP_TO_SINT method is implemented, using an FP + register to convert the floating-point value to an integer.

    +
    + +
    +
    static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) {
    + assert(Op.getValueType() == MVT::i32);
    +   Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0));
    +   return DAG.getNode(ISD::BIT_CONVERT, MVT::i32, Op);
    + }
    + 
    +
    + +
    + Legal +
    +
    +

    The Legal LegalizeAction enum value simply indicates that an + operation is natively supported. Legal represents the default condition, + so it is rarely used. In SparcISelLowering.cpp, the action for CTPOP (an + operation to count the bits set in an integer) is natively supported only for + SPARC v9. The following code enables the Expand conversion technique for non-v9 + SPARC implementations.

    +
    + +
    +
    setOperationAction(ISD::CTPOP, MVT::i32, Expand);
    + ...
    + if (TM.getSubtarget<SparcSubtarget>().isV9())
    +   setOperationAction(ISD::CTPOP, MVT::i32, Legal);
    +   case ISD::SETULT: return SPCC::ICC_CS;
    +   case ISD::SETULE: return SPCC::ICC_LEU;
    +   case ISD::SETUGT: return SPCC::ICC_GU;
    +   case ISD::SETUGE: return SPCC::ICC_CC;
    +   }
    + }
    + 
    +
    + + +
    +

    To support target-specific calling conventions, XXXGenCallingConv.td + uses interfaces (such as CCIfType and CCAssignToReg) that are defined in + lib/Target/TargetCallingConv.td. TableGen can take the target descriptor file + XXXGenCallingConv.td and generate the header file XXXGenCallingConv.inc, which + is typically included in XXXISelLowering.cpp. You can use the interfaces in + TargetCallingConv.td to specify:

    +
      +
    • the order of parameter allocation
    • + +
    • where parameters and return values are placed (that is, on the + stack or in registers)
    • + +
    • which registers may be used
    • + +
    • whether the caller or callee unwinds the stack
    • +
    + +

    The following example demonstrates the use of the CCIfType and + CCAssignToReg interfaces. If the CCIfType predicate is true (that is, if the + current argument is of type f32 or f64), then the action is performed. In this + case, the CCAssignToReg action assigns the argument value to the first + available register: either R0 or R1.

    +
    +
    +
    CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
    + 
    +
    +
    +

    SparcCallingConv.td contains definitions for a target-specific return-value + calling convention (RetCC_Sparc32) and a basic 32-bit C calling convention + (CC_Sparc32). The definition of RetCC_Sparc32 (shown below) indicates which + registers are used for specified scalar return types. A single-precision float + is returned to register F0, and a double-precision float goes to register D0. A + 32-bit integer is returned in register I0 or I1.

    +
    + +
    +
    def RetCC_Sparc32 : CallingConv<[
    +   CCIfType<[i32], CCAssignToReg<[I0, I1]>>,
    +   CCIfType<[f32], CCAssignToReg<[F0]>>,
    +   CCIfType<[f64], CCAssignToReg<[D0]>>
    + ]>;
    + 
    +
    +
    +

    The definition of CC_Sparc32 in SparcCallingConv.td introduces + CCAssignToStack, which assigns the value to a stack slot with the specified size + and alignment. In the example below, the first parameter, 4, indicates the size + of the slot, and the second parameter, also 4, indicates the stack alignment + along 4-byte units. (Special cases: if size is zero, then the ABI size is used; + if alignment is zero, then the ABI alignment is used.)

    +
    + +
    +
    def CC_Sparc32 : CallingConv<[
    +   // All arguments get passed in integer registers if there is space.
    +   CCIfType<[i32, f32, f64], CCAssignToReg<[I0, I1, I2, I3, I4, I5]>>,
    +   CCAssignToStack<4, 4>
    + ]>;
    + 
    +
    +
    +

    CCDelegateTo is another commonly used interface, which tries to find + a specified sub-calling convention and, if a match is found, it is invoked. In + the following example (in X86CallingConv.td), the definition of RetCC_X86_32_C + ends with CCDelegateTo. After the current value is assigned to the register ST0 + or ST1, the RetCC_X86Common is invoked.

    +
    + +
    +
    def RetCC_X86_32_C : CallingConv<[
    +   CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>,
    +   CCIfType<[f64], CCAssignToReg<[ST0, ST1]>>,
    +   CCDelegateTo<RetCC_X86Common>
    + ]>;
    + 
    +
    +
    +

    CCIfCC is an interface that attempts to match the given name to + the current calling convention. If the name identifies the current calling + convention, then a specified action is invoked. In the following example (in + X86CallingConv.td), if the Fast calling convention is in use, then RetCC_X86_32_Fast + is invoked. If the SSECall calling convention is in use, then RetCC_X86_32_SSE + is invoked.

    +
    + +
    +
    def RetCC_X86_32 : CallingConv<[
    +   CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
    +   CCIfCC<"CallingConv::X86_SSECall", CCDelegateTo<RetCC_X86_32_SSE>>,
    +   CCDelegateTo<RetCC_X86_32_C>
    + ]>;
    + 
    +
    +
    +

    Other calling convention interfaces include:

    +
      +
    • CCIf <predicate, action> - if the predicate matches, apply + the action
    • + +
    • CCIfInReg <action> - if the argument is marked with the + ‘inreg’ attribute, then apply the action
    • + +
    • CCIfNest <action> - if the argument is marked with the + ‘nest’ attribute, then apply the action
    • + +
    • CCIfNotVarArg <action> - if the current function does not + take a variable number of arguments, apply the action
    • + +
    • CCAssignToRegWithShadow <registerList, shadowList> - + similar to CCAssignToReg, but with a shadow list of registers
    • + +
    • CCPassByVal <size, align> - assign value to a stack slot + with the minimum specified size and alignment
    • + +
    • CCPromoteToType <type> - promote the current value to the specified + type
    • + +
    • CallingConv <[actions]> - define each calling convention + that is supported
    • +
    +
    + + + + + +
    +

    During the code + emission stage, the code generator may utilize an LLVM pass to produce assembly + output. To do this, you want to implement the code for a printer that converts + LLVM IR to a GAS-format assembly language for your target machine, using the + following steps:

    +
      +
    • Define all the assembly strings for your target, adding them to + the instructions defined in the XXXInstrInfo.td file. + (See Instruction Set.) + TableGen will produce an output file (XXXGenAsmWriter.inc) with an + implementation of the printInstruction method for the XXXAsmPrinter class.
    • + +
    • Write XXXTargetAsmInfo.h, which contains the bare-bones + declaration of the XXXTargetAsmInfo class (a subclass of TargetAsmInfo).
    • + +
    • Write XXXTargetAsmInfo.cpp, which contains target-specific values + for TargetAsmInfo properties and sometimes new implementations for methods
    • + +
    • Write XXXAsmPrinter.cpp, which implements the AsmPrinter class + that performs the LLVM-to-assembly conversion.
    • +
    + +

    The code in XXXTargetAsmInfo.h is usually a trivial declaration + of the XXXTargetAsmInfo class for use in XXXTargetAsmInfo.cpp. Similarly, + XXXTargetAsmInfo.cpp usually has a few declarations of XXXTargetAsmInfo replacement + values that override the default values in TargetAsmInfo.cpp. For example in + SparcTargetAsmInfo.cpp,

    +
    + +
    +
    SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) {
    +   Data16bitsDirective = "\t.half\t";
    +   Data32bitsDirective = "\t.word\t";
    +   Data64bitsDirective = 0;  // .xword is only supported by V9.
    +   ZeroDirective = "\t.skip\t";
    +   CommentString = "!";
    +   ConstantPoolSection = "\t.section \".rodata\",#alloc\n";
    + }
    + 
    +
    +
    +

    The X86 assembly printer implementation (X86TargetAsmInfo) is an + example where the target specific TargetAsmInfo class uses overridden methods: + ExpandInlineAsm and PreferredEHDataFormat.

    + +

    A target-specific implementation of AsmPrinter is written in + XXXAsmPrinter.cpp, which implements the AsmPrinter class that converts the LLVM + to printable assembly. The implementation must include the following headers + that have declarations for the AsmPrinter and MachineFunctionPass classes. The + MachineFunctionPass is a subclass of FunctionPass.

    +
    + +
    +
    #include "llvm/CodeGen/AsmPrinter.h"
    + #include "llvm/CodeGen/MachineFunctionPass.h" 
    + 
    +
    + +
    +

    As a FunctionPass, AsmPrinter first calls doInitialization to set + up the AsmPrinter. In SparcAsmPrinter, a Mangler object is instantiated to + process variable names.

    + +

    In XXXAsmPrinter.cpp, the runOnMachineFunction method (declared + in MachineFunctionPass) must be implemented for XXXAsmPrinter. In + MachineFunctionPass, the runOnFunction method invokes runOnMachineFunction. + Target-specific implementations of runOnMachineFunction differ, but generally + do the following to process each machine function:

    +
      +
    • call SetupMachineFunction to perform initialization
    • + +
    • call EmitConstantPool to print out (to the output stream) + constants which have been spilled to memory
    • + +
    • call EmitJumpTableInfo to print out jump tables used by the + current function
    • + +
    • print out the label for the current function
    • + +
    • print out the code for the function, including basic block labels + and the assembly for the instruction (using printInstruction)
    • +
    +

    The XXXAsmPrinter implementation must also include the code + generated by TableGen that is output in the XXXGenAsmWriter.inc file. The code + in XXXGenAsmWriter.inc contains an implementation of the printInstruction + method that may call these methods:

    +
      +
    • printOperand
    • + +
    • printMemOperand
    • + +
    • printCCOperand (for conditional statements)
    • + +
    • printDataDirective
    • + +
    • printDeclare
    • + +
    • printImplicitDef
    • + +
    • printInlineAsm
    • + +
    • printLabel
    • + +
    • printPICJumpTableEntry
    • + +
    • printPICJumpTableSetLabel
    • +
    + +

    The implementations of printDeclare, printImplicitDef, + printInlineAsm, and printLabel in AsmPrinter.cpp are generally adequate for + printing assembly and do not need to be overridden. (printBasicBlockLabel is + another method that is implemented in AsmPrinter.cpp that may be directly used + in an implementation of XXXAsmPrinter.)

    + +

    The printOperand method is implemented with a long switch/case + statement for the type of operand: register, immediate, basic block, external + symbol, global address, constant pool index, or jump table index. For an + instruction with a memory address operand, the printMemOperand method should be + implemented to generate the proper output. Similarly, printCCOperand should be + used to print a conditional operand.

    + +

    doFinalization should be overridden in XXXAsmPrinter, and + it should be called to shut down the assembly printer. During doFinalization, + global variables and constants are printed to output.

    +
    + + + + +
    +

    Subtarget support is used to inform the code generation process + of instruction set variations for a given chip set. For example, the LLVM + SPARC implementation provided covers three major versions of the SPARC + microprocessor architecture: Version 8 (V8, which is a 32-bit architecture), + Version 9 (V9, a 64-bit architecture), and the UltraSPARC architecture. V8 has + 16 double-precision floating-point registers that are also usable as either 32 + single-precision or 8 quad-precision registers. V8 is also purely big-endian. V9 + has 32 double-precision floating-point registers that are also usable as 16 + quad-precision registers, but cannot be used as single-precision registers. The + UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set + extensions.

    + +

    If subtarget support is needed, you should implement a + target-specific XXXSubtarget class for your architecture. This class should + process the command-line options –mcpu= and –mattr=

    + +

    TableGen uses definitions in the Target.td and Sparc.td files to + generate code in SparcGenSubtarget.inc. In Target.td, shown below, the + SubtargetFeature interface is defined. The first 4 string parameters of the + SubtargetFeature interface are a feature name, an attribute set by the feature, + the value of the attribute, and a description of the feature. (The fifth + parameter is a list of features whose presence is implied, and its default + value is an empty array.)

    +
    + +
    +
    class SubtargetFeature<string n, string a,  string v, string d,
    +                        list<SubtargetFeature> i = []> {
    +   string Name = n;
    +   string Attribute = a;
    +   string Value = v;
    +   string Desc = d;
    +   list<SubtargetFeature> Implies = i;
    + }
    + 
    +
    +
    +

    In the Sparc.td file, the SubtargetFeature is used to define the + following features.

    +
    + +
    +
    def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true",
    +                      "Enable SPARC-V9 instructions">;
    + def FeatureV8Deprecated : SubtargetFeature<"deprecated-v8", 
    +                      "V8DeprecatedInsts", "true",
    +                      "Enable deprecated V8 instructions in V9 mode">;
    + def FeatureVIS : SubtargetFeature<"vis", "IsVIS", "true",
    +                      "Enable UltraSPARC Visual Instruction Set extensions">;
    + 
    +
    + +
    +

    Elsewhere in Sparc.td, the Proc class is defined and then is used + to define particular SPARC processor subtypes that may have the previously + described features.

    +
    + +
    +
    class Proc<string Name, list<SubtargetFeature> Features>
    +  : Processor<Name, NoItineraries, Features>;
    +  
    + def : Proc<"generic",         []>;
    + def : Proc<"v8",              []>;
    + def : Proc<"supersparc",      []>;
    + def : Proc<"sparclite",       []>;
    + def : Proc<"f934",            []>;
    + def : Proc<"hypersparc",      []>;
    + def : Proc<"sparclite86x",    []>;
    + def : Proc<"sparclet",        []>;
    + def : Proc<"tsc701",          []>;
    + def : Proc<"v9",              [FeatureV9]>;
    + def : Proc<"ultrasparc",      [FeatureV9, FeatureV8Deprecated]>;
    + def : Proc<"ultrasparc3",     [FeatureV9, FeatureV8Deprecated]>;
    + def : Proc<"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]>;
    + 
    +
    + +
    +

    From Target.td and Sparc.td files, the resulting + SparcGenSubtarget.inc specifies enum values to identify the features, arrays of + constants to represent the CPU features and CPU subtypes, and the + ParseSubtargetFeatures method that parses the features string that sets + specified subtarget options. The generated SparcGenSubtarget.inc file should be + included in the SparcSubtarget.cpp. The target-specific implementation of the XXXSubtarget + method should follow this pseudocode:

    +
    + +
    +
    XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) {
    +   // Set the default features
    +   // Determine default and user specified characteristics of the CPU
    +   // Call ParseSubtargetFeatures(FS, CPU) to parse the features string
    +   // Perform any additional operations
    + }
    + 
    +
    + + + + + +
    +

    The implementation of a target machine optionally includes a Just-In-Time + (JIT) code generator that emits machine code and auxiliary structures as binary + output that can be written directly to memory. + To do this, implement JIT code generation by performing the following + steps:

    +
      +
    • Write an XXXCodeEmitter.cpp file that contains a machine function + pass that transforms target-machine instructions into relocatable machine code.
    • + +
    • Write an XXXJITInfo.cpp file that implements the JIT interfaces + for target-specific code-generation + activities, such as emitting machine code and stubs.
    • + +
    • Modify XXXTargetMachine so that it provides a TargetJITInfo + object through its getJITInfo method.
    • +
    + +

    There are several different approaches to writing the JIT support + code. For instance, TableGen and target descriptor files may be used for + creating a JIT code generator, but are not mandatory. For the Alpha and PowerPC + target machines, TableGen is used to generate XXXGenCodeEmitter.inc, which + contains the binary coding of machine instructions and the + getBinaryCodeForInstr method to access those codes. Other JIT implementations + do not.

    + +

    Both XXXJITInfo.cpp and XXXCodeEmitter.cpp must include the + llvm/CodeGen/MachineCodeEmitter.h header file that defines the MachineCodeEmitter + class containing code for several callback functions that write data (in bytes, + words, strings, etc.) to the output stream.

    +
    + + + +
    +

    In XXXCodeEmitter.cpp, a target-specific of the Emitter class is + implemented as a function pass (subclass of MachineFunctionPass). The + target-specific implementation of runOnMachineFunction (invoked by + runOnFunction in MachineFunctionPass) iterates through the MachineBasicBlock + calls emitInstruction to process each instruction and emit binary code. emitInstruction + is largely implemented with case statements on the instruction types defined in + XXXInstrInfo.h. For example, in X86CodeEmitter.cpp, the emitInstruction method + is built around the following switch/case statements:

    +
    + +
    +
    switch (Desc->TSFlags & X86::FormMask) {
    + case X86II::Pseudo:  // for not yet implemented instructions 
    +    ...               // or pseudo-instructions
    +    break;
    + case X86II::RawFrm:  // for instructions with a fixed opcode value
    +    ...
    +    break;
    + case X86II::AddRegFrm: // for instructions that have one register operand 
    +    ...                 // added to their opcode
    +    break;
    + case X86II::MRMDestReg:// for instructions that use the Mod/RM byte
    +    ...                 // to specify a destination (register)
    +    break;
    + case X86II::MRMDestMem:// for instructions that use the Mod/RM byte
    +    ...                 // to specify a destination (memory)
    +    break;
    + case X86II::MRMSrcReg: // for instructions that use the Mod/RM byte
    +    ...                 // to specify a source (register)
    +    break;
    + case X86II::MRMSrcMem: // for instructions that use the Mod/RM byte
    +    ...                 // to specify a source (memory)
    +    break;
    + case X86II::MRM0r: case X86II::MRM1r:  // for instructions that operate on 
    + case X86II::MRM2r: case X86II::MRM3r:  // a REGISTER r/m operand and
    + case X86II::MRM4r: case X86II::MRM5r:  // use the Mod/RM byte and a field
    + case X86II::MRM6r: case X86II::MRM7r:  // to hold extended opcode data
    +    ...  
    +    break;
    + case X86II::MRM0m: case X86II::MRM1m:  // for instructions that operate on
    + case X86II::MRM2m: case X86II::MRM3m:  // a MEMORY r/m operand and
    + case X86II::MRM4m: case X86II::MRM5m:  // use the Mod/RM byte and a field
    + case X86II::MRM6m: case X86II::MRM7m:  // to hold extended opcode data
    +    ...  
    +    break;
    + case X86II::MRMInitReg: // for instructions whose source and
    +    ...                  // destination are the same register
    +    break;
    + }
    + 
    +
    +
    +

    The implementations of these case statements often first emit the + opcode and then get the operand(s). Then depending upon the operand, helper + methods may be called to process the operand(s). For example, in X86CodeEmitter.cpp, + for the X86II::AddRegFrm case, the first data emitted (by emitByte) is the + opcode added to the register operand. Then an object representing the machine + operand, MO1, is extracted. The helper methods such as isImmediate, + isGlobalAddress, isExternalSymbol, isConstantPoolIndex, and + isJumpTableIndex + determine the operand type. (X86CodeEmitter.cpp also has private methods such + as emitConstant, emitGlobalAddress, + emitExternalSymbolAddress, emitConstPoolAddress, + and emitJumpTableAddress that emit the data into the output stream.)

    +
    + +
    +
    case X86II::AddRegFrm:
    +   MCE.emitByte(BaseOpcode + getX86RegNum(MI.getOperand(CurOp++).getReg()));
    +   
    +   if (CurOp != NumOps) {
    +     const MachineOperand &MO1 = MI.getOperand(CurOp++);
    +     unsigned Size = X86InstrInfo::sizeOfImm(Desc);
    +     if (MO1.isImmediate())
    +       emitConstant(MO1.getImm(), Size);
    +     else {
    +       unsigned rt = Is64BitMode ? X86::reloc_pcrel_word
    +         : (IsPIC ? X86::reloc_picrel_word : X86::reloc_absolute_word);
    +       if (Opcode == X86::MOV64ri) 
    +         rt = X86::reloc_absolute_dword;  // FIXME: add X86II flag?
    +       if (MO1.isGlobalAddress()) {
    +         bool NeedStub = isa<Function>(MO1.getGlobal());
    +         bool isLazy = gvNeedsLazyPtr(MO1.getGlobal());
    +         emitGlobalAddress(MO1.getGlobal(), rt, MO1.getOffset(), 0,
    +                           NeedStub, isLazy);
    +       } else if (MO1.isExternalSymbol())
    +         emitExternalSymbolAddress(MO1.getSymbolName(), rt);
    +       else if (MO1.isConstantPoolIndex())
    +         emitConstPoolAddress(MO1.getIndex(), rt);
    +       else if (MO1.isJumpTableIndex())
    +         emitJumpTableAddress(MO1.getIndex(), rt);
    +     }
    +   }
    +   break;
    + 
    +
    +
    +

    In the previous example, XXXCodeEmitter.cpp uses the variable rt, + which is a RelocationType enum that may be used to relocate addresses (for + example, a global address with a PIC base offset). The RelocationType enum for + that target is defined in the short target-specific XXXRelocations.h file. The + RelocationType is used by the relocate method defined in XXXJITInfo.cpp to + rewrite addresses for referenced global symbols.

    + +

    For example, X86Relocations.h specifies the following relocation + types for the X86 addresses. In all four cases, the relocated value is added to + the value already in memory. For reloc_pcrel_word and reloc_picrel_word, + there is an additional initial adjustment.

    +
    + +
    +
    enum RelocationType {
    +   reloc_pcrel_word = 0,  // add reloc value after adjusting for the PC loc
    +   reloc_picrel_word = 1, // add reloc value after adjusting for the PIC base
    +   reloc_absolute_word = 2, // absolute relocation; no additional adjustment 
    +   reloc_absolute_dword = 3 // absolute relocation; no additional adjustment
    + };
    + 
    +
    + + +
    +

    XXXJITInfo.cpp implements the JIT interfaces for target-specific code-generation + activities, such as emitting machine code and stubs. At minimum, + a target-specific version of XXXJITInfo implements the following:

    +
      +
    • getLazyResolverFunction – initializes the JIT, gives the + target a function that is used for compilation
    • + +
    • emitFunctionStub – returns a native function with a + specified address for a callback function
    • + +
    • relocate – changes the addresses of referenced globals, + based on relocation types
    • + +
    • callback function that are wrappers to a function stub that is + used when the real target is not initially known
    • +
    + +

    getLazyResolverFunction is generally trivial to implement. It + makes the incoming parameter as the global JITCompilerFunction and returns the + callback function that will be used a function wrapper. For the Alpha target + (in AlphaJITInfo.cpp), the getLazyResolverFunction implementation is simply:

    +
    + +
    +
    TargetJITInfo::LazyResolverFn AlphaJITInfo::getLazyResolverFunction(  
    +                                             JITCompilerFn F) 
    + {
    +   JITCompilerFunction = F;
    +   return AlphaCompilationCallback;
    + }
    + 
    +
    +
    +

    For the X86 target, the getLazyResolverFunction implementation is + a little more complication, because it returns a different callback function + for processors with SSE instructions and XMM registers.

    + +

    The callback function initially saves and later restores the + callee register values, incoming arguments, and frame and return address. The + callback function needs low-level access to the registers or stack, so it is typically + implemented with assembler.

    +
    + + + +
    +
    + Valid CSS + Valid HTML 4.01 + + Mason Woo and Misha Brukman
    + The LLVM Compiler Infrastructure +
    + Last modified: $Date: 2009/03/03 05:17:36 $ +
    + + + Index: llvm-www/releases/2.5/docs/WritingAnLLVMPass.html diff -c /dev/null llvm-www/releases/2.5/docs/WritingAnLLVMPass.html:1.1 *** /dev/null Mon Mar 2 23:19:10 2009 --- llvm-www/releases/2.5/docs/WritingAnLLVMPass.html Mon Mar 2 23:17:36 2009 *************** *** 0 **** --- 1,1828 ---- + + + + + Writing an LLVM Pass + + + + +
    + Writing an LLVM Pass +
    + +
      +
    1. Introduction - What is a pass?
    2. +
    3. Quick Start - Writing hello world +
    4. +
    5. Pass classes and requirements + +
    6. Pass Registration +
    7. +
    8. Specifying interactions between passes +
    9. +
    10. Implementing Analysis Groups +
    11. +
    12. Pass Statistics +
    13. What PassManager does +
    14. +
    15. Registering dynamically loaded passes +
    16. +
    17. Using GDB with dynamically loaded passes +
    18. +
    19. Future extensions planned +
    20. +
    + +
    +

    Written by Chris Lattner and + Jim Laskey

    +
    + + + + + +
    + +

    The LLVM Pass Framework is an important part of the LLVM system, because LLVM + passes are where most of the interesting parts of the compiler exist. Passes + perform the transformations and optimizations that make up the compiler, they + build the analysis results that are used by these transformations, and they are, + above all, a structuring technique for compiler code.

    + +

    All LLVM passes are subclasses of the Pass + class, which implement functionality by overriding virtual methods inherited + from Pass. Depending on how your pass works, you should inherit from + the ModulePass, CallGraphSCCPass, FunctionPass, or LoopPass, or BasicBlockPass classes, which gives the system + more information about what your pass does, and how it can be combined with + other passes. One of the main features of the LLVM Pass Framework is that it + schedules passes to run in an efficient way based on the constraints that your + pass meets (which are indicated by which class they derive from).

    + +

    We start by showing you how to construct a pass, everything from setting up + the code, to compiling, loading, and executing it. After the basics are down, + more advanced features are discussed.

    + +
    + + + + + +
    + +

    Here we describe how to write the "hello world" of passes. The "Hello" pass + is designed to simply print out the name of non-external functions that exist in + the program being compiled. It does not modify the program at all, it just + inspects it. The source code and files for this pass are available in the LLVM + source tree in the lib/Transforms/Hello directory.

    + +
    + + + + +
    + +

    First, you need to create a new directory somewhere in the LLVM source + base. For this example, we'll assume that you made + lib/Transforms/Hello. Next, you must set up a build script + (Makefile) that will compile the source code for the new pass. To do this, + copy the following into Makefile:

    +
    + +
    + # Makefile for hello pass
    + 
    + # Path to top level of LLVM heirarchy
    + LEVEL = ../../..
    + 
    + # Name of the library to build
    + LIBRARYNAME = Hello
    + 
    + # Make the shared library become a loadable module so the tools can 
    + # dlopen/dlsym on the resulting library.
    + LOADABLE_MODULE = 1
    + 
    + # Tell the build system which LLVM libraries your pass needs. You'll probably
    + # need at least LLVMSystem.a, LLVMSupport.a, LLVMCore.a but possibly several
    + # others too.
    + LLVMLIBS = LLVMCore.a LLVMSupport.a LLVMSystem.a
    + 
    + # Include the makefile implementation stuff
    + include $(LEVEL)/Makefile.common
    + 
    + +

    This makefile specifies that all of the .cpp files in the current + directory are to be compiled and linked together into a + Debug/lib/Hello.so shared object that can be dynamically loaded by + the opt or bugpoint tools via their -load options. + If your operating system uses a suffix other than .so (such as windows or + Mac OS/X), the appropriate extension will be used.

    + +

    Now that we have the build scripts set up, we just need to write the code for + the pass itself.

    + +
    + + + + +
    + +

    Now that we have a way to compile our new pass, we just have to write it. + Start out with:

    + +
    + #include "llvm/Pass.h"
    + #include "llvm/Function.h"
    + 
    + +

    Which are needed because we are writing a Pass, and + we are operating on Function's.

    + +

    Next we have:

    +
    + using namespace llvm;
    + 
    +

    ... which is required because the functions from the include files + live in the llvm namespace. +

    + +

    Next we have:

    + +
    + namespace {
    + 
    + +

    ... which starts out an anonymous namespace. Anonymous namespaces are to C++ + what the "static" keyword is to C (at global scope). It makes the + things declared inside of the anonymous namespace only visible to the current + file. If you're not familiar with them, consult a decent C++ book for more + information.

    + +

    Next, we declare our pass itself:

    + +
    +   struct Hello : public FunctionPass {
    + 

    + +

    This declares a "Hello" class that is a subclass of FunctionPass. + The different builtin pass subclasses are described in detail later, but for now, know that FunctionPass's operate a function at a + time.

    + +
    +      static char ID;
    +      Hello() : FunctionPass((intptr_t)&ID) {}
    + 

    + +

    This declares pass identifier used by LLVM to identify pass. This allows LLVM to + avoid using expensive C++ runtime information.

    + +
    +     virtual bool runOnFunction(Function &F) {
    +       llvm::cerr << "Hello: " << F.getName() << "\n";
    +       return false;
    +     }
    +   };  // end of struct Hello
    + 
    + +

    We declare a "runOnFunction" method, + which overloads an abstract virtual method inherited from FunctionPass. This is where we are supposed + to do our thing, so we just print out our message with the name of each + function.

    + +
    +   char Hello::ID = 0;
    + 
    + +

    We initialize pass ID here. LLVM uses ID's address to identify pass so + initialization value is not important.

    + +
    +   RegisterPass<Hello> X("hello", "Hello World Pass",
    +                         false /* Only looks at CFG */,
    +                         false /* Analysis Pass */);
    + }  // end of anonymous namespace
    + 
    + +

    Lastly, we register our class Hello, + giving it a command line + argument "hello", and a name "Hello World Pass". + Last two RegisterPass arguments are optional. Their default value is false. + If a pass walks CFG without modifying it then third argument is set to true. + If a pass is an analysis pass, for example dominator tree pass, then true + is supplied as fourth argument.

    + +

    As a whole, the .cpp file looks like:

    + +
    + #include "llvm/Pass.h"
    + #include "llvm/Function.h"
    + 
    + using namespace llvm;
    + 
    + namespace {
    +   struct Hello : public FunctionPass {
    +     
    +     static char ID;
    +     Hello() : FunctionPass((intptr_t)&ID) {}
    + 
    +     virtual bool runOnFunction(Function &F) {
    +       llvm::cerr << "Hello: " << F.getName() << "\n";
    +       return false;
    +     }
    +   };
    +   
    +   char Hello::ID = 0;
    +   RegisterPass<Hello> X("hello", "Hello World Pass");
    + }
    + 
    + +

    Now that it's all together, compile the file with a simple "gmake" + command in the local directory and you should get a new + "Debug/lib/Hello.so file. Note that everything in this file is + contained in an anonymous namespace: this reflects the fact that passes are self + contained units that do not need external interfaces (although they can have + them) to be useful.

    + +
    + + + + +
    + +

    Now that you have a brand new shiny shared object file, we can use the + opt command to run an LLVM program through your pass. Because you + registered your pass with the RegisterPass template, you will be able to + use the opt tool to access it, once loaded.

    + +

    To test it, follow the example at the end of the Getting Started Guide to compile "Hello World" to + LLVM. We can now run the bitcode file (hello.bc) for the program + through our transformation like this (or course, any bitcode file will + work):

    + +
    + $ opt -load ../../../Debug/lib/Hello.so -hello < hello.bc > /dev/null
    + Hello: __main
    + Hello: puts
    + Hello: main
    + 
    + +

    The '-load' option specifies that 'opt' should load your + pass as a shared object, which makes '-hello' a valid command line + argument (which is one reason you need to register your + pass). Because the hello pass does not modify the program in any + interesting way, we just throw away the result of opt (sending it to + /dev/null).

    + +

    To see what happened to the other string you registered, try running + opt with the --help option:

    + +
    + $ opt -load ../../../Debug/lib/Hello.so --help
    + OVERVIEW: llvm .bc -> .bc modular optimizer
    + 
    + USAGE: opt [options] <input bitcode>
    + 
    + OPTIONS:
    +   Optimizations available:
    + ...
    +     -funcresolve    - Resolve Functions
    +     -gcse           - Global Common Subexpression Elimination
    +     -globaldce      - Dead Global Elimination
    +     -hello          - Hello World Pass
    +     -indvars        - Canonicalize Induction Variables
    +     -inline         - Function Integration/Inlining
    +     -instcombine    - Combine redundant instructions
    + ...
    + 
    + +

    The pass name get added as the information string for your pass, giving some + documentation to users of opt. Now that you have a working pass, you + would go ahead and make it do the cool transformations you want. Once you get + it all working and tested, it may become useful to find out how fast your pass + is. The PassManager provides a nice command + line option (--time-passes) that allows you to get information about + the execution time of your pass along with the other passes you queue up. For + example:

    + +
    + $ opt -load ../../../Debug/lib/Hello.so -hello -time-passes < hello.bc > /dev/null
    + Hello: __main
    + Hello: puts
    + Hello: main
    + ===============================================================================
    +                       ... Pass execution timing report ...
    + ===============================================================================
    +   Total Execution Time: 0.02 seconds (0.0479059 wall clock)
    + 
    +    ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Pass Name ---
    +    0.0100 (100.0%)   0.0000 (  0.0%)   0.0100 ( 50.0%)   0.0402 ( 84.0%)  Bitcode Writer
    +    0.0000 (  0.0%)   0.0100 (100.0%)   0.0100 ( 50.0%)   0.0031 (  6.4%)  Dominator Set Construction
    +    0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0013 (  2.7%)  Module Verifier
    +    0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0033 (  6.9%)  Hello World Pass
    +    0.0100 (100.0%)   0.0100 (100.0%)   0.0200 (100.0%)   0.0479 (100.0%)  TOTAL
    + 
    + +

    As you can see, our implementation above is pretty fast :). The additional + passes listed are automatically inserted by the 'opt' tool to verify + that the LLVM emitted by your pass is still valid and well formed LLVM, which + hasn't been broken somehow.

    + +

    Now that you have seen the basics of the mechanics behind passes, we can talk + about some more details of how they work and how to use them.

    + +
    + + + + + +
    + +

    One of the first things that you should do when designing a new pass is to + decide what class you should subclass for your pass. The Hello World example uses the FunctionPass class for its implementation, but we + did not discuss why or when this should occur. Here we talk about the classes + available, from the most general