[www-releases] r208244 - Add source, binaries, and documentation for 3.4.1 release

Tom Stellard thomas.stellard at amd.com
Wed May 7 13:09:36 PDT 2014


Author: tstellar
Date: Wed May  7 15:09:32 2014
New Revision: 208244

URL: http://llvm.org/viewvc/llvm-project?rev=208244&view=rev
Log:
Add source, binaries, and documentation for 3.4.1 release

Added:
    www-releases/trunk/3.4.1/
    www-releases/trunk/3.4.1/LICENSE.TXT
    www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe   (with props)
    www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe.sig   (with props)
    www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz   (with props)
    www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz.sig   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-i586-opensuse13.1.tar.xz   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-i586-opensuse13.1.tar.xz.sig   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-i686-fedora20.tar.xz   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-i686-fedora20.tar.xz.sig   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-apple-darwin10.9.tar.xz   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-apple-darwin10.9.tar.xz.sig   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-fedora20.tar.xz   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-fedora20.tar.xz.sig   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-opensuse13.1.tar.xz   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-opensuse13.1.tar.xz.sig   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz   (with props)
    www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz.sig   (with props)
    www-releases/trunk/3.4.1/docs/
    www-releases/trunk/3.4.1/docs/AliasAnalysis.html
    www-releases/trunk/3.4.1/docs/Atomics.html
    www-releases/trunk/3.4.1/docs/BitCodeFormat.html
    www-releases/trunk/3.4.1/docs/BranchWeightMetadata.html
    www-releases/trunk/3.4.1/docs/Bugpoint.html
    www-releases/trunk/3.4.1/docs/CMake.html
    www-releases/trunk/3.4.1/docs/CodeGenerator.html
    www-releases/trunk/3.4.1/docs/CodingStandards.html
    www-releases/trunk/3.4.1/docs/CommandGuide/
    www-releases/trunk/3.4.1/docs/CommandGuide/FileCheck.html
    www-releases/trunk/3.4.1/docs/CommandGuide/bugpoint.html
    www-releases/trunk/3.4.1/docs/CommandGuide/index.html
    www-releases/trunk/3.4.1/docs/CommandGuide/lit.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llc.html
    www-releases/trunk/3.4.1/docs/CommandGuide/lli.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-ar.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-as.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-bcanalyzer.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-build.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-config.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-cov.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-diff.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-dis.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-extract.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-link.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-nm.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-prof.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-readobj.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-stress.html
    www-releases/trunk/3.4.1/docs/CommandGuide/llvm-symbolizer.html
    www-releases/trunk/3.4.1/docs/CommandGuide/opt.html
    www-releases/trunk/3.4.1/docs/CommandGuide/tblgen.html
    www-releases/trunk/3.4.1/docs/CommandLine.html
    www-releases/trunk/3.4.1/docs/CompilerWriterInfo.html
    www-releases/trunk/3.4.1/docs/DebuggingJITedCode.html
    www-releases/trunk/3.4.1/docs/DeveloperPolicy.html
    www-releases/trunk/3.4.1/docs/ExceptionHandling.html
    www-releases/trunk/3.4.1/docs/ExtendingLLVM.html
    www-releases/trunk/3.4.1/docs/Extensions.html
    www-releases/trunk/3.4.1/docs/FAQ.html
    www-releases/trunk/3.4.1/docs/GarbageCollection.html
    www-releases/trunk/3.4.1/docs/GetElementPtr.html
    www-releases/trunk/3.4.1/docs/GettingStarted.html
    www-releases/trunk/3.4.1/docs/GettingStartedVS.html
    www-releases/trunk/3.4.1/docs/GoldPlugin.html
    www-releases/trunk/3.4.1/docs/HowToAddABuilder.html
    www-releases/trunk/3.4.1/docs/HowToBuildOnARM.html
    www-releases/trunk/3.4.1/docs/HowToCrossCompileLLVM.html
    www-releases/trunk/3.4.1/docs/HowToReleaseLLVM.html
    www-releases/trunk/3.4.1/docs/HowToSetUpLLVMStyleRTTI.html
    www-releases/trunk/3.4.1/docs/HowToSubmitABug.html
    www-releases/trunk/3.4.1/docs/HowToUseAttributes.html
    www-releases/trunk/3.4.1/docs/HowToUseInstrMappings.html
    www-releases/trunk/3.4.1/docs/LLVMBuild.html
    www-releases/trunk/3.4.1/docs/LangRef.html
    www-releases/trunk/3.4.1/docs/Lexicon.html
    www-releases/trunk/3.4.1/docs/LinkTimeOptimization.html
    www-releases/trunk/3.4.1/docs/MCJITDesignAndImplementation.html
    www-releases/trunk/3.4.1/docs/MakefileGuide.html
    www-releases/trunk/3.4.1/docs/MarkedUpDisassembly.html
    www-releases/trunk/3.4.1/docs/NVPTXUsage.html
    www-releases/trunk/3.4.1/docs/Packaging.html
    www-releases/trunk/3.4.1/docs/Passes.html
    www-releases/trunk/3.4.1/docs/Phabricator.html
    www-releases/trunk/3.4.1/docs/ProgrammersManual.html
    www-releases/trunk/3.4.1/docs/Projects.html
    www-releases/trunk/3.4.1/docs/ReleaseNotes.html
    www-releases/trunk/3.4.1/docs/ReleaseProcess.html
    www-releases/trunk/3.4.1/docs/SegmentedStacks.html
    www-releases/trunk/3.4.1/docs/SourceLevelDebugging.html
    www-releases/trunk/3.4.1/docs/SphinxQuickstartTemplate.html
    www-releases/trunk/3.4.1/docs/SystemLibrary.html
    www-releases/trunk/3.4.1/docs/TableGen/
    www-releases/trunk/3.4.1/docs/TableGen/LangRef.html
    www-releases/trunk/3.4.1/docs/TableGenFundamentals.html
    www-releases/trunk/3.4.1/docs/TestSuiteMakefileGuide.html
    www-releases/trunk/3.4.1/docs/TestingGuide.html
    www-releases/trunk/3.4.1/docs/Vectorizers.html
    www-releases/trunk/3.4.1/docs/WritingAnLLVMBackend.html
    www-releases/trunk/3.4.1/docs/WritingAnLLVMPass.html
    www-releases/trunk/3.4.1/docs/YamlIO.html
    www-releases/trunk/3.4.1/docs/_images/
    www-releases/trunk/3.4.1/docs/_images/LangImpl5-cfg.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/MCJIT-creation.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/MCJIT-dyld-load.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/MCJIT-engine-builder.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/MCJIT-load-object.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/MCJIT-load.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/MCJIT-resolve-relocations.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/gcc-loops.png   (with props)
    www-releases/trunk/3.4.1/docs/_images/linpack-pc.png   (with props)
    www-releases/trunk/3.4.1/docs/_sources/
    www-releases/trunk/3.4.1/docs/_sources/AliasAnalysis.txt
    www-releases/trunk/3.4.1/docs/_sources/Atomics.txt
    www-releases/trunk/3.4.1/docs/_sources/BitCodeFormat.txt
    www-releases/trunk/3.4.1/docs/_sources/BranchWeightMetadata.txt
    www-releases/trunk/3.4.1/docs/_sources/Bugpoint.txt
    www-releases/trunk/3.4.1/docs/_sources/CMake.txt
    www-releases/trunk/3.4.1/docs/_sources/CodeGenerator.txt
    www-releases/trunk/3.4.1/docs/_sources/CodingStandards.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/FileCheck.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/bugpoint.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/index.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/lit.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llc.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/lli.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-ar.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-as.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-bcanalyzer.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-build.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-config.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-cov.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-diff.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-dis.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-extract.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-link.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-nm.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-prof.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-readobj.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-stress.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/llvm-symbolizer.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/opt.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandGuide/tblgen.txt
    www-releases/trunk/3.4.1/docs/_sources/CommandLine.txt
    www-releases/trunk/3.4.1/docs/_sources/CompilerWriterInfo.txt
    www-releases/trunk/3.4.1/docs/_sources/DebuggingJITedCode.txt
    www-releases/trunk/3.4.1/docs/_sources/DeveloperPolicy.txt
    www-releases/trunk/3.4.1/docs/_sources/ExceptionHandling.txt
    www-releases/trunk/3.4.1/docs/_sources/ExtendingLLVM.txt
    www-releases/trunk/3.4.1/docs/_sources/Extensions.txt
    www-releases/trunk/3.4.1/docs/_sources/FAQ.txt
    www-releases/trunk/3.4.1/docs/_sources/GarbageCollection.txt
    www-releases/trunk/3.4.1/docs/_sources/GetElementPtr.txt
    www-releases/trunk/3.4.1/docs/_sources/GettingStarted.txt
    www-releases/trunk/3.4.1/docs/_sources/GettingStartedVS.txt
    www-releases/trunk/3.4.1/docs/_sources/GoldPlugin.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToAddABuilder.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToBuildOnARM.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToCrossCompileLLVM.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToReleaseLLVM.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToSetUpLLVMStyleRTTI.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToSubmitABug.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToUseAttributes.txt
    www-releases/trunk/3.4.1/docs/_sources/HowToUseInstrMappings.txt
    www-releases/trunk/3.4.1/docs/_sources/LLVMBuild.txt
    www-releases/trunk/3.4.1/docs/_sources/LangRef.txt
    www-releases/trunk/3.4.1/docs/_sources/Lexicon.txt
    www-releases/trunk/3.4.1/docs/_sources/LinkTimeOptimization.txt
    www-releases/trunk/3.4.1/docs/_sources/MCJITDesignAndImplementation.txt
    www-releases/trunk/3.4.1/docs/_sources/MakefileGuide.txt
    www-releases/trunk/3.4.1/docs/_sources/MarkedUpDisassembly.txt
    www-releases/trunk/3.4.1/docs/_sources/NVPTXUsage.txt
    www-releases/trunk/3.4.1/docs/_sources/Packaging.txt
    www-releases/trunk/3.4.1/docs/_sources/Passes.txt
    www-releases/trunk/3.4.1/docs/_sources/Phabricator.txt
    www-releases/trunk/3.4.1/docs/_sources/ProgrammersManual.txt
    www-releases/trunk/3.4.1/docs/_sources/Projects.txt
    www-releases/trunk/3.4.1/docs/_sources/ReleaseNotes.txt
    www-releases/trunk/3.4.1/docs/_sources/ReleaseProcess.txt
    www-releases/trunk/3.4.1/docs/_sources/SegmentedStacks.txt
    www-releases/trunk/3.4.1/docs/_sources/SourceLevelDebugging.txt
    www-releases/trunk/3.4.1/docs/_sources/SphinxQuickstartTemplate.txt
    www-releases/trunk/3.4.1/docs/_sources/SystemLibrary.txt
    www-releases/trunk/3.4.1/docs/_sources/TableGen/
    www-releases/trunk/3.4.1/docs/_sources/TableGen/LangRef.txt
    www-releases/trunk/3.4.1/docs/_sources/TableGenFundamentals.txt
    www-releases/trunk/3.4.1/docs/_sources/TestSuiteMakefileGuide.txt
    www-releases/trunk/3.4.1/docs/_sources/TestingGuide.txt
    www-releases/trunk/3.4.1/docs/_sources/Vectorizers.txt
    www-releases/trunk/3.4.1/docs/_sources/WritingAnLLVMBackend.txt
    www-releases/trunk/3.4.1/docs/_sources/WritingAnLLVMPass.txt
    www-releases/trunk/3.4.1/docs/_sources/YamlIO.txt
    www-releases/trunk/3.4.1/docs/_sources/index.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl1.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl2.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl3.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl4.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl5.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl6.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl7.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/LangImpl8.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl1.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl2.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl3.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl4.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl5.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl6.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl7.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/OCamlLangImpl8.txt
    www-releases/trunk/3.4.1/docs/_sources/tutorial/index.txt
    www-releases/trunk/3.4.1/docs/_sources/yaml2obj.txt
    www-releases/trunk/3.4.1/docs/_static/
    www-releases/trunk/3.4.1/docs/_static/ajax-loader.gif   (with props)
    www-releases/trunk/3.4.1/docs/_static/basic.css
    www-releases/trunk/3.4.1/docs/_static/comment-bright.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/comment-close.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/comment.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/contents.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/doctools.js
    www-releases/trunk/3.4.1/docs/_static/down-pressed.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/down.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/file.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/jquery.js
    www-releases/trunk/3.4.1/docs/_static/lines.gif   (with props)
    www-releases/trunk/3.4.1/docs/_static/llvm-theme.css
    www-releases/trunk/3.4.1/docs/_static/llvm.css
    www-releases/trunk/3.4.1/docs/_static/logo.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/minus.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/navigation.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/plus.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/pygments.css
    www-releases/trunk/3.4.1/docs/_static/searchtools.js
    www-releases/trunk/3.4.1/docs/_static/underscore.js
    www-releases/trunk/3.4.1/docs/_static/up-pressed.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/up.png   (with props)
    www-releases/trunk/3.4.1/docs/_static/websupport.js
    www-releases/trunk/3.4.1/docs/genindex.html
    www-releases/trunk/3.4.1/docs/index.html
    www-releases/trunk/3.4.1/docs/objects.inv   (with props)
    www-releases/trunk/3.4.1/docs/search.html
    www-releases/trunk/3.4.1/docs/searchindex.js
    www-releases/trunk/3.4.1/docs/tutorial/
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl1.html
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl2.html
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl3.html
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl4.html
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl5.html
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl6.html
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl7.html
    www-releases/trunk/3.4.1/docs/tutorial/LangImpl8.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl1.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl2.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl3.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl4.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl5.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl6.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl7.html
    www-releases/trunk/3.4.1/docs/tutorial/OCamlLangImpl8.html
    www-releases/trunk/3.4.1/docs/tutorial/index.html
    www-releases/trunk/3.4.1/docs/yaml2obj.html
    www-releases/trunk/3.4.1/index.html
    www-releases/trunk/3.4.1/llvm-3.4.1.src.tar.gz   (with props)
    www-releases/trunk/3.4.1/llvm-3.4.1.src.tar.gz.sig   (with props)
    www-releases/trunk/3.4.1/tools/
    www-releases/trunk/3.4.1/tools/clang/
    www-releases/trunk/3.4.1/tools/clang/docs/
    www-releases/trunk/3.4.1/tools/clang/docs/AddressSanitizer.html
    www-releases/trunk/3.4.1/tools/clang/docs/AutomaticReferenceCounting.html
    www-releases/trunk/3.4.1/tools/clang/docs/Block-ABI-Apple.html
    www-releases/trunk/3.4.1/tools/clang/docs/Block-ABI-Apple.txt
    www-releases/trunk/3.4.1/tools/clang/docs/BlockLanguageSpec.html
    www-releases/trunk/3.4.1/tools/clang/docs/ClangCheck.html
    www-releases/trunk/3.4.1/tools/clang/docs/ClangFormat.html
    www-releases/trunk/3.4.1/tools/clang/docs/ClangFormatStyleOptions.html
    www-releases/trunk/3.4.1/tools/clang/docs/ClangPlugins.html
    www-releases/trunk/3.4.1/tools/clang/docs/ClangTools.html
    www-releases/trunk/3.4.1/tools/clang/docs/CrossCompilation.html
    www-releases/trunk/3.4.1/tools/clang/docs/DataFlowSanitizer.html
    www-releases/trunk/3.4.1/tools/clang/docs/DataFlowSanitizerDesign.html
    www-releases/trunk/3.4.1/tools/clang/docs/DriverInternals.html
    www-releases/trunk/3.4.1/tools/clang/docs/ExternalClangExamples.html
    www-releases/trunk/3.4.1/tools/clang/docs/FAQ.html
    www-releases/trunk/3.4.1/tools/clang/docs/HowToSetupToolingForLLVM.html
    www-releases/trunk/3.4.1/tools/clang/docs/InternalsManual.html
    www-releases/trunk/3.4.1/tools/clang/docs/IntroductionToTheClangAST.html
    www-releases/trunk/3.4.1/tools/clang/docs/JSONCompilationDatabase.html
    www-releases/trunk/3.4.1/tools/clang/docs/LanguageExtensions.html
    www-releases/trunk/3.4.1/tools/clang/docs/LeakSanitizer.html
    www-releases/trunk/3.4.1/tools/clang/docs/LibASTMatchers.html
    www-releases/trunk/3.4.1/tools/clang/docs/LibASTMatchersReference.html
    www-releases/trunk/3.4.1/tools/clang/docs/LibASTMatchersTutorial.html
    www-releases/trunk/3.4.1/tools/clang/docs/LibFormat.html
    www-releases/trunk/3.4.1/tools/clang/docs/LibTooling.html
    www-releases/trunk/3.4.1/tools/clang/docs/MemorySanitizer.html
    www-releases/trunk/3.4.1/tools/clang/docs/Modules.html
    www-releases/trunk/3.4.1/tools/clang/docs/ObjectiveCLiterals.html
    www-releases/trunk/3.4.1/tools/clang/docs/PCHInternals.html
    www-releases/trunk/3.4.1/tools/clang/docs/PTHInternals.html
    www-releases/trunk/3.4.1/tools/clang/docs/RAVFrontendAction.html
    www-releases/trunk/3.4.1/tools/clang/docs/ReleaseNotes.html
    www-releases/trunk/3.4.1/tools/clang/docs/SanitizerSpecialCaseList.html
    www-releases/trunk/3.4.1/tools/clang/docs/ThreadSanitizer.html
    www-releases/trunk/3.4.1/tools/clang/docs/Tooling.html
    www-releases/trunk/3.4.1/tools/clang/docs/UsersManual.html
    www-releases/trunk/3.4.1/tools/clang/docs/_images/
    www-releases/trunk/3.4.1/tools/clang/docs/_images/DriverArchitecture.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_images/PCHLayout.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/AddressSanitizer.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/AutomaticReferenceCounting.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/Block-ABI-Apple.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/BlockLanguageSpec.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ClangCheck.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ClangFormat.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ClangFormatStyleOptions.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ClangPlugins.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ClangTools.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/CrossCompilation.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/DataFlowSanitizer.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/DataFlowSanitizerDesign.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/DriverInternals.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ExternalClangExamples.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/FAQ.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/HowToSetupToolingForLLVM.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/InternalsManual.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/IntroductionToTheClangAST.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/JSONCompilationDatabase.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/LanguageExtensions.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/LeakSanitizer.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/LibASTMatchers.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/LibASTMatchersTutorial.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/LibFormat.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/LibTooling.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/MemorySanitizer.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/Modules.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ObjectiveCLiterals.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/PCHInternals.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/PTHInternals.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/RAVFrontendAction.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ReleaseNotes.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/SanitizerSpecialCaseList.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/ThreadSanitizer.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/Tooling.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/UsersManual.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_sources/index.txt
    www-releases/trunk/3.4.1/tools/clang/docs/_static/
    www-releases/trunk/3.4.1/tools/clang/docs/_static/ajax-loader.gif   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/alert_info_32.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/alert_warning_32.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/basic.css
    www-releases/trunk/3.4.1/tools/clang/docs/_static/bg-page.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/bullet_orange.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/comment-bright.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/comment-close.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/comment.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/doctools.js
    www-releases/trunk/3.4.1/tools/clang/docs/_static/down-pressed.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/down.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/file.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/haiku.css
    www-releases/trunk/3.4.1/tools/clang/docs/_static/jquery.js
    www-releases/trunk/3.4.1/tools/clang/docs/_static/minus.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/plus.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/pygments.css
    www-releases/trunk/3.4.1/tools/clang/docs/_static/searchtools.js
    www-releases/trunk/3.4.1/tools/clang/docs/_static/underscore.js
    www-releases/trunk/3.4.1/tools/clang/docs/_static/up-pressed.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/up.png   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/_static/websupport.js
    www-releases/trunk/3.4.1/tools/clang/docs/genindex.html
    www-releases/trunk/3.4.1/tools/clang/docs/index.html
    www-releases/trunk/3.4.1/tools/clang/docs/objects.inv   (with props)
    www-releases/trunk/3.4.1/tools/clang/docs/search.html
    www-releases/trunk/3.4.1/tools/clang/docs/searchindex.js
Modified:
    www-releases/trunk/download.html
    www-releases/trunk/index.html

Added: www-releases/trunk/3.4.1/LICENSE.TXT
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/LICENSE.TXT?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/LICENSE.TXT (added)
+++ www-releases/trunk/3.4.1/LICENSE.TXT Wed May  7 15:09:32 2014
@@ -0,0 +1,71 @@
+==============================================================================
+LLVM Release License
+==============================================================================
+University of Illinois/NCSA
+Open Source License
+
+Copyright (c) 2003-2013 University of Illinois at Urbana-Champaign.
+All rights reserved.
+
+Developed by:
+
+    LLVM Team
+
+    University of Illinois at Urbana-Champaign
+
+    http://llvm.org
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal with
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
+of the Software, and to permit persons to whom the Software is furnished to do
+so, subject to the following conditions:
+
+    * Redistributions of source code must retain the above copyright notice,
+      this list of conditions and the following disclaimers.
+
+    * Redistributions in binary form must reproduce the above copyright notice,
+      this list of conditions and the following disclaimers in the
+      documentation and/or other materials provided with the distribution.
+
+    * Neither the names of the LLVM Team, University of Illinois at
+      Urbana-Champaign, nor the names of its contributors may be used to
+      endorse or promote products derived from this Software without specific
+      prior written permission.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
+CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
+SOFTWARE.
+
+==============================================================================
+Copyrights and Licenses for Third Party Software Distributed with LLVM:
+==============================================================================
+The LLVM software contains code written by third parties.  Such software will
+have its own individual LICENSE.TXT file in the directory in which it appears.
+This file will describe the copyrights, license, and restrictions which apply
+to that code.
+
+The disclaimer of warranty in the University of Illinois Open Source License
+applies to all code in the LLVM Distribution, and nothing in any of the
+other licenses gives permission to use the names of the LLVM Team or the
+University of Illinois to endorse or promote products derived from this
+Software.
+
+The following pieces of software have additional or alternate copyrights,
+licenses, and/or restrictions:
+
+Program             Directory
+-------             ---------
+Autoconf            llvm/autoconf
+                    llvm/projects/ModuleMaker/autoconf
+                    llvm/projects/sample/autoconf
+Google Test         llvm/utils/unittest/googletest
+OpenBSD regex       llvm/lib/Support/{reg*, COPYRIGHT.regex}
+pyyaml tests        llvm/test/YAMLParser/{*.data, LICENSE.TXT}
+ARM contributions   llvm/lib/Target/ARM/LICENSE.TXT
+md5 contributions   llvm/lib/Support/MD5.cpp llvm/include/llvm/Support/MD5.h

Added: www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe
------------------------------------------------------------------------------
    svn:executable = *

Propchange: www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe
------------------------------------------------------------------------------
    svn:mime-type = application/x-dosexec

Added: www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/LLVM-3.4.1-win32.exe.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz
------------------------------------------------------------------------------
    svn:mime-type = application/x-gzip

Added: www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/cfe-3.4.1.src.tar.gz.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i586-opensuse13.1.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-i586-opensuse13.1.tar.xz?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i586-opensuse13.1.tar.xz
------------------------------------------------------------------------------
    svn:mime-type = application/x-xz

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i586-opensuse13.1.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-i586-opensuse13.1.tar.xz.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i586-opensuse13.1.tar.xz.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i686-fedora20.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-i686-fedora20.tar.xz?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i686-fedora20.tar.xz
------------------------------------------------------------------------------
    svn:mime-type = application/x-xz

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i686-fedora20.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-i686-fedora20.tar.xz.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-i686-fedora20.tar.xz.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-apple-darwin10.9.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-apple-darwin10.9.tar.xz?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-apple-darwin10.9.tar.xz
------------------------------------------------------------------------------
    svn:mime-type = application/x-xz

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-apple-darwin10.9.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-apple-darwin10.9.tar.xz.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-apple-darwin10.9.tar.xz.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-fedora20.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-fedora20.tar.xz?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-fedora20.tar.xz
------------------------------------------------------------------------------
    svn:mime-type = application/x-xz

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-fedora20.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-fedora20.tar.xz.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-fedora20.tar.xz.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-opensuse13.1.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-opensuse13.1.tar.xz?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-opensuse13.1.tar.xz
------------------------------------------------------------------------------
    svn:mime-type = application/x-xz

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-opensuse13.1.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-opensuse13.1.tar.xz.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-opensuse13.1.tar.xz.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz
------------------------------------------------------------------------------
    svn:mime-type = application/x-xz

Added: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/clang%2Bllvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz.sig?rev=208244&view=auto
==============================================================================
Binary file - no diff available.

Propchange: www-releases/trunk/3.4.1/clang+llvm-3.4.1-x86_64-unknown-ubuntu12.04.tar.xz.sig
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: www-releases/trunk/3.4.1/docs/AliasAnalysis.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/AliasAnalysis.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/AliasAnalysis.html (added)
+++ www-releases/trunk/3.4.1/docs/AliasAnalysis.html Wed May  7 15:09:32 2014
@@ -0,0 +1,754 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>LLVM Alias Analysis Infrastructure — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="LLVM Bitcode File Format" href="BitCodeFormat.html" />
+    <link rel="prev" title="LLVM Extensions" href="Extensions.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="BitCodeFormat.html" title="LLVM Bitcode File Format"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="Extensions.html" title="LLVM Extensions"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-alias-analysis-infrastructure">
+<h1>LLVM Alias Analysis Infrastructure<a class="headerlink" href="#llvm-alias-analysis-infrastructure" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#aliasanalysis-class-overview" id="id2"><tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> Class Overview</a><ul>
+<li><a class="reference internal" href="#representation-of-pointers" id="id3">Representation of Pointers</a></li>
+<li><a class="reference internal" href="#the-alias-method" id="id4">The <tt class="docutils literal"><span class="pre">alias</span></tt> method</a><ul>
+<li><a class="reference internal" href="#must-may-and-no-alias-responses" id="id5">Must, May, and No Alias Responses</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-getmodrefinfo-methods" id="id6">The <tt class="docutils literal"><span class="pre">getModRefInfo</span></tt> methods</a></li>
+<li><a class="reference internal" href="#other-useful-aliasanalysis-methods" id="id7">Other useful <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> methods</a><ul>
+<li><a class="reference internal" href="#the-pointstoconstantmemory-method" id="id8">The <tt class="docutils literal"><span class="pre">pointsToConstantMemory</span></tt> method</a></li>
+<li><a class="reference internal" href="#the-doesnotaccessmemory-and-onlyreadsmemory-methods" id="id9">The <tt class="docutils literal"><span class="pre">doesNotAccessMemory</span></tt> and  <tt class="docutils literal"><span class="pre">onlyReadsMemory</span></tt> methods</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#writing-a-new-aliasanalysis-implementation" id="id10">Writing a new <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> Implementation</a><ul>
+<li><a class="reference internal" href="#different-pass-styles" id="id11">Different Pass styles</a></li>
+<li><a class="reference internal" href="#required-initialization-calls" id="id12">Required initialization calls</a></li>
+<li><a class="reference internal" href="#interfaces-which-may-be-specified" id="id13">Interfaces which may be specified</a></li>
+<li><a class="reference internal" href="#aliasanalysis-chaining-behavior" id="id14"><tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> chaining behavior</a></li>
+<li><a class="reference internal" href="#updating-analysis-results-for-transformations" id="id15">Updating analysis results for transformations</a><ul>
+<li><a class="reference internal" href="#the-deletevalue-method" id="id16">The <tt class="docutils literal"><span class="pre">deleteValue</span></tt> method</a></li>
+<li><a class="reference internal" href="#the-copyvalue-method" id="id17">The <tt class="docutils literal"><span class="pre">copyValue</span></tt> method</a></li>
+<li><a class="reference internal" href="#the-replacewithnewvalue-method" id="id18">The <tt class="docutils literal"><span class="pre">replaceWithNewValue</span></tt> method</a></li>
+<li><a class="reference internal" href="#the-addescapinguse-method" id="id19">The <tt class="docutils literal"><span class="pre">addEscapingUse</span></tt> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#efficiency-issues" id="id20">Efficiency Issues</a></li>
+<li><a class="reference internal" href="#limitations" id="id21">Limitations</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#using-alias-analysis-results" id="id22">Using alias analysis results</a><ul>
+<li><a class="reference internal" href="#using-the-memorydependenceanalysis-pass" id="id23">Using the <tt class="docutils literal"><span class="pre">MemoryDependenceAnalysis</span></tt> Pass</a></li>
+<li><a class="reference internal" href="#using-the-aliassettracker-class" id="id24">Using the <tt class="docutils literal"><span class="pre">AliasSetTracker</span></tt> class</a><ul>
+<li><a class="reference internal" href="#the-aliassettracker-implementation" id="id25">The AliasSetTracker implementation</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#using-the-aliasanalysis-interface-directly" id="id26">Using the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface directly</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#existing-alias-analysis-implementations-and-clients" id="id27">Existing alias analysis implementations and clients</a><ul>
+<li><a class="reference internal" href="#available-aliasanalysis-implementations" id="id28">Available <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> implementations</a><ul>
+<li><a class="reference internal" href="#the-no-aa-pass" id="id29">The <tt class="docutils literal"><span class="pre">-no-aa</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-basicaa-pass" id="id30">The <tt class="docutils literal"><span class="pre">-basicaa</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-globalsmodref-aa-pass" id="id31">The <tt class="docutils literal"><span class="pre">-globalsmodref-aa</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-steens-aa-pass" id="id32">The <tt class="docutils literal"><span class="pre">-steens-aa</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-ds-aa-pass" id="id33">The <tt class="docutils literal"><span class="pre">-ds-aa</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-scev-aa-pass" id="id34">The <tt class="docutils literal"><span class="pre">-scev-aa</span></tt> pass</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#alias-analysis-driven-transformations" id="id35">Alias analysis driven transformations</a><ul>
+<li><a class="reference internal" href="#the-adce-pass" id="id36">The <tt class="docutils literal"><span class="pre">-adce</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-licm-pass" id="id37">The <tt class="docutils literal"><span class="pre">-licm</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-argpromotion-pass" id="id38">The <tt class="docutils literal"><span class="pre">-argpromotion</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-gvn-memcpyopt-and-dse-passes" id="id39">The <tt class="docutils literal"><span class="pre">-gvn</span></tt>, <tt class="docutils literal"><span class="pre">-memcpyopt</span></tt>, and <tt class="docutils literal"><span class="pre">-dse</span></tt> passes</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#clients-for-debugging-and-evaluation-of-implementations" id="id40">Clients for debugging and evaluation of implementations</a><ul>
+<li><a class="reference internal" href="#the-print-alias-sets-pass" id="id41">The <tt class="docutils literal"><span class="pre">-print-alias-sets</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-count-aa-pass" id="id42">The <tt class="docutils literal"><span class="pre">-count-aa</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-aa-eval-pass" id="id43">The <tt class="docutils literal"><span class="pre">-aa-eval</span></tt> pass</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#memory-dependence-analysis" id="id44">Memory Dependence Analysis</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>Alias Analysis (aka Pointer Analysis) is a class of techniques which attempt to
+determine whether or not two pointers ever can point to the same object in
+memory.  There are many different algorithms for alias analysis and many
+different ways of classifying them: flow-sensitive vs. flow-insensitive,
+context-sensitive vs. context-insensitive, field-sensitive
+vs. field-insensitive, unification-based vs. subset-based, etc.  Traditionally,
+alias analyses respond to a query with a <a class="reference internal" href="#must-may-or-no">Must, May, or No</a> alias response,
+indicating that two pointers always point to the same object, might point to the
+same object, or are known to never point to the same object.</p>
+<p>The LLVM <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a> class is the
+primary interface used by clients and implementations of alias analyses in the
+LLVM system.  This class is the common interface between clients of alias
+analysis information and the implementations providing it, and is designed to
+support a wide range of implementations and clients (but currently all clients
+are assumed to be flow-insensitive).  In addition to simple alias analysis
+information, this class exposes Mod/Ref information from those implementations
+which can provide it, allowing for powerful analyses and transformations to work
+well together.</p>
+<p>This document contains information necessary to successfully implement this
+interface, use it, and to test both sides.  It also explains some of the finer
+points about what exactly results mean.  If you feel that something is unclear
+or should be added, please <a class="reference external" href="mailto:sabre%40nondot.org">let me know</a>.</p>
+</div>
+<div class="section" id="aliasanalysis-class-overview">
+<h2><a class="toc-backref" href="#id2"><tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> Class Overview</a><a class="headerlink" href="#aliasanalysis-class-overview" title="Permalink to this headline">¶</a></h2>
+<p>The <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>
+class defines the interface that the various alias analysis implementations
+should support.  This class exports two important enums: <tt class="docutils literal"><span class="pre">AliasResult</span></tt> and
+<tt class="docutils literal"><span class="pre">ModRefResult</span></tt> which represent the result of an alias query or a mod/ref
+query, respectively.</p>
+<p>The <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface exposes information about memory, represented in
+several different ways.  In particular, memory objects are represented as a
+starting address and size, and function calls are represented as the actual
+<tt class="docutils literal"><span class="pre">call</span></tt> or <tt class="docutils literal"><span class="pre">invoke</span></tt> instructions that performs the call.  The
+<tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface also exposes some helper methods which allow you to
+get mod/ref information for arbitrary instructions.</p>
+<p>All <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interfaces require that in queries involving multiple
+values, values which are not <a class="reference external" href="LangRef.html#constants">constants</a> are all
+defined within the same function.</p>
+<div class="section" id="representation-of-pointers">
+<h3><a class="toc-backref" href="#id3">Representation of Pointers</a><a class="headerlink" href="#representation-of-pointers" title="Permalink to this headline">¶</a></h3>
+<p>Most importantly, the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> class provides several methods which are
+used to query whether or not two memory objects alias, whether function calls
+can modify or read a memory object, etc.  For all of these queries, memory
+objects are represented as a pair of their starting address (a symbolic LLVM
+<tt class="docutils literal"><span class="pre">Value*</span></tt>) and a static size.</p>
+<p>Representing memory objects as a starting address and a size is critically
+important for correct Alias Analyses.  For example, consider this (silly, but
+possible) C code:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">i</span><span class="p">;</span>
+<span class="kt">char</span> <span class="n">C</span><span class="p">[</span><span class="mi">2</span><span class="p">];</span>
+<span class="kt">char</span> <span class="n">A</span><span class="p">[</span><span class="mi">10</span><span class="p">];</span>
+<span class="cm">/* ... */</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o">!=</span> <span class="mi">10</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span> <span class="p">{</span>
+  <span class="n">C</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="o">=</span> <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">];</span>          <span class="cm">/* One byte store */</span>
+  <span class="n">C</span><span class="p">[</span><span class="mi">1</span><span class="p">]</span> <span class="o">=</span> <span class="n">A</span><span class="p">[</span><span class="mi">9</span><span class="o">-</span><span class="n">i</span><span class="p">];</span>        <span class="cm">/* One byte store */</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In this case, the <tt class="docutils literal"><span class="pre">basicaa</span></tt> pass will disambiguate the stores to <tt class="docutils literal"><span class="pre">C[0]</span></tt> and
+<tt class="docutils literal"><span class="pre">C[1]</span></tt> because they are accesses to two distinct locations one byte apart, and
+the accesses are each one byte.  In this case, the Loop Invariant Code Motion
+(LICM) pass can use store motion to remove the stores from the loop.  In
+constrast, the following code:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">i</span><span class="p">;</span>
+<span class="kt">char</span> <span class="n">C</span><span class="p">[</span><span class="mi">2</span><span class="p">];</span>
+<span class="kt">char</span> <span class="n">A</span><span class="p">[</span><span class="mi">10</span><span class="p">];</span>
+<span class="cm">/* ... */</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o">!=</span> <span class="mi">10</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span> <span class="p">{</span>
+  <span class="p">((</span><span class="kt">short</span><span class="o">*</span><span class="p">)</span><span class="n">C</span><span class="p">)[</span><span class="mi">0</span><span class="p">]</span> <span class="o">=</span> <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">];</span>  <span class="cm">/* Two byte store! */</span>
+  <span class="n">C</span><span class="p">[</span><span class="mi">1</span><span class="p">]</span> <span class="o">=</span> <span class="n">A</span><span class="p">[</span><span class="mi">9</span><span class="o">-</span><span class="n">i</span><span class="p">];</span>          <span class="cm">/* One byte store */</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In this case, the two stores to C do alias each other, because the access to the
+<tt class="docutils literal"><span class="pre">&C[0]</span></tt> element is a two byte access.  If size information wasn’t available in
+the query, even the first case would have to conservatively assume that the
+accesses alias.</p>
+</div>
+<div class="section" id="the-alias-method">
+<span id="alias"></span><h3><a class="toc-backref" href="#id4">The <tt class="docutils literal"><span class="pre">alias</span></tt> method</a><a class="headerlink" href="#the-alias-method" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">alias</span></tt> method is the primary interface used to determine whether or not
+two memory objects alias each other.  It takes two memory objects as input and
+returns MustAlias, PartialAlias, MayAlias, or NoAlias as appropriate.</p>
+<p>Like all <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interfaces, the <tt class="docutils literal"><span class="pre">alias</span></tt> method requires that either
+the two pointer values be defined within the same function, or at least one of
+the values is a <a class="reference external" href="LangRef.html#constants">constant</a>.</p>
+<div class="section" id="must-may-and-no-alias-responses">
+<span id="must-may-or-no"></span><h4><a class="toc-backref" href="#id5">Must, May, and No Alias Responses</a><a class="headerlink" href="#must-may-and-no-alias-responses" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">NoAlias</span></tt> response may be used when there is never an immediate dependence
+between any memory reference <em>based</em> on one pointer and any memory reference
+<em>based</em> the other. The most obvious example is when the two pointers point to
+non-overlapping memory ranges. Another is when the two pointers are only ever
+used for reading memory. Another is when the memory is freed and reallocated
+between accesses through one pointer and accesses through the other — in this
+case, there is a dependence, but it’s mediated by the free and reallocation.</p>
+<p>As an exception to this is with the <a class="reference external" href="LangRef.html#noalias">noalias</a> keyword;
+the “irrelevant” dependencies are ignored.</p>
+<p>The <tt class="docutils literal"><span class="pre">MayAlias</span></tt> response is used whenever the two pointers might refer to the
+same object.</p>
+<p>The <tt class="docutils literal"><span class="pre">PartialAlias</span></tt> response is used when the two memory objects are known to
+be overlapping in some way, but do not start at the same address.</p>
+<p>The <tt class="docutils literal"><span class="pre">MustAlias</span></tt> response may only be returned if the two memory objects are
+guaranteed to always start at exactly the same location. A <tt class="docutils literal"><span class="pre">MustAlias</span></tt>
+response implies that the pointers compare equal.</p>
+</div>
+</div>
+<div class="section" id="the-getmodrefinfo-methods">
+<h3><a class="toc-backref" href="#id6">The <tt class="docutils literal"><span class="pre">getModRefInfo</span></tt> methods</a><a class="headerlink" href="#the-getmodrefinfo-methods" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">getModRefInfo</span></tt> methods return information about whether the execution of
+an instruction can read or modify a memory location.  Mod/Ref information is
+always conservative: if an instruction <strong>might</strong> read or write a location,
+<tt class="docutils literal"><span class="pre">ModRef</span></tt> is returned.</p>
+<p>The <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> class also provides a <tt class="docutils literal"><span class="pre">getModRefInfo</span></tt> method for testing
+dependencies between function calls.  This method takes two call sites (<tt class="docutils literal"><span class="pre">CS1</span></tt>
+& <tt class="docutils literal"><span class="pre">CS2</span></tt>), returns <tt class="docutils literal"><span class="pre">NoModRef</span></tt> if neither call writes to memory read or
+written by the other, <tt class="docutils literal"><span class="pre">Ref</span></tt> if <tt class="docutils literal"><span class="pre">CS1</span></tt> reads memory written by <tt class="docutils literal"><span class="pre">CS2</span></tt>,
+<tt class="docutils literal"><span class="pre">Mod</span></tt> if <tt class="docutils literal"><span class="pre">CS1</span></tt> writes to memory read or written by <tt class="docutils literal"><span class="pre">CS2</span></tt>, or <tt class="docutils literal"><span class="pre">ModRef</span></tt> if
+<tt class="docutils literal"><span class="pre">CS1</span></tt> might read or write memory written to by <tt class="docutils literal"><span class="pre">CS2</span></tt>.  Note that this
+relation is not commutative.</p>
+</div>
+<div class="section" id="other-useful-aliasanalysis-methods">
+<h3><a class="toc-backref" href="#id7">Other useful <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> methods</a><a class="headerlink" href="#other-useful-aliasanalysis-methods" title="Permalink to this headline">¶</a></h3>
+<p>Several other tidbits of information are often collected by various alias
+analysis implementations and can be put to good use by various clients.</p>
+<div class="section" id="the-pointstoconstantmemory-method">
+<h4><a class="toc-backref" href="#id8">The <tt class="docutils literal"><span class="pre">pointsToConstantMemory</span></tt> method</a><a class="headerlink" href="#the-pointstoconstantmemory-method" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">pointsToConstantMemory</span></tt> method returns true if and only if the analysis
+can prove that the pointer only points to unchanging memory locations
+(functions, constant global variables, and the null pointer).  This information
+can be used to refine mod/ref information: it is impossible for an unchanging
+memory location to be modified.</p>
+</div>
+<div class="section" id="the-doesnotaccessmemory-and-onlyreadsmemory-methods">
+<span id="never-access-memory-or-only-read-memory"></span><h4><a class="toc-backref" href="#id9">The <tt class="docutils literal"><span class="pre">doesNotAccessMemory</span></tt> and  <tt class="docutils literal"><span class="pre">onlyReadsMemory</span></tt> methods</a><a class="headerlink" href="#the-doesnotaccessmemory-and-onlyreadsmemory-methods" title="Permalink to this headline">¶</a></h4>
+<p>These methods are used to provide very simple mod/ref information for function
+calls.  The <tt class="docutils literal"><span class="pre">doesNotAccessMemory</span></tt> method returns true for a function if the
+analysis can prove that the function never reads or writes to memory, or if the
+function only reads from constant memory.  Functions with this property are
+side-effect free and only depend on their input arguments, allowing them to be
+eliminated if they form common subexpressions or be hoisted out of loops.  Many
+common functions behave this way (e.g., <tt class="docutils literal"><span class="pre">sin</span></tt> and <tt class="docutils literal"><span class="pre">cos</span></tt>) but many others do
+not (e.g., <tt class="docutils literal"><span class="pre">acos</span></tt>, which modifies the <tt class="docutils literal"><span class="pre">errno</span></tt> variable).</p>
+<p>The <tt class="docutils literal"><span class="pre">onlyReadsMemory</span></tt> method returns true for a function if analysis can prove
+that (at most) the function only reads from non-volatile memory.  Functions with
+this property are side-effect free, only depending on their input arguments and
+the state of memory when they are called.  This property allows calls to these
+functions to be eliminated and moved around, as long as there is no store
+instruction that changes the contents of memory.  Note that all functions that
+satisfy the <tt class="docutils literal"><span class="pre">doesNotAccessMemory</span></tt> method also satisfies <tt class="docutils literal"><span class="pre">onlyReadsMemory</span></tt>.</p>
+</div>
+</div>
+</div>
+<div class="section" id="writing-a-new-aliasanalysis-implementation">
+<h2><a class="toc-backref" href="#id10">Writing a new <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> Implementation</a><a class="headerlink" href="#writing-a-new-aliasanalysis-implementation" title="Permalink to this headline">¶</a></h2>
+<p>Writing a new alias analysis implementation for LLVM is quite straight-forward.
+There are already several implementations that you can use for examples, and the
+following information should help fill in any details.  For a examples, take a
+look at the <a class="reference internal" href="#various-alias-analysis-implementations">various alias analysis implementations</a> included with LLVM.</p>
+<div class="section" id="different-pass-styles">
+<h3><a class="toc-backref" href="#id11">Different Pass styles</a><a class="headerlink" href="#different-pass-styles" title="Permalink to this headline">¶</a></h3>
+<p>The first step to determining what type of <a class="reference internal" href="WritingAnLLVMPass.html"><em>LLVM pass</em></a>
+you need to use for your Alias Analysis.  As is the case with most other
+analyses and transformations, the answer should be fairly obvious from what type
+of problem you are trying to solve:</p>
+<ol class="arabic simple">
+<li>If you require interprocedural analysis, it should be a <tt class="docutils literal"><span class="pre">Pass</span></tt>.</li>
+<li>If you are a function-local analysis, subclass <tt class="docutils literal"><span class="pre">FunctionPass</span></tt>.</li>
+<li>If you don’t need to look at the program at all, subclass <tt class="docutils literal"><span class="pre">ImmutablePass</span></tt>.</li>
+</ol>
+<p>In addition to the pass that you subclass, you should also inherit from the
+<tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface, of course, and use the <tt class="docutils literal"><span class="pre">RegisterAnalysisGroup</span></tt>
+template to register as an implementation of <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt>.</p>
+</div>
+<div class="section" id="required-initialization-calls">
+<h3><a class="toc-backref" href="#id12">Required initialization calls</a><a class="headerlink" href="#required-initialization-calls" title="Permalink to this headline">¶</a></h3>
+<p>Your subclass of <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> is required to invoke two methods on the
+<tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> base class: <tt class="docutils literal"><span class="pre">getAnalysisUsage</span></tt> and
+<tt class="docutils literal"><span class="pre">InitializeAliasAnalysis</span></tt>.  In particular, your implementation of
+<tt class="docutils literal"><span class="pre">getAnalysisUsage</span></tt> should explicitly call into the
+<tt class="docutils literal"><span class="pre">AliasAnalysis::getAnalysisUsage</span></tt> method in addition to doing any declaring
+any pass dependencies your pass has.  Thus you should have something like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">void</span> <span class="nf">getAnalysisUsage</span><span class="p">(</span><span class="n">AnalysisUsage</span> <span class="o">&</span><span class="n">AU</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
+  <span class="n">AliasAnalysis</span><span class="o">::</span><span class="n">getAnalysisUsage</span><span class="p">(</span><span class="n">AU</span><span class="p">);</span>
+  <span class="c1">// declare your dependencies here.</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Additionally, your must invoke the <tt class="docutils literal"><span class="pre">InitializeAliasAnalysis</span></tt> method from your
+analysis run method (<tt class="docutils literal"><span class="pre">run</span></tt> for a <tt class="docutils literal"><span class="pre">Pass</span></tt>, <tt class="docutils literal"><span class="pre">runOnFunction</span></tt> for a
+<tt class="docutils literal"><span class="pre">FunctionPass</span></tt>, or <tt class="docutils literal"><span class="pre">InitializePass</span></tt> for an <tt class="docutils literal"><span class="pre">ImmutablePass</span></tt>).  For example
+(as part of a <tt class="docutils literal"><span class="pre">Pass</span></tt>):</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">bool</span> <span class="nf">run</span><span class="p">(</span><span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">)</span> <span class="p">{</span>
+  <span class="n">InitializeAliasAnalysis</span><span class="p">(</span><span class="k">this</span><span class="p">);</span>
+  <span class="c1">// Perform analysis here...</span>
+  <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="interfaces-which-may-be-specified">
+<h3><a class="toc-backref" href="#id13">Interfaces which may be specified</a><a class="headerlink" href="#interfaces-which-may-be-specified" title="Permalink to this headline">¶</a></h3>
+<p>All of the <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a> virtual methods
+default to providing <a class="reference internal" href="#aliasanalysis-chaining"><em>chaining</em></a> to another alias
+analysis implementation, which ends up returning conservatively correct
+information (returning “May” Alias and “Mod/Ref” for alias and mod/ref queries
+respectively).  Depending on the capabilities of the analysis you are
+implementing, you just override the interfaces you can improve.</p>
+</div>
+<div class="section" id="aliasanalysis-chaining-behavior">
+<span id="aliasanalysis-chaining"></span><h3><a class="toc-backref" href="#id14"><tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> chaining behavior</a><a class="headerlink" href="#aliasanalysis-chaining-behavior" title="Permalink to this headline">¶</a></h3>
+<p>With only one special exception (the <a class="reference internal" href="#aliasanalysis-no-aa"><em>-no-aa</em></a> pass)
+every alias analysis pass chains to another alias analysis implementation (for
+example, the user can specify “<tt class="docutils literal"><span class="pre">-basicaa</span> <span class="pre">-ds-aa</span> <span class="pre">-licm</span></tt>” to get the maximum
+benefit from both alias analyses).  The alias analysis class automatically
+takes care of most of this for methods that you don’t override.  For methods
+that you do override, in code paths that return a conservative MayAlias or
+Mod/Ref result, simply return whatever the superclass computes.  For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">AliasAnalysis</span><span class="o">::</span><span class="n">AliasResult</span> <span class="n">alias</span><span class="p">(</span><span class="k">const</span> <span class="n">Value</span> <span class="o">*</span><span class="n">V1</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="n">V1Size</span><span class="p">,</span>
+                                 <span class="k">const</span> <span class="n">Value</span> <span class="o">*</span><span class="n">V2</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="n">V2Size</span><span class="p">)</span> <span class="p">{</span>
+  <span class="k">if</span> <span class="p">(...)</span>
+    <span class="k">return</span> <span class="n">NoAlias</span><span class="p">;</span>
+  <span class="p">...</span>
+
+  <span class="c1">// Couldn't determine a must or no-alias result.</span>
+  <span class="k">return</span> <span class="n">AliasAnalysis</span><span class="o">::</span><span class="n">alias</span><span class="p">(</span><span class="n">V1</span><span class="p">,</span> <span class="n">V1Size</span><span class="p">,</span> <span class="n">V2</span><span class="p">,</span> <span class="n">V2Size</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In addition to analysis queries, you must make sure to unconditionally pass LLVM
+<a class="reference internal" href="#update-notification">update notification</a> methods to the superclass as well if you override them,
+which allows all alias analyses in a change to be updated.</p>
+</div>
+<div class="section" id="updating-analysis-results-for-transformations">
+<span id="update-notification"></span><h3><a class="toc-backref" href="#id15">Updating analysis results for transformations</a><a class="headerlink" href="#updating-analysis-results-for-transformations" title="Permalink to this headline">¶</a></h3>
+<p>Alias analysis information is initially computed for a static snapshot of the
+program, but clients will use this information to make transformations to the
+code.  All but the most trivial forms of alias analysis will need to have their
+analysis results updated to reflect the changes made by these transformations.</p>
+<p>The <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface exposes four methods which are used to
+communicate program changes from the clients to the analysis implementations.
+Various alias analysis implementations should use these methods to ensure that
+their internal data structures are kept up-to-date as the program changes (for
+example, when an instruction is deleted), and clients of alias analysis must be
+sure to call these interfaces appropriately.</p>
+<div class="section" id="the-deletevalue-method">
+<h4><a class="toc-backref" href="#id16">The <tt class="docutils literal"><span class="pre">deleteValue</span></tt> method</a><a class="headerlink" href="#the-deletevalue-method" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">deleteValue</span></tt> method is called by transformations when they remove an
+instruction or any other value from the program (including values that do not
+use pointers).  Typically alias analyses keep data structures that have entries
+for each value in the program.  When this method is called, they should remove
+any entries for the specified value, if they exist.</p>
+</div>
+<div class="section" id="the-copyvalue-method">
+<h4><a class="toc-backref" href="#id17">The <tt class="docutils literal"><span class="pre">copyValue</span></tt> method</a><a class="headerlink" href="#the-copyvalue-method" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">copyValue</span></tt> method is used when a new value is introduced into the
+program.  There is no way to introduce a value into the program that did not
+exist before (this doesn’t make sense for a safe compiler transformation), so
+this is the only way to introduce a new value.  This method indicates that the
+new value has exactly the same properties as the value being copied.</p>
+</div>
+<div class="section" id="the-replacewithnewvalue-method">
+<h4><a class="toc-backref" href="#id18">The <tt class="docutils literal"><span class="pre">replaceWithNewValue</span></tt> method</a><a class="headerlink" href="#the-replacewithnewvalue-method" title="Permalink to this headline">¶</a></h4>
+<p>This method is a simple helper method that is provided to make clients easier to
+use.  It is implemented by copying the old analysis information to the new
+value, then deleting the old value.  This method cannot be overridden by alias
+analysis implementations.</p>
+</div>
+<div class="section" id="the-addescapinguse-method">
+<h4><a class="toc-backref" href="#id19">The <tt class="docutils literal"><span class="pre">addEscapingUse</span></tt> method</a><a class="headerlink" href="#the-addescapinguse-method" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">addEscapingUse</span></tt> method is used when the uses of a pointer value have
+changed in ways that may invalidate precomputed analysis information.
+Implementations may either use this callback to provide conservative responses
+for points whose uses have change since analysis time, or may recompute some or
+all of their internal state to continue providing accurate responses.</p>
+<p>In general, any new use of a pointer value is considered an escaping use, and
+must be reported through this callback, <em>except</em> for the uses below:</p>
+<ul class="simple">
+<li>A <tt class="docutils literal"><span class="pre">bitcast</span></tt> or <tt class="docutils literal"><span class="pre">getelementptr</span></tt> of the pointer</li>
+<li>A <tt class="docutils literal"><span class="pre">store</span></tt> through the pointer (but not a <tt class="docutils literal"><span class="pre">store</span></tt> <em>of</em> the pointer)</li>
+<li>A <tt class="docutils literal"><span class="pre">load</span></tt> through the pointer</li>
+</ul>
+</div>
+</div>
+<div class="section" id="efficiency-issues">
+<h3><a class="toc-backref" href="#id20">Efficiency Issues</a><a class="headerlink" href="#efficiency-issues" title="Permalink to this headline">¶</a></h3>
+<p>From the LLVM perspective, the only thing you need to do to provide an efficient
+alias analysis is to make sure that alias analysis <strong>queries</strong> are serviced
+quickly.  The actual calculation of the alias analysis results (the “run”
+method) is only performed once, but many (perhaps duplicate) queries may be
+performed.  Because of this, try to move as much computation to the run method
+as possible (within reason).</p>
+</div>
+<div class="section" id="limitations">
+<h3><a class="toc-backref" href="#id21">Limitations</a><a class="headerlink" href="#limitations" title="Permalink to this headline">¶</a></h3>
+<p>The AliasAnalysis infrastructure has several limitations which make writing a
+new <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> implementation difficult.</p>
+<p>There is no way to override the default alias analysis. It would be very useful
+to be able to do something like “<tt class="docutils literal"><span class="pre">opt</span> <span class="pre">-my-aa</span> <span class="pre">-O2</span></tt>” and have it use <tt class="docutils literal"><span class="pre">-my-aa</span></tt>
+for all passes which need AliasAnalysis, but there is currently no support for
+that, short of changing the source code and recompiling. Similarly, there is
+also no way of setting a chain of analyses as the default.</p>
+<p>There is no way for transform passes to declare that they preserve
+<tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> implementations. The <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface includes
+<tt class="docutils literal"><span class="pre">deleteValue</span></tt> and <tt class="docutils literal"><span class="pre">copyValue</span></tt> methods which are intended to allow a pass to
+keep an AliasAnalysis consistent, however there’s no way for a pass to declare
+in its <tt class="docutils literal"><span class="pre">getAnalysisUsage</span></tt> that it does so. Some passes attempt to use
+<tt class="docutils literal"><span class="pre">AU.addPreserved<AliasAnalysis></span></tt>, however this doesn’t actually have any
+effect.</p>
+<p><tt class="docutils literal"><span class="pre">AliasAnalysisCounter</span></tt> (<tt class="docutils literal"><span class="pre">-count-aa</span></tt>) and <tt class="docutils literal"><span class="pre">AliasDebugger</span></tt> (<tt class="docutils literal"><span class="pre">-debug-aa</span></tt>)
+are implemented as <tt class="docutils literal"><span class="pre">ModulePass</span></tt> classes, so if your alias analysis uses
+<tt class="docutils literal"><span class="pre">FunctionPass</span></tt>, it won’t be able to use these utilities. If you try to use
+them, the pass manager will silently route alias analysis queries directly to
+<tt class="docutils literal"><span class="pre">BasicAliasAnalysis</span></tt> instead.</p>
+<p>Similarly, the <tt class="docutils literal"><span class="pre">opt</span> <span class="pre">-p</span></tt> option introduces <tt class="docutils literal"><span class="pre">ModulePass</span></tt> passes between each
+pass, which prevents the use of <tt class="docutils literal"><span class="pre">FunctionPass</span></tt> alias analysis passes.</p>
+<p>The <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> API does have functions for notifying implementations when
+values are deleted or copied, however these aren’t sufficient. There are many
+other ways that LLVM IR can be modified which could be relevant to
+<tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> implementations which can not be expressed.</p>
+<p>The <tt class="docutils literal"><span class="pre">AliasAnalysisDebugger</span></tt> utility seems to suggest that <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt>
+implementations can expect that they will be informed of any relevant <tt class="docutils literal"><span class="pre">Value</span></tt>
+before it appears in an alias query. However, popular clients such as <tt class="docutils literal"><span class="pre">GVN</span></tt>
+don’t support this, and are known to trigger errors when run with the
+<tt class="docutils literal"><span class="pre">AliasAnalysisDebugger</span></tt>.</p>
+<p>Due to several of the above limitations, the most obvious use for the
+<tt class="docutils literal"><span class="pre">AliasAnalysisCounter</span></tt> utility, collecting stats on all alias queries in a
+compilation, doesn’t work, even if the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> implementations don’t
+use <tt class="docutils literal"><span class="pre">FunctionPass</span></tt>.  There’s no way to set a default, much less a default
+sequence, and there’s no way to preserve it.</p>
+<p>The <tt class="docutils literal"><span class="pre">AliasSetTracker</span></tt> class (which is used by <tt class="docutils literal"><span class="pre">LICM</span></tt>) makes a
+non-deterministic number of alias queries. This can cause stats collected by
+<tt class="docutils literal"><span class="pre">AliasAnalysisCounter</span></tt> to have fluctuations among identical runs, for
+example. Another consequence is that debugging techniques involving pausing
+execution after a predetermined number of queries can be unreliable.</p>
+<p>Many alias queries can be reformulated in terms of other alias queries. When
+multiple <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> queries are chained together, it would make sense to
+start those queries from the beginning of the chain, with care taken to avoid
+infinite looping, however currently an implementation which wants to do this can
+only start such queries from itself.</p>
+</div>
+</div>
+<div class="section" id="using-alias-analysis-results">
+<h2><a class="toc-backref" href="#id22">Using alias analysis results</a><a class="headerlink" href="#using-alias-analysis-results" title="Permalink to this headline">¶</a></h2>
+<p>There are several different ways to use alias analysis results.  In order of
+preference, these are:</p>
+<div class="section" id="using-the-memorydependenceanalysis-pass">
+<h3><a class="toc-backref" href="#id23">Using the <tt class="docutils literal"><span class="pre">MemoryDependenceAnalysis</span></tt> Pass</a><a class="headerlink" href="#using-the-memorydependenceanalysis-pass" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">memdep</span></tt> pass uses alias analysis to provide high-level dependence
+information about memory-using instructions.  This will tell you which store
+feeds into a load, for example.  It uses caching and other techniques to be
+efficient, and is used by Dead Store Elimination, GVN, and memcpy optimizations.</p>
+</div>
+<div class="section" id="using-the-aliassettracker-class">
+<span id="aliassettracker"></span><h3><a class="toc-backref" href="#id24">Using the <tt class="docutils literal"><span class="pre">AliasSetTracker</span></tt> class</a><a class="headerlink" href="#using-the-aliassettracker-class" title="Permalink to this headline">¶</a></h3>
+<p>Many transformations need information about alias <strong>sets</strong> that are active in
+some scope, rather than information about pairwise aliasing.  The
+<a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AliasSetTracker.html">AliasSetTracker</a>
+class is used to efficiently build these Alias Sets from the pairwise alias
+analysis information provided by the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface.</p>
+<p>First you initialize the AliasSetTracker by using the “<tt class="docutils literal"><span class="pre">add</span></tt>” methods to add
+information about various potentially aliasing instructions in the scope you are
+interested in.  Once all of the alias sets are completed, your pass should
+simply iterate through the constructed alias sets, using the <tt class="docutils literal"><span class="pre">AliasSetTracker</span></tt>
+<tt class="docutils literal"><span class="pre">begin()</span></tt>/<tt class="docutils literal"><span class="pre">end()</span></tt> methods.</p>
+<p>The <tt class="docutils literal"><span class="pre">AliasSet</span></tt>s formed by the <tt class="docutils literal"><span class="pre">AliasSetTracker</span></tt> are guaranteed to be
+disjoint, calculate mod/ref information and volatility for the set, and keep
+track of whether or not all of the pointers in the set are Must aliases.  The
+AliasSetTracker also makes sure that sets are properly folded due to call
+instructions, and can provide a list of pointers in each set.</p>
+<p>As an example user of this, the <a class="reference external" href="doxygen/structLICM.html">Loop Invariant Code Motion</a> pass uses <tt class="docutils literal"><span class="pre">AliasSetTracker</span></tt>s to calculate alias
+sets for each loop nest.  If an <tt class="docutils literal"><span class="pre">AliasSet</span></tt> in a loop is not modified, then all
+load instructions from that set may be hoisted out of the loop.  If any alias
+sets are stored to <strong>and</strong> are must alias sets, then the stores may be sunk
+to outside of the loop, promoting the memory location to a register for the
+duration of the loop nest.  Both of these transformations only apply if the
+pointer argument is loop-invariant.</p>
+<div class="section" id="the-aliassettracker-implementation">
+<h4><a class="toc-backref" href="#id25">The AliasSetTracker implementation</a><a class="headerlink" href="#the-aliassettracker-implementation" title="Permalink to this headline">¶</a></h4>
+<p>The AliasSetTracker class is implemented to be as efficient as possible.  It
+uses the union-find algorithm to efficiently merge AliasSets when a pointer is
+inserted into the AliasSetTracker that aliases multiple sets.  The primary data
+structure is a hash table mapping pointers to the AliasSet they are in.</p>
+<p>The AliasSetTracker class must maintain a list of all of the LLVM <tt class="docutils literal"><span class="pre">Value*</span></tt>s
+that are in each AliasSet.  Since the hash table already has entries for each
+LLVM <tt class="docutils literal"><span class="pre">Value*</span></tt> of interest, the AliasesSets thread the linked list through
+these hash-table nodes to avoid having to allocate memory unnecessarily, and to
+make merging alias sets extremely efficient (the linked list merge is constant
+time).</p>
+<p>You shouldn’t need to understand these details if you are just a client of the
+AliasSetTracker, but if you look at the code, hopefully this brief description
+will help make sense of why things are designed the way they are.</p>
+</div>
+</div>
+<div class="section" id="using-the-aliasanalysis-interface-directly">
+<h3><a class="toc-backref" href="#id26">Using the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface directly</a><a class="headerlink" href="#using-the-aliasanalysis-interface-directly" title="Permalink to this headline">¶</a></h3>
+<p>If neither of these utility class are what your pass needs, you should use the
+interfaces exposed by the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> class directly.  Try to use the
+higher-level methods when possible (e.g., use mod/ref information instead of the
+<a class="reference internal" href="#alias">alias</a> method directly if possible) to get the best precision and efficiency.</p>
+</div>
+</div>
+<div class="section" id="existing-alias-analysis-implementations-and-clients">
+<h2><a class="toc-backref" href="#id27">Existing alias analysis implementations and clients</a><a class="headerlink" href="#existing-alias-analysis-implementations-and-clients" title="Permalink to this headline">¶</a></h2>
+<p>If you’re going to be working with the LLVM alias analysis infrastructure, you
+should know what clients and implementations of alias analysis are available.
+In particular, if you are implementing an alias analysis, you should be aware of
+the <a class="reference internal" href="#the-clients">the clients</a> that are useful for monitoring and evaluating different
+implementations.</p>
+<div class="section" id="available-aliasanalysis-implementations">
+<span id="various-alias-analysis-implementations"></span><h3><a class="toc-backref" href="#id28">Available <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> implementations</a><a class="headerlink" href="#available-aliasanalysis-implementations" title="Permalink to this headline">¶</a></h3>
+<p>This section lists the various implementations of the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt>
+interface.  With the exception of the <a class="reference internal" href="#aliasanalysis-no-aa"><em>-no-aa</em></a>
+implementation, all of these <a class="reference internal" href="#aliasanalysis-chaining"><em>chain</em></a> to other
+alias analysis implementations.</p>
+<div class="section" id="the-no-aa-pass">
+<span id="aliasanalysis-no-aa"></span><h4><a class="toc-backref" href="#id29">The <tt class="docutils literal"><span class="pre">-no-aa</span></tt> pass</a><a class="headerlink" href="#the-no-aa-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-no-aa</span></tt> pass is just like what it sounds: an alias analysis that never
+returns any useful information.  This pass can be useful if you think that alias
+analysis is doing something wrong and are trying to narrow down a problem.</p>
+</div>
+<div class="section" id="the-basicaa-pass">
+<h4><a class="toc-backref" href="#id30">The <tt class="docutils literal"><span class="pre">-basicaa</span></tt> pass</a><a class="headerlink" href="#the-basicaa-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-basicaa</span></tt> pass is an aggressive local analysis that <em>knows</em> many
+important facts:</p>
+<ul class="simple">
+<li>Distinct globals, stack allocations, and heap allocations can never alias.</li>
+<li>Globals, stack allocations, and heap allocations never alias the null pointer.</li>
+<li>Different fields of a structure do not alias.</li>
+<li>Indexes into arrays with statically differing subscripts cannot alias.</li>
+<li>Many common standard C library functions <a class="reference internal" href="#never-access-memory-or-only-read-memory">never access memory or only read
+memory</a>.</li>
+<li>Pointers that obviously point to constant globals “<tt class="docutils literal"><span class="pre">pointToConstantMemory</span></tt>”.</li>
+<li>Function calls can not modify or references stack allocations if they never
+escape from the function that allocates them (a common case for automatic
+arrays).</li>
+</ul>
+</div>
+<div class="section" id="the-globalsmodref-aa-pass">
+<h4><a class="toc-backref" href="#id31">The <tt class="docutils literal"><span class="pre">-globalsmodref-aa</span></tt> pass</a><a class="headerlink" href="#the-globalsmodref-aa-pass" title="Permalink to this headline">¶</a></h4>
+<p>This pass implements a simple context-sensitive mod/ref and alias analysis for
+internal global variables that don’t “have their address taken”.  If a global
+does not have its address taken, the pass knows that no pointers alias the
+global.  This pass also keeps track of functions that it knows never access
+memory or never read memory.  This allows certain optimizations (e.g. GVN) to
+eliminate call instructions entirely.</p>
+<p>The real power of this pass is that it provides context-sensitive mod/ref
+information for call instructions.  This allows the optimizer to know that calls
+to a function do not clobber or read the value of the global, allowing loads and
+stores to be eliminated.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This pass is somewhat limited in its scope (only support non-address taken
+globals), but is very quick analysis.</p>
+</div>
+</div>
+<div class="section" id="the-steens-aa-pass">
+<h4><a class="toc-backref" href="#id32">The <tt class="docutils literal"><span class="pre">-steens-aa</span></tt> pass</a><a class="headerlink" href="#the-steens-aa-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-steens-aa</span></tt> pass implements a variation on the well-known “Steensgaard’s
+algorithm” for interprocedural alias analysis.  Steensgaard’s algorithm is a
+unification-based, flow-insensitive, context-insensitive, and field-insensitive
+alias analysis that is also very scalable (effectively linear time).</p>
+<p>The LLVM <tt class="docutils literal"><span class="pre">-steens-aa</span></tt> pass implements a “speculatively field-<strong>sensitive</strong>”
+version of Steensgaard’s algorithm using the Data Structure Analysis framework.
+This gives it substantially more precision than the standard algorithm while
+maintaining excellent analysis scalability.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last"><tt class="docutils literal"><span class="pre">-steens-aa</span></tt> is available in the optional “poolalloc” module. It is not part
+of the LLVM core.</p>
+</div>
+</div>
+<div class="section" id="the-ds-aa-pass">
+<h4><a class="toc-backref" href="#id33">The <tt class="docutils literal"><span class="pre">-ds-aa</span></tt> pass</a><a class="headerlink" href="#the-ds-aa-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-ds-aa</span></tt> pass implements the full Data Structure Analysis algorithm.  Data
+Structure Analysis is a modular unification-based, flow-insensitive,
+context-<strong>sensitive</strong>, and speculatively field-<strong>sensitive</strong> alias
+analysis that is also quite scalable, usually at <tt class="docutils literal"><span class="pre">O(n</span> <span class="pre">*</span> <span class="pre">log(n))</span></tt>.</p>
+<p>This algorithm is capable of responding to a full variety of alias analysis
+queries, and can provide context-sensitive mod/ref information as well.  The
+only major facility not implemented so far is support for must-alias
+information.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last"><tt class="docutils literal"><span class="pre">-ds-aa</span></tt> is available in the optional “poolalloc” module. It is not part of
+the LLVM core.</p>
+</div>
+</div>
+<div class="section" id="the-scev-aa-pass">
+<h4><a class="toc-backref" href="#id34">The <tt class="docutils literal"><span class="pre">-scev-aa</span></tt> pass</a><a class="headerlink" href="#the-scev-aa-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-scev-aa</span></tt> pass implements AliasAnalysis queries by translating them into
+ScalarEvolution queries. This gives it a more complete understanding of
+<tt class="docutils literal"><span class="pre">getelementptr</span></tt> instructions and loop induction variables than other alias
+analyses have.</p>
+</div>
+</div>
+<div class="section" id="alias-analysis-driven-transformations">
+<h3><a class="toc-backref" href="#id35">Alias analysis driven transformations</a><a class="headerlink" href="#alias-analysis-driven-transformations" title="Permalink to this headline">¶</a></h3>
+<p>LLVM includes several alias-analysis driven transformations which can be used
+with any of the implementations above.</p>
+<div class="section" id="the-adce-pass">
+<h4><a class="toc-backref" href="#id36">The <tt class="docutils literal"><span class="pre">-adce</span></tt> pass</a><a class="headerlink" href="#the-adce-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-adce</span></tt> pass, which implements Aggressive Dead Code Elimination uses the
+<tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface to delete calls to functions that do not have
+side-effects and are not used.</p>
+</div>
+<div class="section" id="the-licm-pass">
+<h4><a class="toc-backref" href="#id37">The <tt class="docutils literal"><span class="pre">-licm</span></tt> pass</a><a class="headerlink" href="#the-licm-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-licm</span></tt> pass implements various Loop Invariant Code Motion related
+transformations.  It uses the <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt> interface for several different
+transformations:</p>
+<ul class="simple">
+<li>It uses mod/ref information to hoist or sink load instructions out of loops if
+there are no instructions in the loop that modifies the memory loaded.</li>
+<li>It uses mod/ref information to hoist function calls out of loops that do not
+write to memory and are loop-invariant.</li>
+<li>If uses alias information to promote memory objects that are loaded and stored
+to in loops to live in a register instead.  It can do this if there are no may
+aliases to the loaded/stored memory location.</li>
+</ul>
+</div>
+<div class="section" id="the-argpromotion-pass">
+<h4><a class="toc-backref" href="#id38">The <tt class="docutils literal"><span class="pre">-argpromotion</span></tt> pass</a><a class="headerlink" href="#the-argpromotion-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-argpromotion</span></tt> pass promotes by-reference arguments to be passed in
+by-value instead.  In particular, if pointer arguments are only loaded from it
+passes in the value loaded instead of the address to the function.  This pass
+uses alias information to make sure that the value loaded from the argument
+pointer is not modified between the entry of the function and any load of the
+pointer.</p>
+</div>
+<div class="section" id="the-gvn-memcpyopt-and-dse-passes">
+<h4><a class="toc-backref" href="#id39">The <tt class="docutils literal"><span class="pre">-gvn</span></tt>, <tt class="docutils literal"><span class="pre">-memcpyopt</span></tt>, and <tt class="docutils literal"><span class="pre">-dse</span></tt> passes</a><a class="headerlink" href="#the-gvn-memcpyopt-and-dse-passes" title="Permalink to this headline">¶</a></h4>
+<p>These passes use AliasAnalysis information to reason about loads and stores.</p>
+</div>
+</div>
+<div class="section" id="clients-for-debugging-and-evaluation-of-implementations">
+<span id="the-clients"></span><h3><a class="toc-backref" href="#id40">Clients for debugging and evaluation of implementations</a><a class="headerlink" href="#clients-for-debugging-and-evaluation-of-implementations" title="Permalink to this headline">¶</a></h3>
+<p>These passes are useful for evaluating the various alias analysis
+implementations.  You can use them with commands like:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% opt -ds-aa -aa-eval foo.bc -disable-output -stats
+</pre></div>
+</div>
+<div class="section" id="the-print-alias-sets-pass">
+<h4><a class="toc-backref" href="#id41">The <tt class="docutils literal"><span class="pre">-print-alias-sets</span></tt> pass</a><a class="headerlink" href="#the-print-alias-sets-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-print-alias-sets</span></tt> pass is exposed as part of the <tt class="docutils literal"><span class="pre">opt</span></tt> tool to print
+out the Alias Sets formed by the <a class="reference internal" href="#aliassettracker">AliasSetTracker</a> class.  This is useful if
+you’re using the <tt class="docutils literal"><span class="pre">AliasSetTracker</span></tt> class.  To use it, use something like:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% opt -ds-aa -print-alias-sets -disable-output
+</pre></div>
+</div>
+</div>
+<div class="section" id="the-count-aa-pass">
+<h4><a class="toc-backref" href="#id42">The <tt class="docutils literal"><span class="pre">-count-aa</span></tt> pass</a><a class="headerlink" href="#the-count-aa-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-count-aa</span></tt> pass is useful to see how many queries a particular pass is
+making and what responses are returned by the alias analysis.  As an example:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% opt -basicaa -count-aa -ds-aa -count-aa -licm
+</pre></div>
+</div>
+<p>will print out how many queries (and what responses are returned) by the
+<tt class="docutils literal"><span class="pre">-licm</span></tt> pass (of the <tt class="docutils literal"><span class="pre">-ds-aa</span></tt> pass) and how many queries are made of the
+<tt class="docutils literal"><span class="pre">-basicaa</span></tt> pass by the <tt class="docutils literal"><span class="pre">-ds-aa</span></tt> pass.  This can be useful when debugging a
+transformation or an alias analysis implementation.</p>
+</div>
+<div class="section" id="the-aa-eval-pass">
+<h4><a class="toc-backref" href="#id43">The <tt class="docutils literal"><span class="pre">-aa-eval</span></tt> pass</a><a class="headerlink" href="#the-aa-eval-pass" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">-aa-eval</span></tt> pass simply iterates through all pairs of pointers in a
+function and asks an alias analysis whether or not the pointers alias.  This
+gives an indication of the precision of the alias analysis.  Statistics are
+printed indicating the percent of no/may/must aliases found (a more precise
+algorithm will have a lower number of may aliases).</p>
+</div>
+</div>
+</div>
+<div class="section" id="memory-dependence-analysis">
+<h2><a class="toc-backref" href="#id44">Memory Dependence Analysis</a><a class="headerlink" href="#memory-dependence-analysis" title="Permalink to this headline">¶</a></h2>
+<p>If you’re just looking to be a client of alias analysis information, consider
+using the Memory Dependence Analysis interface instead.  MemDep is a lazy,
+caching layer on top of alias analysis that is able to answer the question of
+what preceding memory operations a given instruction depends on, either at an
+intra- or inter-block level.  Because of its laziness and caching policy, using
+MemDep can be a significant performance win over accessing alias analysis
+directly.</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="BitCodeFormat.html" title="LLVM Bitcode File Format"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="Extensions.html" title="LLVM Extensions"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/Atomics.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/Atomics.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/Atomics.html (added)
+++ www-releases/trunk/3.4.1/docs/Atomics.html Wed May  7 15:09:32 2014
@@ -0,0 +1,488 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>LLVM Atomic Instructions and Concurrency Guide — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="LLVM Coding Standards" href="CodingStandards.html" />
+    <link rel="prev" title="MCJIT Design and Implementation" href="MCJITDesignAndImplementation.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="CodingStandards.html" title="LLVM Coding Standards"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="MCJITDesignAndImplementation.html" title="MCJIT Design and Implementation"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-atomic-instructions-and-concurrency-guide">
+<h1>LLVM Atomic Instructions and Concurrency Guide<a class="headerlink" href="#llvm-atomic-instructions-and-concurrency-guide" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id4">Introduction</a></li>
+<li><a class="reference internal" href="#optimization-outside-atomic" id="id5">Optimization outside atomic</a></li>
+<li><a class="reference internal" href="#atomic-instructions" id="id6">Atomic instructions</a></li>
+<li><a class="reference internal" href="#atomic-orderings" id="id7">Atomic orderings</a><ul>
+<li><a class="reference internal" href="#notatomic" id="id8">NotAtomic</a></li>
+<li><a class="reference internal" href="#unordered" id="id9">Unordered</a></li>
+<li><a class="reference internal" href="#monotonic" id="id10">Monotonic</a></li>
+<li><a class="reference internal" href="#acquire" id="id11">Acquire</a></li>
+<li><a class="reference internal" href="#release" id="id12">Release</a></li>
+<li><a class="reference internal" href="#acquirerelease" id="id13">AcquireRelease</a></li>
+<li><a class="reference internal" href="#sequentiallyconsistent" id="id14">SequentiallyConsistent</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#atomics-and-ir-optimization" id="id15">Atomics and IR optimization</a></li>
+<li><a class="reference internal" href="#atomics-and-codegen" id="id16">Atomics and Codegen</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id4">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>Historically, LLVM has not had very strong support for concurrency; some minimal
+intrinsics were provided, and <tt class="docutils literal"><span class="pre">volatile</span></tt> was used in some cases to achieve
+rough semantics in the presence of concurrency.  However, this is changing;
+there are now new instructions which are well-defined in the presence of threads
+and asynchronous signals, and the model for existing instructions has been
+clarified in the IR.</p>
+<p>The atomic instructions are designed specifically to provide readable IR and
+optimized code generation for the following:</p>
+<ul class="simple">
+<li>The new C++0x <tt class="docutils literal"><span class="pre"><atomic></span></tt> header.  (<a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/">C++0x draft available here</a>.) (<a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg14/">C1x draft available here</a>.)</li>
+<li>Proper semantics for Java-style memory, for both <tt class="docutils literal"><span class="pre">volatile</span></tt> and regular
+shared variables. (<a class="reference external" href="http://java.sun.com/docs/books/jls/third_edition/html/memory.html">Java Specification</a>)</li>
+<li>gcc-compatible <tt class="docutils literal"><span class="pre">__sync_*</span></tt> builtins. (<a class="reference external" href="http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html">Description</a>)</li>
+<li>Other scenarios with atomic semantics, including <tt class="docutils literal"><span class="pre">static</span></tt> variables with
+non-trivial constructors in C++.</li>
+</ul>
+<p>Atomic and volatile in the IR are orthogonal; “volatile” is the C/C++ volatile,
+which ensures that every volatile load and store happens and is performed in the
+stated order.  A couple examples: if a SequentiallyConsistent store is
+immediately followed by another SequentiallyConsistent store to the same
+address, the first store can be erased. This transformation is not allowed for a
+pair of volatile stores. On the other hand, a non-volatile non-atomic load can
+be moved across a volatile load freely, but not an Acquire load.</p>
+<p>This document is intended to provide a guide to anyone either writing a frontend
+for LLVM or working on optimization passes for LLVM with a guide for how to deal
+with instructions with special semantics in the presence of concurrency.  This
+is not intended to be a precise guide to the semantics; the details can get
+extremely complicated and unreadable, and are not usually necessary.</p>
+</div>
+<div class="section" id="optimization-outside-atomic">
+<span id="id1"></span><h2><a class="toc-backref" href="#id5">Optimization outside atomic</a><a class="headerlink" href="#optimization-outside-atomic" title="Permalink to this headline">¶</a></h2>
+<p>The basic <tt class="docutils literal"><span class="pre">'load'</span></tt> and <tt class="docutils literal"><span class="pre">'store'</span></tt> allow a variety of optimizations, but can
+lead to undefined results in a concurrent environment; see <a class="reference internal" href="#notatomic">NotAtomic</a>. This
+section specifically goes into the one optimizer restriction which applies in
+concurrent environments, which gets a bit more of an extended description
+because any optimization dealing with stores needs to be aware of it.</p>
+<p>From the optimizer’s point of view, the rule is that if there are not any
+instructions with atomic ordering involved, concurrency does not matter, with
+one exception: if a variable might be visible to another thread or signal
+handler, a store cannot be inserted along a path where it might not execute
+otherwise.  Take the following example:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="cm">/* C code, for readability; run through clang -O2 -S -emit-llvm to get</span>
+<span class="cm">    equivalent IR */</span>
+ <span class="kt">int</span> <span class="n">x</span><span class="p">;</span>
+ <span class="kt">void</span> <span class="nf">f</span><span class="p">(</span><span class="kt">int</span><span class="o">*</span> <span class="n">a</span><span class="p">)</span> <span class="p">{</span>
+   <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="mi">100</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
+     <span class="k">if</span> <span class="p">(</span><span class="n">a</span><span class="p">[</span><span class="n">i</span><span class="p">])</span>
+       <span class="n">x</span> <span class="o">+=</span> <span class="mi">1</span><span class="p">;</span>
+   <span class="p">}</span>
+ <span class="p">}</span>
+</pre></div>
+</div>
+<p>The following is equivalent in non-concurrent situations:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="kt">int</span> <span class="n">x</span><span class="p">;</span>
+<span class="kt">void</span> <span class="nf">f</span><span class="p">(</span><span class="kt">int</span><span class="o">*</span> <span class="n">a</span><span class="p">)</span> <span class="p">{</span>
+  <span class="kt">int</span> <span class="n">xtemp</span> <span class="o">=</span> <span class="n">x</span><span class="p">;</span>
+  <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="mi">100</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
+    <span class="k">if</span> <span class="p">(</span><span class="n">a</span><span class="p">[</span><span class="n">i</span><span class="p">])</span>
+      <span class="n">xtemp</span> <span class="o">+=</span> <span class="mi">1</span><span class="p">;</span>
+  <span class="p">}</span>
+  <span class="n">x</span> <span class="o">=</span> <span class="n">xtemp</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>However, LLVM is not allowed to transform the former to the latter: it could
+indirectly introduce undefined behavior if another thread can access <tt class="docutils literal"><span class="pre">x</span></tt> at
+the same time. (This example is particularly of interest because before the
+concurrency model was implemented, LLVM would perform this transformation.)</p>
+<p>Note that speculative loads are allowed; a load which is part of a race returns
+<tt class="docutils literal"><span class="pre">undef</span></tt>, but does not have undefined behavior.</p>
+</div>
+<div class="section" id="atomic-instructions">
+<h2><a class="toc-backref" href="#id6">Atomic instructions</a><a class="headerlink" href="#atomic-instructions" title="Permalink to this headline">¶</a></h2>
+<p>For cases where simple loads and stores are not sufficient, LLVM provides
+various atomic instructions. The exact guarantees provided depend on the
+ordering; see <a class="reference internal" href="#atomic-orderings">Atomic orderings</a>.</p>
+<p><tt class="docutils literal"><span class="pre">load</span> <span class="pre">atomic</span></tt> and <tt class="docutils literal"><span class="pre">store</span> <span class="pre">atomic</span></tt> provide the same basic functionality as
+non-atomic loads and stores, but provide additional guarantees in situations
+where threads and signals are involved.</p>
+<p><tt class="docutils literal"><span class="pre">cmpxchg</span></tt> and <tt class="docutils literal"><span class="pre">atomicrmw</span></tt> are essentially like an atomic load followed by an
+atomic store (where the store is conditional for <tt class="docutils literal"><span class="pre">cmpxchg</span></tt>), but no other
+memory operation can happen on any thread between the load and store.  Note that
+LLVM’s cmpxchg does not provide quite as many options as the C++0x version.</p>
+<p>A <tt class="docutils literal"><span class="pre">fence</span></tt> provides Acquire and/or Release ordering which is not part of
+another operation; it is normally used along with Monotonic memory operations.
+A Monotonic load followed by an Acquire fence is roughly equivalent to an
+Acquire load.</p>
+<p>Frontends generating atomic instructions generally need to be aware of the
+target to some degree; atomic instructions are guaranteed to be lock-free, and
+therefore an instruction which is wider than the target natively supports can be
+impossible to generate.</p>
+</div>
+<div class="section" id="atomic-orderings">
+<span id="id2"></span><h2><a class="toc-backref" href="#id7">Atomic orderings</a><a class="headerlink" href="#atomic-orderings" title="Permalink to this headline">¶</a></h2>
+<p>In order to achieve a balance between performance and necessary guarantees,
+there are six levels of atomicity. They are listed in order of strength; each
+level includes all the guarantees of the previous level except for
+Acquire/Release. (See also <a class="reference external" href="LangRef.html#ordering">LangRef Ordering</a>.)</p>
+<div class="section" id="notatomic">
+<span id="id3"></span><h3><a class="toc-backref" href="#id8">NotAtomic</a><a class="headerlink" href="#notatomic" title="Permalink to this headline">¶</a></h3>
+<p>NotAtomic is the obvious, a load or store which is not atomic. (This isn’t
+really a level of atomicity, but is listed here for comparison.) This is
+essentially a regular load or store. If there is a race on a given memory
+location, loads from that location return undef.</p>
+<dl class="docutils">
+<dt>Relevant standard</dt>
+<dd>This is intended to match shared variables in C/C++, and to be used in any
+other context where memory access is necessary, and a race is impossible. (The
+precise definition is in <a class="reference external" href="LangRef.html#memmodel">LangRef Memory Model</a>.)</dd>
+<dt>Notes for frontends</dt>
+<dd>The rule is essentially that all memory accessed with basic loads and stores
+by multiple threads should be protected by a lock or other synchronization;
+otherwise, you are likely to run into undefined behavior. If your frontend is
+for a “safe” language like Java, use Unordered to load and store any shared
+variable.  Note that NotAtomic volatile loads and stores are not properly
+atomic; do not try to use them as a substitute. (Per the C/C++ standards,
+volatile does provide some limited guarantees around asynchronous signals, but
+atomics are generally a better solution.)</dd>
+<dt>Notes for optimizers</dt>
+<dd>Introducing loads to shared variables along a codepath where they would not
+otherwise exist is allowed; introducing stores to shared variables is not. See
+<a class="reference internal" href="#optimization-outside-atomic">Optimization outside atomic</a>.</dd>
+<dt>Notes for code generation</dt>
+<dd>The one interesting restriction here is that it is not allowed to write to
+bytes outside of the bytes relevant to a store.  This is mostly relevant to
+unaligned stores: it is not allowed in general to convert an unaligned store
+into two aligned stores of the same width as the unaligned store. Backends are
+also expected to generate an i8 store as an i8 store, and not an instruction
+which writes to surrounding bytes.  (If you are writing a backend for an
+architecture which cannot satisfy these restrictions and cares about
+concurrency, please send an email to llvmdev.)</dd>
+</dl>
+</div>
+<div class="section" id="unordered">
+<h3><a class="toc-backref" href="#id9">Unordered</a><a class="headerlink" href="#unordered" title="Permalink to this headline">¶</a></h3>
+<p>Unordered is the lowest level of atomicity. It essentially guarantees that races
+produce somewhat sane results instead of having undefined behavior.  It also
+guarantees the operation to be lock-free, so it do not depend on the data being
+part of a special atomic structure or depend on a separate per-process global
+lock.  Note that code generation will fail for unsupported atomic operations; if
+you need such an operation, use explicit locking.</p>
+<dl class="docutils">
+<dt>Relevant standard</dt>
+<dd>This is intended to match the Java memory model for shared variables.</dd>
+<dt>Notes for frontends</dt>
+<dd>This cannot be used for synchronization, but is useful for Java and other
+“safe” languages which need to guarantee that the generated code never
+exhibits undefined behavior. Note that this guarantee is cheap on common
+platforms for loads of a native width, but can be expensive or unavailable for
+wider loads, like a 64-bit store on ARM. (A frontend for Java or other “safe”
+languages would normally split a 64-bit store on ARM into two 32-bit unordered
+stores.)</dd>
+<dt>Notes for optimizers</dt>
+<dd>In terms of the optimizer, this prohibits any transformation that transforms a
+single load into multiple loads, transforms a store into multiple stores,
+narrows a store, or stores a value which would not be stored otherwise.  Some
+examples of unsafe optimizations are narrowing an assignment into a bitfield,
+rematerializing a load, and turning loads and stores into a memcpy
+call. Reordering unordered operations is safe, though, and optimizers should
+take advantage of that because unordered operations are common in languages
+that need them.</dd>
+<dt>Notes for code generation</dt>
+<dd>These operations are required to be atomic in the sense that if you use
+unordered loads and unordered stores, a load cannot see a value which was
+never stored.  A normal load or store instruction is usually sufficient, but
+note that an unordered load or store cannot be split into multiple
+instructions (or an instruction which does multiple memory operations, like
+<tt class="docutils literal"><span class="pre">LDRD</span></tt> on ARM without LPAE, or not naturally-aligned <tt class="docutils literal"><span class="pre">LDRD</span></tt> on LPAE ARM).</dd>
+</dl>
+</div>
+<div class="section" id="monotonic">
+<h3><a class="toc-backref" href="#id10">Monotonic</a><a class="headerlink" href="#monotonic" title="Permalink to this headline">¶</a></h3>
+<p>Monotonic is the weakest level of atomicity that can be used in synchronization
+primitives, although it does not provide any general synchronization. It
+essentially guarantees that if you take all the operations affecting a specific
+address, a consistent ordering exists.</p>
+<dl class="docutils">
+<dt>Relevant standard</dt>
+<dd>This corresponds to the C++0x/C1x <tt class="docutils literal"><span class="pre">memory_order_relaxed</span></tt>; see those
+standards for the exact definition.</dd>
+<dt>Notes for frontends</dt>
+<dd>If you are writing a frontend which uses this directly, use with caution.  The
+guarantees in terms of synchronization are very weak, so make sure these are
+only used in a pattern which you know is correct.  Generally, these would
+either be used for atomic operations which do not protect other memory (like
+an atomic counter), or along with a <tt class="docutils literal"><span class="pre">fence</span></tt>.</dd>
+<dt>Notes for optimizers</dt>
+<dd>In terms of the optimizer, this can be treated as a read+write on the relevant
+memory location (and alias analysis will take advantage of that). In addition,
+it is legal to reorder non-atomic and Unordered loads around Monotonic
+loads. CSE/DSE and a few other optimizations are allowed, but Monotonic
+operations are unlikely to be used in ways which would make those
+optimizations useful.</dd>
+<dt>Notes for code generation</dt>
+<dd>Code generation is essentially the same as that for unordered for loads and
+stores.  No fences are required.  <tt class="docutils literal"><span class="pre">cmpxchg</span></tt> and <tt class="docutils literal"><span class="pre">atomicrmw</span></tt> are required
+to appear as a single operation.</dd>
+</dl>
+</div>
+<div class="section" id="acquire">
+<h3><a class="toc-backref" href="#id11">Acquire</a><a class="headerlink" href="#acquire" title="Permalink to this headline">¶</a></h3>
+<p>Acquire provides a barrier of the sort necessary to acquire a lock to access
+other memory with normal loads and stores.</p>
+<dl class="docutils">
+<dt>Relevant standard</dt>
+<dd>This corresponds to the C++0x/C1x <tt class="docutils literal"><span class="pre">memory_order_acquire</span></tt>. It should also be
+used for C++0x/C1x <tt class="docutils literal"><span class="pre">memory_order_consume</span></tt>.</dd>
+<dt>Notes for frontends</dt>
+<dd>If you are writing a frontend which uses this directly, use with caution.
+Acquire only provides a semantic guarantee when paired with a Release
+operation.</dd>
+<dt>Notes for optimizers</dt>
+<dd>Optimizers not aware of atomics can treat this like a nothrow call.  It is
+also possible to move stores from before an Acquire load or read-modify-write
+operation to after it, and move non-Acquire loads from before an Acquire
+operation to after it.</dd>
+<dt>Notes for code generation</dt>
+<dd>Architectures with weak memory ordering (essentially everything relevant today
+except x86 and SPARC) require some sort of fence to maintain the Acquire
+semantics.  The precise fences required varies widely by architecture, but for
+a simple implementation, most architectures provide a barrier which is strong
+enough for everything (<tt class="docutils literal"><span class="pre">dmb</span></tt> on ARM, <tt class="docutils literal"><span class="pre">sync</span></tt> on PowerPC, etc.).  Putting
+such a fence after the equivalent Monotonic operation is sufficient to
+maintain Acquire semantics for a memory operation.</dd>
+</dl>
+</div>
+<div class="section" id="release">
+<h3><a class="toc-backref" href="#id12">Release</a><a class="headerlink" href="#release" title="Permalink to this headline">¶</a></h3>
+<p>Release is similar to Acquire, but with a barrier of the sort necessary to
+release a lock.</p>
+<dl class="docutils">
+<dt>Relevant standard</dt>
+<dd>This corresponds to the C++0x/C1x <tt class="docutils literal"><span class="pre">memory_order_release</span></tt>.</dd>
+<dt>Notes for frontends</dt>
+<dd>If you are writing a frontend which uses this directly, use with caution.
+Release only provides a semantic guarantee when paired with a Acquire
+operation.</dd>
+<dt>Notes for optimizers</dt>
+<dd>Optimizers not aware of atomics can treat this like a nothrow call.  It is
+also possible to move loads from after a Release store or read-modify-write
+operation to before it, and move non-Release stores from after an Release
+operation to before it.</dd>
+<dt>Notes for code generation</dt>
+<dd>See the section on Acquire; a fence before the relevant operation is usually
+sufficient for Release. Note that a store-store fence is not sufficient to
+implement Release semantics; store-store fences are generally not exposed to
+IR because they are extremely difficult to use correctly.</dd>
+</dl>
+</div>
+<div class="section" id="acquirerelease">
+<h3><a class="toc-backref" href="#id13">AcquireRelease</a><a class="headerlink" href="#acquirerelease" title="Permalink to this headline">¶</a></h3>
+<p>AcquireRelease (<tt class="docutils literal"><span class="pre">acq_rel</span></tt> in IR) provides both an Acquire and a Release
+barrier (for fences and operations which both read and write memory).</p>
+<dl class="docutils">
+<dt>Relevant standard</dt>
+<dd>This corresponds to the C++0x/C1x <tt class="docutils literal"><span class="pre">memory_order_acq_rel</span></tt>.</dd>
+<dt>Notes for frontends</dt>
+<dd>If you are writing a frontend which uses this directly, use with caution.
+Acquire only provides a semantic guarantee when paired with a Release
+operation, and vice versa.</dd>
+<dt>Notes for optimizers</dt>
+<dd>In general, optimizers should treat this like a nothrow call; the possible
+optimizations are usually not interesting.</dd>
+<dt>Notes for code generation</dt>
+<dd>This operation has Acquire and Release semantics; see the sections on Acquire
+and Release.</dd>
+</dl>
+</div>
+<div class="section" id="sequentiallyconsistent">
+<h3><a class="toc-backref" href="#id14">SequentiallyConsistent</a><a class="headerlink" href="#sequentiallyconsistent" title="Permalink to this headline">¶</a></h3>
+<p>SequentiallyConsistent (<tt class="docutils literal"><span class="pre">seq_cst</span></tt> in IR) provides Acquire semantics for loads
+and Release semantics for stores. Additionally, it guarantees that a total
+ordering exists between all SequentiallyConsistent operations.</p>
+<dl class="docutils">
+<dt>Relevant standard</dt>
+<dd>This corresponds to the C++0x/C1x <tt class="docutils literal"><span class="pre">memory_order_seq_cst</span></tt>, Java volatile, and
+the gcc-compatible <tt class="docutils literal"><span class="pre">__sync_*</span></tt> builtins which do not specify otherwise.</dd>
+<dt>Notes for frontends</dt>
+<dd>If a frontend is exposing atomic operations, these are much easier to reason
+about for the programmer than other kinds of operations, and using them is
+generally a practical performance tradeoff.</dd>
+<dt>Notes for optimizers</dt>
+<dd>Optimizers not aware of atomics can treat this like a nothrow call.  For
+SequentiallyConsistent loads and stores, the same reorderings are allowed as
+for Acquire loads and Release stores, except that SequentiallyConsistent
+operations may not be reordered.</dd>
+<dt>Notes for code generation</dt>
+<dd>SequentiallyConsistent loads minimally require the same barriers as Acquire
+operations and SequentiallyConsistent stores require Release
+barriers. Additionally, the code generator must enforce ordering between
+SequentiallyConsistent stores followed by SequentiallyConsistent loads. This
+is usually done by emitting either a full fence before the loads or a full
+fence after the stores; which is preferred varies by architecture.</dd>
+</dl>
+</div>
+</div>
+<div class="section" id="atomics-and-ir-optimization">
+<h2><a class="toc-backref" href="#id15">Atomics and IR optimization</a><a class="headerlink" href="#atomics-and-ir-optimization" title="Permalink to this headline">¶</a></h2>
+<p>Predicates for optimizer writers to query:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">isSimple()</span></tt>: A load or store which is not volatile or atomic.  This is
+what, for example, memcpyopt would check for operations it might transform.</li>
+<li><tt class="docutils literal"><span class="pre">isUnordered()</span></tt>: A load or store which is not volatile and at most
+Unordered. This would be checked, for example, by LICM before hoisting an
+operation.</li>
+<li><tt class="docutils literal"><span class="pre">mayReadFromMemory()</span></tt>/<tt class="docutils literal"><span class="pre">mayWriteToMemory()</span></tt>: Existing predicate, but note
+that they return true for any operation which is volatile or at least
+Monotonic.</li>
+<li>Alias analysis: Note that AA will return ModRef for anything Acquire or
+Release, and for the address accessed by any Monotonic operation.</li>
+</ul>
+<p>To support optimizing around atomic operations, make sure you are using the
+right predicates; everything should work if that is done.  If your pass should
+optimize some atomic operations (Unordered operations in particular), make sure
+it doesn’t replace an atomic load or store with a non-atomic operation.</p>
+<p>Some examples of how optimizations interact with various kinds of atomic
+operations:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">memcpyopt</span></tt>: An atomic operation cannot be optimized into part of a
+memcpy/memset, including unordered loads/stores.  It can pull operations
+across some atomic operations.</li>
+<li>LICM: Unordered loads/stores can be moved out of a loop.  It just treats
+monotonic operations like a read+write to a memory location, and anything
+stricter than that like a nothrow call.</li>
+<li>DSE: Unordered stores can be DSE’ed like normal stores.  Monotonic stores can
+be DSE’ed in some cases, but it’s tricky to reason about, and not especially
+important.</li>
+<li>Folding a load: Any atomic load from a constant global can be constant-folded,
+because it cannot be observed.  Similar reasoning allows scalarrepl with
+atomic loads and stores.</li>
+</ul>
+</div>
+<div class="section" id="atomics-and-codegen">
+<h2><a class="toc-backref" href="#id16">Atomics and Codegen</a><a class="headerlink" href="#atomics-and-codegen" title="Permalink to this headline">¶</a></h2>
+<p>Atomic operations are represented in the SelectionDAG with <tt class="docutils literal"><span class="pre">ATOMIC_*</span></tt> opcodes.
+On architectures which use barrier instructions for all atomic ordering (like
+ARM), appropriate fences are split out as the DAG is built.</p>
+<p>The MachineMemOperand for all atomic operations is currently marked as volatile;
+this is not correct in the IR sense of volatile, but CodeGen handles anything
+marked volatile very conservatively.  This should get fixed at some point.</p>
+<p>Common architectures have some way of representing at least a pointer-sized
+lock-free <tt class="docutils literal"><span class="pre">cmpxchg</span></tt>; such an operation can be used to implement all the other
+atomic operations which can be represented in IR up to that size.  Backends are
+expected to implement all those operations, but not operations which cannot be
+implemented in a lock-free manner.  It is expected that backends will give an
+error when given an operation which cannot be implemented.  (The LLVM code
+generator is not very helpful here at the moment, but hopefully that will
+change.)</p>
+<p>The implementation of atomics on LL/SC architectures (like ARM) is currently a
+bit of a mess; there is a lot of copy-pasted code across targets, and the
+representation is relatively unsuited to optimization (it would be nice to be
+able to optimize loops involving cmpxchg etc.).</p>
+<p>On x86, all atomic loads generate a <tt class="docutils literal"><span class="pre">MOV</span></tt>. SequentiallyConsistent stores
+generate an <tt class="docutils literal"><span class="pre">XCHG</span></tt>, other stores generate a <tt class="docutils literal"><span class="pre">MOV</span></tt>. SequentiallyConsistent
+fences generate an <tt class="docutils literal"><span class="pre">MFENCE</span></tt>, other fences do not cause any code to be
+generated.  cmpxchg uses the <tt class="docutils literal"><span class="pre">LOCK</span> <span class="pre">CMPXCHG</span></tt> instruction.  <tt class="docutils literal"><span class="pre">atomicrmw</span> <span class="pre">xchg</span></tt>
+uses <tt class="docutils literal"><span class="pre">XCHG</span></tt>, <tt class="docutils literal"><span class="pre">atomicrmw</span> <span class="pre">add</span></tt> and <tt class="docutils literal"><span class="pre">atomicrmw</span> <span class="pre">sub</span></tt> use <tt class="docutils literal"><span class="pre">XADD</span></tt>, and all
+other <tt class="docutils literal"><span class="pre">atomicrmw</span></tt> operations generate a loop with <tt class="docutils literal"><span class="pre">LOCK</span> <span class="pre">CMPXCHG</span></tt>.  Depending
+on the users of the result, some <tt class="docutils literal"><span class="pre">atomicrmw</span></tt> operations can be translated into
+operations like <tt class="docutils literal"><span class="pre">LOCK</span> <span class="pre">AND</span></tt>, but that does not work in general.</p>
+<p>On ARM, MIPS, and many other RISC architectures, Acquire, Release, and
+SequentiallyConsistent semantics require barrier instructions for every such
+operation. Loads and stores generate normal instructions.  <tt class="docutils literal"><span class="pre">cmpxchg</span></tt> and
+<tt class="docutils literal"><span class="pre">atomicrmw</span></tt> can be represented using a loop with LL/SC-style instructions
+which take some sort of exclusive lock on a cache line (<tt class="docutils literal"><span class="pre">LDREX</span></tt> and <tt class="docutils literal"><span class="pre">STREX</span></tt>
+on ARM, etc.). At the moment, the IR does not provide any way to represent a
+weak <tt class="docutils literal"><span class="pre">cmpxchg</span></tt> which would not require a loop.</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="CodingStandards.html" title="LLVM Coding Standards"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="MCJITDesignAndImplementation.html" title="MCJIT Design and Implementation"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/BitCodeFormat.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/BitCodeFormat.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/BitCodeFormat.html (added)
+++ www-releases/trunk/3.4.1/docs/BitCodeFormat.html Wed May  7 15:09:32 2014
@@ -0,0 +1,1014 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>LLVM Bitcode File Format — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="LLVM Branch Weight Metadata" href="BranchWeightMetadata.html" />
+    <link rel="prev" title="LLVM Alias Analysis Infrastructure" href="AliasAnalysis.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="AliasAnalysis.html" title="LLVM Alias Analysis Infrastructure"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-bitcode-file-format">
+<h1>LLVM Bitcode File Format<a class="headerlink" href="#llvm-bitcode-file-format" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id9">Abstract</a></li>
+<li><a class="reference internal" href="#overview" id="id10">Overview</a></li>
+<li><a class="reference internal" href="#bitstream-format" id="id11">Bitstream Format</a><ul>
+<li><a class="reference internal" href="#magic-numbers" id="id12">Magic Numbers</a></li>
+<li><a class="reference internal" href="#primitives" id="id13">Primitives</a><ul>
+<li><a class="reference internal" href="#fixed-width-value" id="id14">Fixed Width Integers</a></li>
+<li><a class="reference internal" href="#variable-width-value" id="id15">Variable Width Integers</a></li>
+<li><a class="reference internal" href="#bit-characters" id="id16">6-bit characters</a></li>
+<li><a class="reference internal" href="#word-alignment" id="id17">Word Alignment</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#abbreviation-ids" id="id18">Abbreviation IDs</a></li>
+<li><a class="reference internal" href="#blocks" id="id19">Blocks</a><ul>
+<li><a class="reference internal" href="#enter-subblock-encoding" id="id20">ENTER_SUBBLOCK Encoding</a></li>
+<li><a class="reference internal" href="#end-block-encoding" id="id21">END_BLOCK Encoding</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#data-records" id="id22">Data Records</a><ul>
+<li><a class="reference internal" href="#unabbrev-record-encoding" id="id23">UNABBREV_RECORD Encoding</a></li>
+<li><a class="reference internal" href="#abbreviated-record-encoding" id="id24">Abbreviated Record Encoding</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#abbreviations" id="id25">Abbreviations</a><ul>
+<li><a class="reference internal" href="#define-abbrev-encoding" id="id26">DEFINE_ABBREV Encoding</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#standard-block" id="id27">Standard Blocks</a><ul>
+<li><a class="reference internal" href="#blockinfo-block" id="id28">#0 - BLOCKINFO Block</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#bitcode-wrapper-format" id="id29">Bitcode Wrapper Format</a></li>
+<li><a class="reference internal" href="#llvm-ir-encoding" id="id30">LLVM IR Encoding</a><ul>
+<li><a class="reference internal" href="#basics" id="id31">Basics</a><ul>
+<li><a class="reference internal" href="#llvm-ir-magic-number" id="id32">LLVM IR Magic Number</a></li>
+<li><a class="reference internal" href="#signed-vbrs" id="id33">Signed VBRs</a></li>
+<li><a class="reference internal" href="#llvm-ir-blocks" id="id34">LLVM IR Blocks</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#module-block-contents" id="id35">MODULE_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#module-code-version-record" id="id36">MODULE_CODE_VERSION Record</a></li>
+<li><a class="reference internal" href="#module-code-triple-record" id="id37">MODULE_CODE_TRIPLE Record</a></li>
+<li><a class="reference internal" href="#module-code-datalayout-record" id="id38">MODULE_CODE_DATALAYOUT Record</a></li>
+<li><a class="reference internal" href="#module-code-asm-record" id="id39">MODULE_CODE_ASM Record</a></li>
+<li><a class="reference internal" href="#module-code-sectionname-record" id="id40">MODULE_CODE_SECTIONNAME Record</a></li>
+<li><a class="reference internal" href="#module-code-deplib-record" id="id41">MODULE_CODE_DEPLIB Record</a></li>
+<li><a class="reference internal" href="#module-code-globalvar-record" id="id42">MODULE_CODE_GLOBALVAR Record</a></li>
+<li><a class="reference internal" href="#module-code-function-record" id="id43">MODULE_CODE_FUNCTION Record</a></li>
+<li><a class="reference internal" href="#module-code-alias-record" id="id44">MODULE_CODE_ALIAS Record</a></li>
+<li><a class="reference internal" href="#module-code-purgevals-record" id="id45">MODULE_CODE_PURGEVALS Record</a></li>
+<li><a class="reference internal" href="#module-code-gcname-record" id="id46">MODULE_CODE_GCNAME Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#paramattr-block-contents" id="id47">PARAMATTR_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#paramattr-code-entry-record" id="id48">PARAMATTR_CODE_ENTRY Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#type-block-contents" id="id49">TYPE_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#type-code-numentry-record" id="id50">TYPE_CODE_NUMENTRY Record</a></li>
+<li><a class="reference internal" href="#type-code-void-record" id="id51">TYPE_CODE_VOID Record</a></li>
+<li><a class="reference internal" href="#type-code-half-record" id="id52">TYPE_CODE_HALF Record</a></li>
+<li><a class="reference internal" href="#type-code-float-record" id="id53">TYPE_CODE_FLOAT Record</a></li>
+<li><a class="reference internal" href="#type-code-double-record" id="id54">TYPE_CODE_DOUBLE Record</a></li>
+<li><a class="reference internal" href="#type-code-label-record" id="id55">TYPE_CODE_LABEL Record</a></li>
+<li><a class="reference internal" href="#type-code-opaque-record" id="id56">TYPE_CODE_OPAQUE Record</a></li>
+<li><a class="reference internal" href="#type-code-integer-record" id="id57">TYPE_CODE_INTEGER Record</a></li>
+<li><a class="reference internal" href="#type-code-pointer-record" id="id58">TYPE_CODE_POINTER Record</a></li>
+<li><a class="reference internal" href="#type-code-function-record" id="id59">TYPE_CODE_FUNCTION Record</a></li>
+<li><a class="reference internal" href="#type-code-struct-record" id="id60">TYPE_CODE_STRUCT Record</a></li>
+<li><a class="reference internal" href="#type-code-array-record" id="id61">TYPE_CODE_ARRAY Record</a></li>
+<li><a class="reference internal" href="#type-code-vector-record" id="id62">TYPE_CODE_VECTOR Record</a></li>
+<li><a class="reference internal" href="#type-code-x86-fp80-record" id="id63">TYPE_CODE_X86_FP80 Record</a></li>
+<li><a class="reference internal" href="#type-code-fp128-record" id="id64">TYPE_CODE_FP128 Record</a></li>
+<li><a class="reference internal" href="#type-code-ppc-fp128-record" id="id65">TYPE_CODE_PPC_FP128 Record</a></li>
+<li><a class="reference internal" href="#type-code-metadata-record" id="id66">TYPE_CODE_METADATA Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#constants-block-contents" id="id67">CONSTANTS_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#function-block-contents" id="id68">FUNCTION_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#type-symtab-block-contents" id="id69">TYPE_SYMTAB_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#tst-code-entry-record" id="id70">TST_CODE_ENTRY Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#value-symtab-block-contents" id="id71">VALUE_SYMTAB_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#metadata-block-contents" id="id72">METADATA_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#metadata-attachment-contents" id="id73">METADATA_ATTACHMENT Contents</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h2><a class="toc-backref" href="#id9">Abstract</a><a class="headerlink" href="#abstract" title="Permalink to this headline">¶</a></h2>
+<p>This document describes the LLVM bitstream file format and the encoding of the
+LLVM IR into it.</p>
+</div>
+<div class="section" id="overview">
+<h2><a class="toc-backref" href="#id10">Overview</a><a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
+<p>What is commonly known as the LLVM bitcode file format (also, sometimes
+anachronistically known as bytecode) is actually two things: a <a class="reference internal" href="#bitstream-container-format">bitstream
+container format</a> and an <a class="reference internal" href="#encoding-of-llvm-ir">encoding of LLVM IR</a> into the container format.</p>
+<p>The bitstream format is an abstract encoding of structured data, very similar to
+XML in some ways.  Like XML, bitstream files contain tags, and nested
+structures, and you can parse the file without having to understand the tags.
+Unlike XML, the bitstream format is a binary encoding, and unlike XML it
+provides a mechanism for the file to self-describe “abbreviations”, which are
+effectively size optimizations for the content.</p>
+<p>LLVM IR files may be optionally embedded into a <a class="reference internal" href="#wrapper">wrapper</a> structure that makes
+it easy to embed extra data along with LLVM IR files.</p>
+<p>This document first describes the LLVM bitstream format, describes the wrapper
+format, then describes the record structure used by LLVM IR files.</p>
+</div>
+<div class="section" id="bitstream-format">
+<span id="bitstream-container-format"></span><h2><a class="toc-backref" href="#id11">Bitstream Format</a><a class="headerlink" href="#bitstream-format" title="Permalink to this headline">¶</a></h2>
+<p>The bitstream format is literally a stream of bits, with a very simple
+structure.  This structure consists of the following concepts:</p>
+<ul class="simple">
+<li>A “<a class="reference internal" href="#magic-number">magic number</a>” that identifies the contents of the stream.</li>
+<li>Encoding <a class="reference internal" href="#primitives">primitives</a> like variable bit-rate integers.</li>
+<li><a class="reference internal" href="#blocks">Blocks</a>, which define nested content.</li>
+<li><a class="reference internal" href="#data-records">Data Records</a>, which describe entities within the file.</li>
+<li>Abbreviations, which specify compression optimizations for the file.</li>
+</ul>
+<p>Note that the <a class="reference internal" href="CommandGuide/llvm-bcanalyzer.html"><em>llvm-bcanalyzer</em></a> tool can be
+used to dump and inspect arbitrary bitstreams, which is very useful for
+understanding the encoding.</p>
+<div class="section" id="magic-numbers">
+<span id="magic-number"></span><h3><a class="toc-backref" href="#id12">Magic Numbers</a><a class="headerlink" href="#magic-numbers" title="Permalink to this headline">¶</a></h3>
+<p>The first two bytes of a bitcode file are ‘BC’ (<tt class="docutils literal"><span class="pre">0x42</span></tt>, <tt class="docutils literal"><span class="pre">0x43</span></tt>).  The second
+two bytes are an application-specific magic number.  Generic bitcode tools can
+look at only the first two bytes to verify the file is bitcode, while
+application-specific programs will want to look at all four.</p>
+</div>
+<div class="section" id="primitives">
+<span id="id1"></span><h3><a class="toc-backref" href="#id13">Primitives</a><a class="headerlink" href="#primitives" title="Permalink to this headline">¶</a></h3>
+<p>A bitstream literally consists of a stream of bits, which are read in order
+starting with the least significant bit of each byte.  The stream is made up of
+a number of primitive values that encode a stream of unsigned integer values.
+These integers are encoded in two ways: either as <a class="reference internal" href="#fixed-width-integers">Fixed Width Integers</a> or as
+<a class="reference internal" href="#variable-width-integers">Variable Width Integers</a>.</p>
+<div class="section" id="fixed-width-value">
+<span id="fixed-width-integers"></span><span id="id2"></span><h4><a class="toc-backref" href="#id14">Fixed Width Integers</a><a class="headerlink" href="#fixed-width-value" title="Permalink to this headline">¶</a></h4>
+<p>Fixed-width integer values have their low bits emitted directly to the file.
+For example, a 3-bit integer value encodes 1 as 001.  Fixed width integers are
+used when there are a well-known number of options for a field.  For example,
+boolean values are usually encoded with a 1-bit wide integer.</p>
+</div>
+<div class="section" id="variable-width-value">
+<span id="variable-width-integer"></span><span id="variable-width-integers"></span><span id="id3"></span><h4><a class="toc-backref" href="#id15">Variable Width Integers</a><a class="headerlink" href="#variable-width-value" title="Permalink to this headline">¶</a></h4>
+<p>Variable-width integer (VBR) values encode values of arbitrary size, optimizing
+for the case where the values are small.  Given a 4-bit VBR field, any 3-bit
+value (0 through 7) is encoded directly, with the high bit set to zero.  Values
+larger than N-1 bits emit their bits in a series of N-1 bit chunks, where all
+but the last set the high bit.</p>
+<p>For example, the value 27 (0x1B) is encoded as 1011 0011 when emitted as a vbr4
+value.  The first set of four bits indicates the value 3 (011) with a
+continuation piece (indicated by a high bit of 1).  The next word indicates a
+value of 24 (011 << 3) with no continuation.  The sum (3+24) yields the value
+27.</p>
+</div>
+<div class="section" id="bit-characters">
+<span id="char6-encoded-value"></span><h4><a class="toc-backref" href="#id16">6-bit characters</a><a class="headerlink" href="#bit-characters" title="Permalink to this headline">¶</a></h4>
+<p>6-bit characters encode common characters into a fixed 6-bit field.  They
+represent the following characters with the following 6-bit values:</p>
+<div class="highlight-python"><pre>'a' .. 'z' ---  0 .. 25
+'A' .. 'Z' --- 26 .. 51
+'0' .. '9' --- 52 .. 61
+       '.' --- 62
+       '_' --- 63</pre>
+</div>
+<p>This encoding is only suitable for encoding characters and strings that consist
+only of the above characters.  It is completely incapable of encoding characters
+not in the set.</p>
+</div>
+<div class="section" id="word-alignment">
+<h4><a class="toc-backref" href="#id17">Word Alignment</a><a class="headerlink" href="#word-alignment" title="Permalink to this headline">¶</a></h4>
+<p>Occasionally, it is useful to emit zero bits until the bitstream is a multiple
+of 32 bits.  This ensures that the bit position in the stream can be represented
+as a multiple of 32-bit words.</p>
+</div>
+</div>
+<div class="section" id="abbreviation-ids">
+<h3><a class="toc-backref" href="#id18">Abbreviation IDs</a><a class="headerlink" href="#abbreviation-ids" title="Permalink to this headline">¶</a></h3>
+<p>A bitstream is a sequential series of <a class="reference internal" href="#blocks">Blocks</a> and <a class="reference internal" href="#data-records">Data Records</a>.  Both of
+these start with an abbreviation ID encoded as a fixed-bitwidth field.  The
+width is specified by the current block, as described below.  The value of the
+abbreviation ID specifies either a builtin ID (which have special meanings,
+defined below) or one of the abbreviation IDs defined for the current block by
+the stream itself.</p>
+<p>The set of builtin abbrev IDs is:</p>
+<ul class="simple">
+<li>0 - <a class="reference internal" href="#end-block">END_BLOCK</a> — This abbrev ID marks the end of the current block.</li>
+<li>1 - <a class="reference internal" href="#enter-subblock">ENTER_SUBBLOCK</a> — This abbrev ID marks the beginning of a new
+block.</li>
+<li>2 - <a class="reference internal" href="#define-abbrev">DEFINE_ABBREV</a> — This defines a new abbreviation.</li>
+<li>3 - <a class="reference internal" href="#unabbrev-record">UNABBREV_RECORD</a> — This ID specifies the definition of an
+unabbreviated record.</li>
+</ul>
+<p>Abbreviation IDs 4 and above are defined by the stream itself, and specify an
+<a class="reference internal" href="#abbreviated-record-encoding">abbreviated record encoding</a>.</p>
+</div>
+<div class="section" id="blocks">
+<span id="id4"></span><h3><a class="toc-backref" href="#id19">Blocks</a><a class="headerlink" href="#blocks" title="Permalink to this headline">¶</a></h3>
+<p>Blocks in a bitstream denote nested regions of the stream, and are identified by
+a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
+function bodies).  Block IDs 0-7 are reserved for <a class="reference internal" href="#standard-blocks">standard blocks</a> whose
+meaning is defined by Bitcode; block IDs 8 and greater are application
+specific. Nested blocks capture the hierarchical structure of the data encoded
+in it, and various properties are associated with blocks as the file is parsed.
+Block definitions allow the reader to efficiently skip blocks in constant time
+if the reader wants a summary of blocks, or if it wants to efficiently skip data
+it does not understand.  The LLVM IR reader uses this mechanism to skip function
+bodies, lazily reading them on demand.</p>
+<p>When reading and encoding the stream, several properties are maintained for the
+block.  In particular, each block maintains:</p>
+<ol class="arabic simple">
+<li>A current abbrev id width.  This value starts at 2 at the beginning of the
+stream, and is set every time a block record is entered.  The block entry
+specifies the abbrev id width for the body of the block.</li>
+<li>A set of abbreviations.  Abbreviations may be defined within a block, in
+which case they are only defined in that block (neither subblocks nor
+enclosing blocks see the abbreviation).  Abbreviations can also be defined
+inside a <a class="reference internal" href="#blockinfo">BLOCKINFO</a> block, in which case they are defined in all blocks
+that match the ID that the <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> block is describing.</li>
+</ol>
+<p>As sub blocks are entered, these properties are saved and the new sub-block has
+its own set of abbreviations, and its own abbrev id width.  When a sub-block is
+popped, the saved values are restored.</p>
+<div class="section" id="enter-subblock-encoding">
+<span id="enter-subblock"></span><h4><a class="toc-backref" href="#id20">ENTER_SUBBLOCK Encoding</a><a class="headerlink" href="#enter-subblock-encoding" title="Permalink to this headline">¶</a></h4>
+<p><span class="raw-html"><tt></span>
+[ENTER_SUBBLOCK, blockid<sub>vbr8</sub>, newabbrevlen<sub>vbr4</sub>, <align32bits>, blocklen_32]
+<span class="raw-html"></tt></span></p>
+<p>The <tt class="docutils literal"><span class="pre">ENTER_SUBBLOCK</span></tt> abbreviation ID specifies the start of a new block
+record.  The <tt class="docutils literal"><span class="pre">blockid</span></tt> value is encoded as an 8-bit VBR identifier, and
+indicates the type of block being entered, which can be a <a class="reference internal" href="#standard-block">standard block</a> or
+an application-specific block.  The <tt class="docutils literal"><span class="pre">newabbrevlen</span></tt> value is a 4-bit VBR, which
+specifies the abbrev id width for the sub-block.  The <tt class="docutils literal"><span class="pre">blocklen</span></tt> value is a
+32-bit aligned value that specifies the size of the subblock in 32-bit
+words. This value allows the reader to skip over the entire block in one jump.</p>
+</div>
+<div class="section" id="end-block-encoding">
+<span id="end-block"></span><h4><a class="toc-backref" href="#id21">END_BLOCK Encoding</a><a class="headerlink" href="#end-block-encoding" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[END_BLOCK,</span> <span class="pre"><align32bits>]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">END_BLOCK</span></tt> abbreviation ID specifies the end of the current block record.
+Its end is aligned to 32-bits to ensure that the size of the block is an even
+multiple of 32-bits.</p>
+</div>
+</div>
+<div class="section" id="data-records">
+<span id="id5"></span><h3><a class="toc-backref" href="#id22">Data Records</a><a class="headerlink" href="#data-records" title="Permalink to this headline">¶</a></h3>
+<p>Data records consist of a record code and a number of (up to) 64-bit integer
+values.  The interpretation of the code and values is application specific and
+may vary between different block types.  Records can be encoded either using an
+unabbrev record, or with an abbreviation.  In the LLVM IR format, for example,
+there is a record which encodes the target triple of a module.  The code is
+<tt class="docutils literal"><span class="pre">MODULE_CODE_TRIPLE</span></tt>, and the values of the record are the ASCII codes for the
+characters in the string.</p>
+<div class="section" id="unabbrev-record-encoding">
+<span id="unabbrev-record"></span><h4><a class="toc-backref" href="#id23">UNABBREV_RECORD Encoding</a><a class="headerlink" href="#unabbrev-record-encoding" title="Permalink to this headline">¶</a></h4>
+<p><span class="raw-html"><tt></span>
+[UNABBREV_RECORD, code<sub>vbr6</sub>, numops<sub>vbr6</sub>, op0<sub>vbr6</sub>, op1<sub>vbr6</sub>, ...]
+<span class="raw-html"></tt></span></p>
+<p>An <tt class="docutils literal"><span class="pre">UNABBREV_RECORD</span></tt> provides a default fallback encoding, which is both
+completely general and extremely inefficient.  It can describe an arbitrary
+record by emitting the code and operands as VBRs.</p>
+<p>For example, emitting an LLVM IR target triple as an unabbreviated record
+requires emitting the <tt class="docutils literal"><span class="pre">UNABBREV_RECORD</span></tt> abbrevid, a vbr6 for the
+<tt class="docutils literal"><span class="pre">MODULE_CODE_TRIPLE</span></tt> code, a vbr6 for the length of the string, which is equal
+to the number of operands, and a vbr6 for each character.  Because there are no
+letters with values less than 32, each letter would need to be emitted as at
+least a two-part VBR, which means that each letter would require at least 12
+bits.  This is not an efficient encoding, but it is fully general.</p>
+</div>
+<div class="section" id="abbreviated-record-encoding">
+<span id="id6"></span><h4><a class="toc-backref" href="#id24">Abbreviated Record Encoding</a><a class="headerlink" href="#abbreviated-record-encoding" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[<abbrevid>,</span> <span class="pre">fields...]</span></tt></p>
+<p>An abbreviated record is a abbreviation id followed by a set of fields that are
+encoded according to the <a class="reference internal" href="#abbreviation-definition">abbreviation definition</a>.  This allows records to be
+encoded significantly more densely than records encoded with the
+<a class="reference internal" href="#unabbrev-record">UNABBREV_RECORD</a> type, and allows the abbreviation types to be specified in
+the stream itself, which allows the files to be completely self describing.  The
+actual encoding of abbreviations is defined below.</p>
+<p>The record code, which is the first field of an abbreviated record, may be
+encoded in the abbreviation definition (as a literal operand) or supplied in the
+abbreviated record (as a Fixed or VBR operand value).</p>
+</div>
+</div>
+<div class="section" id="abbreviations">
+<span id="abbreviation-definition"></span><h3><a class="toc-backref" href="#id25">Abbreviations</a><a class="headerlink" href="#abbreviations" title="Permalink to this headline">¶</a></h3>
+<p>Abbreviations are an important form of compression for bitstreams.  The idea is
+to specify a dense encoding for a class of records once, then use that encoding
+to emit many records.  It takes space to emit the encoding into the file, but
+the space is recouped (hopefully plus some) when the records that use it are
+emitted.</p>
+<p>Abbreviations can be determined dynamically per client, per file. Because the
+abbreviations are stored in the bitstream itself, different streams of the same
+format can contain different sets of abbreviations according to the needs of the
+specific stream.  As a concrete example, LLVM IR files usually emit an
+abbreviation for binary operators.  If a specific LLVM module contained no or
+few binary operators, the abbreviation does not need to be emitted.</p>
+<div class="section" id="define-abbrev-encoding">
+<span id="define-abbrev"></span><h4><a class="toc-backref" href="#id26">DEFINE_ABBREV Encoding</a><a class="headerlink" href="#define-abbrev-encoding" title="Permalink to this headline">¶</a></h4>
+<p><span class="raw-html"><tt></span>
+[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1, ...]
+<span class="raw-html"></tt></span></p>
+<p>A <tt class="docutils literal"><span class="pre">DEFINE_ABBREV</span></tt> record adds an abbreviation to the list of currently defined
+abbreviations in the scope of this block.  This definition only exists inside
+this immediate block — it is not visible in subblocks or enclosing blocks.
+Abbreviations are implicitly assigned IDs sequentially starting from 4 (the
+first application-defined abbreviation ID).  Any abbreviations defined in a
+<tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> record for the particular block type receive IDs first, in order,
+followed by any abbreviations defined within the block itself.  Abbreviated data
+records reference this ID to indicate what abbreviation they are invoking.</p>
+<p>An abbreviation definition consists of the <tt class="docutils literal"><span class="pre">DEFINE_ABBREV</span></tt> abbrevid followed
+by a VBR that specifies the number of abbrev operands, then the abbrev operands
+themselves.  Abbreviation operands come in three forms.  They all start with a
+single bit that indicates whether the abbrev operand is a literal operand (when
+the bit is 1) or an encoding operand (when the bit is 0).</p>
+<ol class="arabic simple">
+<li>Literal operands — <span class="raw-html"><tt></span> [1<sub>1</sub>, litvalue<sub>vbr8</sub>] <span class="raw-html"></tt></span> — Literal operands specify that the value in
+the result is always a single specific value.  This specific value is emitted
+as a vbr8 after the bit indicating that it is a literal operand.</li>
+<li>Encoding info without data — <span class="raw-html"><tt></span> [0<sub>1</sub>, encoding<sub>3</sub>] <span class="raw-html"></tt></span> — Operand encodings that do not have extra data
+are just emitted as their code.</li>
+<li>Encoding info with data — <span class="raw-html"><tt></span> [0<sub>1</sub>, encoding<sub>3</sub>, value<sub>vbr5</sub>] <span class="raw-html"></tt></span> — Operand encodings that do
+have extra data are emitted as their code, followed by the extra data.</li>
+</ol>
+<p>The possible operand encodings are:</p>
+<ul class="simple">
+<li>Fixed (code 1): The field should be emitted as a <a class="reference internal" href="#fixed-width-value">fixed-width value</a>, whose
+width is specified by the operand’s extra data.</li>
+<li>VBR (code 2): The field should be emitted as a <a class="reference internal" href="#variable-width-value">variable-width value</a>, whose
+width is specified by the operand’s extra data.</li>
+<li>Array (code 3): This field is an array of values.  The array operand has no
+extra data, but expects another operand to follow it, indicating the element
+type of the array.  When reading an array in an abbreviated record, the first
+integer is a vbr6 that indicates the array length, followed by the encoded
+elements of the array.  An array may only occur as the last operand of an
+abbreviation (except for the one final operand that gives the array’s
+type).</li>
+<li>Char6 (code 4): This field should be emitted as a <a class="reference internal" href="#char6-encoded-value">char6-encoded value</a>.
+This operand type takes no extra data. Char6 encoding is normally used as an
+array element type.</li>
+<li>Blob (code 5): This field is emitted as a vbr6, followed by padding to a
+32-bit boundary (for alignment) and an array of 8-bit objects.  The array of
+bytes is further followed by tail padding to ensure that its total length is a
+multiple of 4 bytes.  This makes it very efficient for the reader to decode
+the data without having to make a copy of it: it can use a pointer to the data
+in the mapped in file and poke directly at it.  A blob may only occur as the
+last operand of an abbreviation.</li>
+</ul>
+<p>For example, target triples in LLVM modules are encoded as a record of the form
+<tt class="docutils literal"><span class="pre">[TRIPLE,</span> <span class="pre">'a',</span> <span class="pre">'b',</span> <span class="pre">'c',</span> <span class="pre">'d']</span></tt>.  Consider if the bitstream emitted the
+following abbrev entry:</p>
+<div class="highlight-python"><div class="highlight"><pre><span class="p">[</span><span class="mi">0</span><span class="p">,</span> <span class="n">Fixed</span><span class="p">,</span> <span class="mi">4</span><span class="p">]</span>
+<span class="p">[</span><span class="mi">0</span><span class="p">,</span> <span class="n">Array</span><span class="p">]</span>
+<span class="p">[</span><span class="mi">0</span><span class="p">,</span> <span class="n">Char6</span><span class="p">]</span>
+</pre></div>
+</div>
+<p>When emitting a record with this abbreviation, the above entry would be emitted
+as:</p>
+<p><span class="raw-html"><tt><blockquote></span>
+[4<sub>abbrevwidth</sub>, 2<sub>4</sub>, 4<sub>vbr6</sub>, 0<sub>6</sub>, 1<sub>6</sub>, 2<sub>6</sub>, 3<sub>6</sub>]
+<span class="raw-html"></blockquote></tt></span></p>
+<p>These values are:</p>
+<ol class="arabic simple">
+<li>The first value, 4, is the abbreviation ID for this abbreviation.</li>
+<li>The second value, 2, is the record code for <tt class="docutils literal"><span class="pre">TRIPLE</span></tt> records within LLVM IR
+file <tt class="docutils literal"><span class="pre">MODULE_BLOCK</span></tt> blocks.</li>
+<li>The third value, 4, is the length of the array.</li>
+<li>The rest of the values are the char6 encoded values for <tt class="docutils literal"><span class="pre">"abcd"</span></tt>.</li>
+</ol>
+<p>With this abbreviation, the triple is emitted with only 37 bits (assuming a
+abbrev id width of 3).  Without the abbreviation, significantly more space would
+be required to emit the target triple.  Also, because the <tt class="docutils literal"><span class="pre">TRIPLE</span></tt> value is
+not emitted as a literal in the abbreviation, the abbreviation can also be used
+for any other string value.</p>
+</div>
+</div>
+<div class="section" id="standard-block">
+<span id="standard-blocks"></span><span id="id7"></span><h3><a class="toc-backref" href="#id27">Standard Blocks</a><a class="headerlink" href="#standard-block" title="Permalink to this headline">¶</a></h3>
+<p>In addition to the basic block structure and record encodings, the bitstream
+also defines specific built-in block types.  These block types specify how the
+stream is to be decoded or other metadata.  In the future, new standard blocks
+may be added.  Block IDs 0-7 are reserved for standard blocks.</p>
+<div class="section" id="blockinfo-block">
+<span id="blockinfo"></span><h4><a class="toc-backref" href="#id28">#0 - BLOCKINFO Block</a><a class="headerlink" href="#blockinfo-block" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> block allows the description of metadata for other blocks.
+The currently specified records are:</p>
+<div class="highlight-python"><pre>[SETBID (#1), blockid]
+[DEFINE_ABBREV, ...]
+[BLOCKNAME, ...name...]
+[SETRECORDNAME, RecordID, ...name...]</pre>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">SETBID</span></tt> record (code 1) indicates which block ID is being described.
+<tt class="docutils literal"><span class="pre">SETBID</span></tt> records can occur multiple times throughout the block to change which
+block ID is being described.  There must be a <tt class="docutils literal"><span class="pre">SETBID</span></tt> record prior to any
+other records.</p>
+<p>Standard <tt class="docutils literal"><span class="pre">DEFINE_ABBREV</span></tt> records can occur inside <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> blocks, but
+unlike their occurrence in normal blocks, the abbreviation is defined for blocks
+matching the block ID we are describing, <em>not</em> the <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> block
+itself.  The abbreviations defined in <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> blocks receive abbreviation
+IDs as described in <a class="reference internal" href="#define-abbrev">DEFINE_ABBREV</a>.</p>
+<p>The <tt class="docutils literal"><span class="pre">BLOCKNAME</span></tt> record (code 2) can optionally occur in this block.  The
+elements of the record are the bytes of the string name of the block.
+llvm-bcanalyzer can use this to dump out bitcode files symbolically.</p>
+<p>The <tt class="docutils literal"><span class="pre">SETRECORDNAME</span></tt> record (code 3) can also optionally occur in this block.
+The first operand value is a record ID number, and the rest of the elements of
+the record are the bytes for the string name of the record.  llvm-bcanalyzer can
+use this to dump out bitcode files symbolically.</p>
+<p>Note that although the data in <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> blocks is described as “metadata,”
+the abbreviations they contain are essential for parsing records from the
+corresponding blocks.  It is not safe to skip them.</p>
+</div>
+</div>
+</div>
+<div class="section" id="bitcode-wrapper-format">
+<span id="wrapper"></span><h2><a class="toc-backref" href="#id29">Bitcode Wrapper Format</a><a class="headerlink" href="#bitcode-wrapper-format" title="Permalink to this headline">¶</a></h2>
+<p>Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper
+structure.  This structure contains a simple header that indicates the offset
+and size of the embedded BC file.  This allows additional information to be
+stored alongside the BC file.  The structure of this file header is:</p>
+<p><span class="raw-html"><tt><blockquote></span>
+[Magic<sub>32</sub>, Version<sub>32</sub>, Offset<sub>32</sub>, Size<sub>32</sub>, CPUType<sub>32</sub>]
+<span class="raw-html"></blockquote></tt></span></p>
+<p>Each of the fields are 32-bit fields stored in little endian form (as with the
+rest of the bitcode file fields).  The Magic number is always <tt class="docutils literal"><span class="pre">0x0B17C0DE</span></tt> and
+the version is currently always <tt class="docutils literal"><span class="pre">0</span></tt>.  The Offset field is the offset in bytes
+to the start of the bitcode stream in the file, and the Size field is the size
+in bytes of the stream. CPUType is a target-specific value that can be used to
+encode the CPU of the target.</p>
+</div>
+<div class="section" id="llvm-ir-encoding">
+<span id="encoding-of-llvm-ir"></span><h2><a class="toc-backref" href="#id30">LLVM IR Encoding</a><a class="headerlink" href="#llvm-ir-encoding" title="Permalink to this headline">¶</a></h2>
+<p>LLVM IR is encoded into a bitstream by defining blocks and records.  It uses
+blocks for things like constant pools, functions, symbol tables, etc.  It uses
+records for things like instructions, global variable descriptors, type
+descriptions, etc.  This document does not describe the set of abbreviations
+that the writer uses, as these are fully self-described in the file, and the
+reader is not allowed to build in any knowledge of this.</p>
+<div class="section" id="basics">
+<h3><a class="toc-backref" href="#id31">Basics</a><a class="headerlink" href="#basics" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="llvm-ir-magic-number">
+<h4><a class="toc-backref" href="#id32">LLVM IR Magic Number</a><a class="headerlink" href="#llvm-ir-magic-number" title="Permalink to this headline">¶</a></h4>
+<p>The magic number for LLVM IR files is:</p>
+<p><span class="raw-html"><tt><blockquote></span>
+[0x0<sub>4</sub>, 0xC<sub>4</sub>, 0xE<sub>4</sub>, 0xD<sub>4</sub>]
+<span class="raw-html"></blockquote></tt></span></p>
+<p>When combined with the bitcode magic number and viewed as bytes, this is
+<tt class="docutils literal"><span class="pre">"BC</span> <span class="pre">0xC0DE"</span></tt>.</p>
+</div>
+<div class="section" id="signed-vbrs">
+<span id="id8"></span><h4><a class="toc-backref" href="#id33">Signed VBRs</a><a class="headerlink" href="#signed-vbrs" title="Permalink to this headline">¶</a></h4>
+<p><a class="reference internal" href="#variable-width-integer">Variable Width Integer</a> encoding is an efficient way to encode arbitrary sized
+unsigned values, but is an extremely inefficient for encoding signed values, as
+signed values are otherwise treated as maximally large unsigned values.</p>
+<p>As such, signed VBR values of a specific width are emitted as follows:</p>
+<ul class="simple">
+<li>Positive values are emitted as VBRs of the specified width, but with their
+value shifted left by one.</li>
+<li>Negative values are emitted as VBRs of the specified width, but the negated
+value is shifted left by one, and the low bit is set.</li>
+</ul>
+<p>With this encoding, small positive and small negative values can both be emitted
+efficiently. Signed VBR encoding is used in <tt class="docutils literal"><span class="pre">CST_CODE_INTEGER</span></tt> and
+<tt class="docutils literal"><span class="pre">CST_CODE_WIDE_INTEGER</span></tt> records within <tt class="docutils literal"><span class="pre">CONSTANTS_BLOCK</span></tt> blocks.
+It is also used for phi instruction operands in <a class="reference internal" href="#module-code-version">MODULE_CODE_VERSION</a> 1.</p>
+</div>
+<div class="section" id="llvm-ir-blocks">
+<h4><a class="toc-backref" href="#id34">LLVM IR Blocks</a><a class="headerlink" href="#llvm-ir-blocks" title="Permalink to this headline">¶</a></h4>
+<p>LLVM IR is defined with the following blocks:</p>
+<ul class="simple">
+<li>8 — <a class="reference internal" href="#module-block">MODULE_BLOCK</a> — This is the top-level block that contains the entire
+module, and describes a variety of per-module information.</li>
+<li>9 — <a class="reference internal" href="#paramattr-block">PARAMATTR_BLOCK</a> — This enumerates the parameter attributes.</li>
+<li>10 — <a class="reference internal" href="#type-block">TYPE_BLOCK</a> — This describes all of the types in the module.</li>
+<li>11 — <a class="reference internal" href="#constants-block">CONSTANTS_BLOCK</a> — This describes constants for a module or
+function.</li>
+<li>12 — <a class="reference internal" href="#function-block">FUNCTION_BLOCK</a> — This describes a function body.</li>
+<li>13 — <a class="reference internal" href="#type-symtab-block">TYPE_SYMTAB_BLOCK</a> — This describes the type symbol table.</li>
+<li>14 — <a class="reference internal" href="#value-symtab-block">VALUE_SYMTAB_BLOCK</a> — This describes a value symbol table.</li>
+<li>15 — <a class="reference internal" href="#metadata-block">METADATA_BLOCK</a> — This describes metadata items.</li>
+<li>16 — <a class="reference internal" href="#metadata-attachment">METADATA_ATTACHMENT</a> — This contains records associating metadata
+with function instruction values.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="module-block-contents">
+<span id="module-block"></span><h3><a class="toc-backref" href="#id35">MODULE_BLOCK Contents</a><a class="headerlink" href="#module-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MODULE_BLOCK</span></tt> block (id 8) is the top-level block for LLVM bitcode files,
+and each bitcode file must contain exactly one. In addition to records
+(described below) containing information about the module, a <tt class="docutils literal"><span class="pre">MODULE_BLOCK</span></tt>
+block may contain the following sub-blocks:</p>
+<ul class="simple">
+<li><a class="reference internal" href="#blockinfo">BLOCKINFO</a></li>
+<li><a class="reference internal" href="#paramattr-block">PARAMATTR_BLOCK</a></li>
+<li><a class="reference internal" href="#type-block">TYPE_BLOCK</a></li>
+<li><a class="reference internal" href="#type-symtab-block">TYPE_SYMTAB_BLOCK</a></li>
+<li><a class="reference internal" href="#value-symtab-block">VALUE_SYMTAB_BLOCK</a></li>
+<li><a class="reference internal" href="#constants-block">CONSTANTS_BLOCK</a></li>
+<li><a class="reference internal" href="#function-block">FUNCTION_BLOCK</a></li>
+<li><a class="reference internal" href="#metadata-block">METADATA_BLOCK</a></li>
+</ul>
+<div class="section" id="module-code-version-record">
+<span id="module-code-version"></span><h4><a class="toc-backref" href="#id36">MODULE_CODE_VERSION Record</a><a class="headerlink" href="#module-code-version-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[VERSION,</span> <span class="pre">version#]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">VERSION</span></tt> record (code 1) contains a single value indicating the format
+version. Versions 0 and 1 are supported at this time. The difference between
+version 0 and 1 is in the encoding of instruction operands in
+each <a class="reference internal" href="#function-block">FUNCTION_BLOCK</a>.</p>
+<p>In version 0, each value defined by an instruction is assigned an ID
+unique to the function. Function-level value IDs are assigned starting from
+<tt class="docutils literal"><span class="pre">NumModuleValues</span></tt> since they share the same namespace as module-level
+values. The value enumerator resets after each function. When a value is
+an operand of an instruction, the value ID is used to represent the operand.
+For large functions or large modules, these operand values can be large.</p>
+<p>The encoding in version 1 attempts to avoid large operand values
+in common cases. Instead of using the value ID directly, operands are
+encoded as relative to the current instruction. Thus, if an operand
+is the value defined by the previous instruction, the operand
+will be encoded as 1.</p>
+<p>For example, instead of</p>
+<div class="highlight-llvm"><pre>#n = load #n-1
+#n+1 = icmp eq #n, #const0
+br #n+1, label #(bb1), label #(bb2)</pre>
+</div>
+<p>version 1 will encode the instructions as</p>
+<div class="highlight-llvm"><pre>#n = load #1
+#n+1 = icmp eq #1, (#n+1)-#const0
+br #1, label #(bb1), label #(bb2)</pre>
+</div>
+<p>Note in the example that operands which are constants also use
+the relative encoding, while operands like basic block labels
+do not use the relative encoding.</p>
+<p>Forward references will result in a negative value.
+This can be inefficient, as operands are normally encoded
+as unsigned VBRs. However, forward references are rare, except in the
+case of phi instructions. For phi instructions, operands are encoded as
+<a class="reference internal" href="#signed-vbrs">Signed VBRs</a> to deal with forward references.</p>
+</div>
+<div class="section" id="module-code-triple-record">
+<h4><a class="toc-backref" href="#id37">MODULE_CODE_TRIPLE Record</a><a class="headerlink" href="#module-code-triple-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[TRIPLE,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">TRIPLE</span></tt> record (code 2) contains a variable number of values representing
+the bytes of the <tt class="docutils literal"><span class="pre">target</span> <span class="pre">triple</span></tt> specification string.</p>
+</div>
+<div class="section" id="module-code-datalayout-record">
+<h4><a class="toc-backref" href="#id38">MODULE_CODE_DATALAYOUT Record</a><a class="headerlink" href="#module-code-datalayout-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[DATALAYOUT,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">DATALAYOUT</span></tt> record (code 3) contains a variable number of values
+representing the bytes of the <tt class="docutils literal"><span class="pre">target</span> <span class="pre">datalayout</span></tt> specification string.</p>
+</div>
+<div class="section" id="module-code-asm-record">
+<h4><a class="toc-backref" href="#id39">MODULE_CODE_ASM Record</a><a class="headerlink" href="#module-code-asm-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ASM,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ASM</span></tt> record (code 4) contains a variable number of values representing
+the bytes of <tt class="docutils literal"><span class="pre">module</span> <span class="pre">asm</span></tt> strings, with individual assembly blocks separated
+by newline (ASCII 10) characters.</p>
+</div>
+<div class="section" id="module-code-sectionname-record">
+<span id="module-code-sectionname"></span><h4><a class="toc-backref" href="#id40">MODULE_CODE_SECTIONNAME Record</a><a class="headerlink" href="#module-code-sectionname-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[SECTIONNAME,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">SECTIONNAME</span></tt> record (code 5) contains a variable number of values
+representing the bytes of a single section name string. There should be one
+<tt class="docutils literal"><span class="pre">SECTIONNAME</span></tt> record for each section name referenced (e.g., in global
+variable or function <tt class="docutils literal"><span class="pre">section</span></tt> attributes) within the module. These records
+can be referenced by the 1-based index in the <em>section</em> fields of <tt class="docutils literal"><span class="pre">GLOBALVAR</span></tt>
+or <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> records.</p>
+</div>
+<div class="section" id="module-code-deplib-record">
+<h4><a class="toc-backref" href="#id41">MODULE_CODE_DEPLIB Record</a><a class="headerlink" href="#module-code-deplib-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[DEPLIB,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">DEPLIB</span></tt> record (code 6) contains a variable number of values representing
+the bytes of a single dependent library name string, one of the libraries
+mentioned in a <tt class="docutils literal"><span class="pre">deplibs</span></tt> declaration.  There should be one <tt class="docutils literal"><span class="pre">DEPLIB</span></tt> record
+for each library name referenced.</p>
+</div>
+<div class="section" id="module-code-globalvar-record">
+<h4><a class="toc-backref" href="#id42">MODULE_CODE_GLOBALVAR Record</a><a class="headerlink" href="#module-code-globalvar-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[GLOBALVAR,</span> <span class="pre">pointer</span> <span class="pre">type,</span> <span class="pre">isconst,</span> <span class="pre">initid,</span> <span class="pre">linkage,</span> <span class="pre">alignment,</span> <span class="pre">section,</span> <span class="pre">visibility,</span> <span class="pre">threadlocal,</span> <span class="pre">unnamed_addr]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">GLOBALVAR</span></tt> record (code 7) marks the declaration or definition of a
+global variable. The operand fields are:</p>
+<ul class="simple">
+<li><em>pointer type</em>: The type index of the pointer type used to point to this
+global variable</li>
+<li><em>isconst</em>: Non-zero if the variable is treated as constant within the module,
+or zero if it is not</li>
+<li><em>initid</em>: If non-zero, the value index of the initializer for this variable,
+plus 1.</li>
+</ul>
+<ul class="simple" id="linkage-type">
+<li><em>linkage</em>: An encoding of the linkage type for this variable:
+* <tt class="docutils literal"><span class="pre">external</span></tt>: code 0
+* <tt class="docutils literal"><span class="pre">weak</span></tt>: code 1
+* <tt class="docutils literal"><span class="pre">appending</span></tt>: code 2
+* <tt class="docutils literal"><span class="pre">internal</span></tt>: code 3
+* <tt class="docutils literal"><span class="pre">linkonce</span></tt>: code 4
+* <tt class="docutils literal"><span class="pre">dllimport</span></tt>: code 5
+* <tt class="docutils literal"><span class="pre">dllexport</span></tt>: code 6
+* <tt class="docutils literal"><span class="pre">extern_weak</span></tt>: code 7
+* <tt class="docutils literal"><span class="pre">common</span></tt>: code 8
+* <tt class="docutils literal"><span class="pre">private</span></tt>: code 9
+* <tt class="docutils literal"><span class="pre">weak_odr</span></tt>: code 10
+* <tt class="docutils literal"><span class="pre">linkonce_odr</span></tt>: code 11
+* <tt class="docutils literal"><span class="pre">available_externally</span></tt>: code 12
+* <tt class="docutils literal"><span class="pre">linker_private</span></tt>: code 13</li>
+<li>alignment*: The logarithm base 2 of the variable’s requested alignment, plus 1</li>
+<li><em>section</em>: If non-zero, the 1-based section index in the table of
+<a class="reference internal" href="#module-code-sectionname">MODULE_CODE_SECTIONNAME</a> entries.</li>
+</ul>
+<ul class="simple" id="visibility">
+<li><em>visibility</em>: If present, an encoding of the visibility of this variable:
+* <tt class="docutils literal"><span class="pre">default</span></tt>: code 0
+* <tt class="docutils literal"><span class="pre">hidden</span></tt>: code 1
+* <tt class="docutils literal"><span class="pre">protected</span></tt>: code 2</li>
+<li><em>threadlocal</em>: If present, an encoding of the thread local storage mode of the
+variable:
+* <tt class="docutils literal"><span class="pre">not</span> <span class="pre">thread</span> <span class="pre">local</span></tt>: code 0
+* <tt class="docutils literal"><span class="pre">thread</span> <span class="pre">local;</span> <span class="pre">default</span> <span class="pre">TLS</span> <span class="pre">model</span></tt>: code 1
+* <tt class="docutils literal"><span class="pre">localdynamic</span></tt>: code 2
+* <tt class="docutils literal"><span class="pre">initialexec</span></tt>: code 3
+* <tt class="docutils literal"><span class="pre">localexec</span></tt>: code 4</li>
+<li><em>unnamed_addr</em>: If present and non-zero, indicates that the variable has
+<tt class="docutils literal"><span class="pre">unnamed_addr</span></tt></li>
+</ul>
+</div>
+<div class="section" id="module-code-function-record">
+<span id="function"></span><h4><a class="toc-backref" href="#id43">MODULE_CODE_FUNCTION Record</a><a class="headerlink" href="#module-code-function-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FUNCTION,</span> <span class="pre">type,</span> <span class="pre">callingconv,</span> <span class="pre">isproto,</span> <span class="pre">linkage,</span> <span class="pre">paramattr,</span> <span class="pre">alignment,</span> <span class="pre">section,</span> <span class="pre">visibility,</span> <span class="pre">gc,</span> <span class="pre">prefix]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> record (code 8) marks the declaration or definition of a
+function. The operand fields are:</p>
+<ul class="simple">
+<li><em>type</em>: The type index of the function type describing this function</li>
+<li><em>callingconv</em>: The calling convention number:
+* <tt class="docutils literal"><span class="pre">ccc</span></tt>: code 0
+* <tt class="docutils literal"><span class="pre">fastcc</span></tt>: code 8
+* <tt class="docutils literal"><span class="pre">coldcc</span></tt>: code 9
+* <tt class="docutils literal"><span class="pre">x86_stdcallcc</span></tt>: code 64
+* <tt class="docutils literal"><span class="pre">x86_fastcallcc</span></tt>: code 65
+* <tt class="docutils literal"><span class="pre">arm_apcscc</span></tt>: code 66
+* <tt class="docutils literal"><span class="pre">arm_aapcscc</span></tt>: code 67
+* <tt class="docutils literal"><span class="pre">arm_aapcs_vfpcc</span></tt>: code 68</li>
+<li>isproto*: Non-zero if this entry represents a declaration rather than a
+definition</li>
+<li><em>linkage</em>: An encoding of the <a class="reference internal" href="#linkage-type">linkage type</a> for this function</li>
+<li><em>paramattr</em>: If nonzero, the 1-based parameter attribute index into the table
+of <a class="reference internal" href="#paramattr-code-entry">PARAMATTR_CODE_ENTRY</a> entries.</li>
+<li><em>alignment</em>: The logarithm base 2 of the function’s requested alignment, plus
+1</li>
+<li><em>section</em>: If non-zero, the 1-based section index in the table of
+<a class="reference internal" href="#module-code-sectionname">MODULE_CODE_SECTIONNAME</a> entries.</li>
+<li><em>visibility</em>: An encoding of the <a class="reference internal" href="#visibility">visibility</a> of this function</li>
+<li><em>gc</em>: If present and nonzero, the 1-based garbage collector index in the table
+of <a class="reference internal" href="#module-code-gcname">MODULE_CODE_GCNAME</a> entries.</li>
+<li><em>unnamed_addr</em>: If present and non-zero, indicates that the function has
+<tt class="docutils literal"><span class="pre">unnamed_addr</span></tt></li>
+<li><em>prefix</em>: If non-zero, the value index of the prefix data for this function,
+plus 1.</li>
+</ul>
+</div>
+<div class="section" id="module-code-alias-record">
+<h4><a class="toc-backref" href="#id44">MODULE_CODE_ALIAS Record</a><a class="headerlink" href="#module-code-alias-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ALIAS,</span> <span class="pre">alias</span> <span class="pre">type,</span> <span class="pre">aliasee</span> <span class="pre">val#,</span> <span class="pre">linkage,</span> <span class="pre">visibility]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ALIAS</span></tt> record (code 9) marks the definition of an alias. The operand
+fields are</p>
+<ul class="simple">
+<li><em>alias type</em>: The type index of the alias</li>
+<li><em>aliasee val#</em>: The value index of the aliased value</li>
+<li><em>linkage</em>: An encoding of the <a class="reference internal" href="#linkage-type">linkage type</a> for this alias</li>
+<li><em>visibility</em>: If present, an encoding of the <a class="reference internal" href="#visibility">visibility</a> of the alias</li>
+</ul>
+</div>
+<div class="section" id="module-code-purgevals-record">
+<h4><a class="toc-backref" href="#id45">MODULE_CODE_PURGEVALS Record</a><a class="headerlink" href="#module-code-purgevals-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[PURGEVALS,</span> <span class="pre">numvals]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">PURGEVALS</span></tt> record (code 10) resets the module-level value list to the
+size given by the single operand value. Module-level value list items are added
+by <tt class="docutils literal"><span class="pre">GLOBALVAR</span></tt>, <tt class="docutils literal"><span class="pre">FUNCTION</span></tt>, and <tt class="docutils literal"><span class="pre">ALIAS</span></tt> records.  After a <tt class="docutils literal"><span class="pre">PURGEVALS</span></tt>
+record is seen, new value indices will start from the given <em>numvals</em> value.</p>
+</div>
+<div class="section" id="module-code-gcname-record">
+<span id="module-code-gcname"></span><h4><a class="toc-backref" href="#id46">MODULE_CODE_GCNAME Record</a><a class="headerlink" href="#module-code-gcname-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[GCNAME,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">GCNAME</span></tt> record (code 11) contains a variable number of values
+representing the bytes of a single garbage collector name string. There should
+be one <tt class="docutils literal"><span class="pre">GCNAME</span></tt> record for each garbage collector name referenced in function
+<tt class="docutils literal"><span class="pre">gc</span></tt> attributes within the module. These records can be referenced by 1-based
+index in the <em>gc</em> fields of <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> records.</p>
+</div>
+</div>
+<div class="section" id="paramattr-block-contents">
+<span id="paramattr-block"></span><h3><a class="toc-backref" href="#id47">PARAMATTR_BLOCK Contents</a><a class="headerlink" href="#paramattr-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">PARAMATTR_BLOCK</span></tt> block (id 9) contains a table of entries describing the
+attributes of function parameters. These entries are referenced by 1-based index
+in the <em>paramattr</em> field of module block <a class="reference internal" href="#function">FUNCTION</a> records, or within the
+<em>attr</em> field of function block <tt class="docutils literal"><span class="pre">INST_INVOKE</span></tt> and <tt class="docutils literal"><span class="pre">INST_CALL</span></tt> records.</p>
+<p>Entries within <tt class="docutils literal"><span class="pre">PARAMATTR_BLOCK</span></tt> are constructed to ensure that each is unique
+(i.e., no two indicies represent equivalent attribute lists).</p>
+<div class="section" id="paramattr-code-entry-record">
+<span id="paramattr-code-entry"></span><h4><a class="toc-backref" href="#id48">PARAMATTR_CODE_ENTRY Record</a><a class="headerlink" href="#paramattr-code-entry-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ENTRY,</span> <span class="pre">paramidx0,</span> <span class="pre">attr0,</span> <span class="pre">paramidx1,</span> <span class="pre">attr1...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ENTRY</span></tt> record (code 1) contains an even number of values describing a
+unique set of function parameter attributes. Each <em>paramidx</em> value indicates
+which set of attributes is represented, with 0 representing the return value
+attributes, 0xFFFFFFFF representing function attributes, and other values
+representing 1-based function parameters. Each <em>attr</em> value is a bitmap with the
+following interpretation:</p>
+<ul class="simple">
+<li>bit 0: <tt class="docutils literal"><span class="pre">zeroext</span></tt></li>
+<li>bit 1: <tt class="docutils literal"><span class="pre">signext</span></tt></li>
+<li>bit 2: <tt class="docutils literal"><span class="pre">noreturn</span></tt></li>
+<li>bit 3: <tt class="docutils literal"><span class="pre">inreg</span></tt></li>
+<li>bit 4: <tt class="docutils literal"><span class="pre">sret</span></tt></li>
+<li>bit 5: <tt class="docutils literal"><span class="pre">nounwind</span></tt></li>
+<li>bit 6: <tt class="docutils literal"><span class="pre">noalias</span></tt></li>
+<li>bit 7: <tt class="docutils literal"><span class="pre">byval</span></tt></li>
+<li>bit 8: <tt class="docutils literal"><span class="pre">nest</span></tt></li>
+<li>bit 9: <tt class="docutils literal"><span class="pre">readnone</span></tt></li>
+<li>bit 10: <tt class="docutils literal"><span class="pre">readonly</span></tt></li>
+<li>bit 11: <tt class="docutils literal"><span class="pre">noinline</span></tt></li>
+<li>bit 12: <tt class="docutils literal"><span class="pre">alwaysinline</span></tt></li>
+<li>bit 13: <tt class="docutils literal"><span class="pre">optsize</span></tt></li>
+<li>bit 14: <tt class="docutils literal"><span class="pre">ssp</span></tt></li>
+<li>bit 15: <tt class="docutils literal"><span class="pre">sspreq</span></tt></li>
+<li>bits 16-31: <tt class="docutils literal"><span class="pre">align</span> <span class="pre">n</span></tt></li>
+<li>bit 32: <tt class="docutils literal"><span class="pre">nocapture</span></tt></li>
+<li>bit 33: <tt class="docutils literal"><span class="pre">noredzone</span></tt></li>
+<li>bit 34: <tt class="docutils literal"><span class="pre">noimplicitfloat</span></tt></li>
+<li>bit 35: <tt class="docutils literal"><span class="pre">naked</span></tt></li>
+<li>bit 36: <tt class="docutils literal"><span class="pre">inlinehint</span></tt></li>
+<li>bits 37-39: <tt class="docutils literal"><span class="pre">alignstack</span> <span class="pre">n</span></tt>, represented as the logarithm
+base 2 of the requested alignment, plus 1</li>
+</ul>
+</div>
+</div>
+<div class="section" id="type-block-contents">
+<span id="type-block"></span><h3><a class="toc-backref" href="#id49">TYPE_BLOCK Contents</a><a class="headerlink" href="#type-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TYPE_BLOCK</span></tt> block (id 10) contains records which constitute a table of
+type operator entries used to represent types referenced within an LLVM
+module. Each record (with the exception of <a class="reference internal" href="#numentry">NUMENTRY</a>) generates a single type
+table entry, which may be referenced by 0-based index from instructions,
+constants, metadata, type symbol table entries, or other type operator records.</p>
+<p>Entries within <tt class="docutils literal"><span class="pre">TYPE_BLOCK</span></tt> are constructed to ensure that each entry is
+unique (i.e., no two indicies represent structurally equivalent types).</p>
+<div class="section" id="type-code-numentry-record">
+<span id="numentry"></span><span id="type-code-numentry"></span><h4><a class="toc-backref" href="#id50">TYPE_CODE_NUMENTRY Record</a><a class="headerlink" href="#type-code-numentry-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[NUMENTRY,</span> <span class="pre">numentries]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">NUMENTRY</span></tt> record (code 1) contains a single value which indicates the
+total number of type code entries in the type table of the module. If present,
+<tt class="docutils literal"><span class="pre">NUMENTRY</span></tt> should be the first record in the block.</p>
+</div>
+<div class="section" id="type-code-void-record">
+<h4><a class="toc-backref" href="#id51">TYPE_CODE_VOID Record</a><a class="headerlink" href="#type-code-void-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[VOID]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">VOID</span></tt> record (code 2) adds a <tt class="docutils literal"><span class="pre">void</span></tt> type to the type table.</p>
+</div>
+<div class="section" id="type-code-half-record">
+<h4><a class="toc-backref" href="#id52">TYPE_CODE_HALF Record</a><a class="headerlink" href="#type-code-half-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[HALF]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">HALF</span></tt> record (code 10) adds a <tt class="docutils literal"><span class="pre">half</span></tt> (16-bit floating point) type to
+the type table.</p>
+</div>
+<div class="section" id="type-code-float-record">
+<h4><a class="toc-backref" href="#id53">TYPE_CODE_FLOAT Record</a><a class="headerlink" href="#type-code-float-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FLOAT]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FLOAT</span></tt> record (code 3) adds a <tt class="docutils literal"><span class="pre">float</span></tt> (32-bit floating point) type to
+the type table.</p>
+</div>
+<div class="section" id="type-code-double-record">
+<h4><a class="toc-backref" href="#id54">TYPE_CODE_DOUBLE Record</a><a class="headerlink" href="#type-code-double-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[DOUBLE]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">DOUBLE</span></tt> record (code 4) adds a <tt class="docutils literal"><span class="pre">double</span></tt> (64-bit floating point) type to
+the type table.</p>
+</div>
+<div class="section" id="type-code-label-record">
+<h4><a class="toc-backref" href="#id55">TYPE_CODE_LABEL Record</a><a class="headerlink" href="#type-code-label-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[LABEL]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">LABEL</span></tt> record (code 5) adds a <tt class="docutils literal"><span class="pre">label</span></tt> type to the type table.</p>
+</div>
+<div class="section" id="type-code-opaque-record">
+<h4><a class="toc-backref" href="#id56">TYPE_CODE_OPAQUE Record</a><a class="headerlink" href="#type-code-opaque-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[OPAQUE]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">OPAQUE</span></tt> record (code 6) adds an <tt class="docutils literal"><span class="pre">opaque</span></tt> type to the type table. Note
+that distinct <tt class="docutils literal"><span class="pre">opaque</span></tt> types are not unified.</p>
+</div>
+<div class="section" id="type-code-integer-record">
+<h4><a class="toc-backref" href="#id57">TYPE_CODE_INTEGER Record</a><a class="headerlink" href="#type-code-integer-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[INTEGER,</span> <span class="pre">width]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">INTEGER</span></tt> record (code 7) adds an integer type to the type table. The
+single <em>width</em> field indicates the width of the integer type.</p>
+</div>
+<div class="section" id="type-code-pointer-record">
+<h4><a class="toc-backref" href="#id58">TYPE_CODE_POINTER Record</a><a class="headerlink" href="#type-code-pointer-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[POINTER,</span> <span class="pre">pointee</span> <span class="pre">type,</span> <span class="pre">address</span> <span class="pre">space]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">POINTER</span></tt> record (code 8) adds a pointer type to the type table. The
+operand fields are</p>
+<ul class="simple">
+<li><em>pointee type</em>: The type index of the pointed-to type</li>
+<li><em>address space</em>: If supplied, the target-specific numbered address space where
+the pointed-to object resides. Otherwise, the default address space is zero.</li>
+</ul>
+</div>
+<div class="section" id="type-code-function-record">
+<h4><a class="toc-backref" href="#id59">TYPE_CODE_FUNCTION Record</a><a class="headerlink" href="#type-code-function-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FUNCTION,</span> <span class="pre">vararg,</span> <span class="pre">ignored,</span> <span class="pre">retty,</span> <span class="pre">...paramty...</span> <span class="pre">]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> record (code 9) adds a function type to the type table. The
+operand fields are</p>
+<ul class="simple">
+<li><em>vararg</em>: Non-zero if the type represents a varargs function</li>
+<li><em>ignored</em>: This value field is present for backward compatibility only, and is
+ignored</li>
+<li><em>retty</em>: The type index of the function’s return type</li>
+<li><em>paramty</em>: Zero or more type indices representing the parameter types of the
+function</li>
+</ul>
+</div>
+<div class="section" id="type-code-struct-record">
+<h4><a class="toc-backref" href="#id60">TYPE_CODE_STRUCT Record</a><a class="headerlink" href="#type-code-struct-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[STRUCT,</span> <span class="pre">ispacked,</span> <span class="pre">...eltty...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">STRUCT</span></tt> record (code 10) adds a struct type to the type table. The
+operand fields are</p>
+<ul class="simple">
+<li><em>ispacked</em>: Non-zero if the type represents a packed structure</li>
+<li><em>eltty</em>: Zero or more type indices representing the element types of the
+structure</li>
+</ul>
+</div>
+<div class="section" id="type-code-array-record">
+<h4><a class="toc-backref" href="#id61">TYPE_CODE_ARRAY Record</a><a class="headerlink" href="#type-code-array-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ARRAY,</span> <span class="pre">numelts,</span> <span class="pre">eltty]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ARRAY</span></tt> record (code 11) adds an array type to the type table.  The
+operand fields are</p>
+<ul class="simple">
+<li><em>numelts</em>: The number of elements in arrays of this type</li>
+<li><em>eltty</em>: The type index of the array element type</li>
+</ul>
+</div>
+<div class="section" id="type-code-vector-record">
+<h4><a class="toc-backref" href="#id62">TYPE_CODE_VECTOR Record</a><a class="headerlink" href="#type-code-vector-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[VECTOR,</span> <span class="pre">numelts,</span> <span class="pre">eltty]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">VECTOR</span></tt> record (code 12) adds a vector type to the type table.  The
+operand fields are</p>
+<ul class="simple">
+<li><em>numelts</em>: The number of elements in vectors of this type</li>
+<li><em>eltty</em>: The type index of the vector element type</li>
+</ul>
+</div>
+<div class="section" id="type-code-x86-fp80-record">
+<h4><a class="toc-backref" href="#id63">TYPE_CODE_X86_FP80 Record</a><a class="headerlink" href="#type-code-x86-fp80-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[X86_FP80]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">X86_FP80</span></tt> record (code 13) adds an <tt class="docutils literal"><span class="pre">x86_fp80</span></tt> (80-bit floating point)
+type to the type table.</p>
+</div>
+<div class="section" id="type-code-fp128-record">
+<h4><a class="toc-backref" href="#id64">TYPE_CODE_FP128 Record</a><a class="headerlink" href="#type-code-fp128-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FP128]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FP128</span></tt> record (code 14) adds an <tt class="docutils literal"><span class="pre">fp128</span></tt> (128-bit floating point) type
+to the type table.</p>
+</div>
+<div class="section" id="type-code-ppc-fp128-record">
+<h4><a class="toc-backref" href="#id65">TYPE_CODE_PPC_FP128 Record</a><a class="headerlink" href="#type-code-ppc-fp128-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[PPC_FP128]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">PPC_FP128</span></tt> record (code 15) adds a <tt class="docutils literal"><span class="pre">ppc_fp128</span></tt> (128-bit floating point)
+type to the type table.</p>
+</div>
+<div class="section" id="type-code-metadata-record">
+<h4><a class="toc-backref" href="#id66">TYPE_CODE_METADATA Record</a><a class="headerlink" href="#type-code-metadata-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[METADATA]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">METADATA</span></tt> record (code 16) adds a <tt class="docutils literal"><span class="pre">metadata</span></tt> type to the type table.</p>
+</div>
+</div>
+<div class="section" id="constants-block-contents">
+<span id="constants-block"></span><h3><a class="toc-backref" href="#id67">CONSTANTS_BLOCK Contents</a><a class="headerlink" href="#constants-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">CONSTANTS_BLOCK</span></tt> block (id 11) ...</p>
+</div>
+<div class="section" id="function-block-contents">
+<span id="function-block"></span><h3><a class="toc-backref" href="#id68">FUNCTION_BLOCK Contents</a><a class="headerlink" href="#function-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">FUNCTION_BLOCK</span></tt> block (id 12) ...</p>
+<p>In addition to the record types described below, a <tt class="docutils literal"><span class="pre">FUNCTION_BLOCK</span></tt> block may
+contain the following sub-blocks:</p>
+<ul class="simple">
+<li><a class="reference internal" href="#constants-block">CONSTANTS_BLOCK</a></li>
+<li><a class="reference internal" href="#value-symtab-block">VALUE_SYMTAB_BLOCK</a></li>
+<li><a class="reference internal" href="#metadata-attachment">METADATA_ATTACHMENT</a></li>
+</ul>
+</div>
+<div class="section" id="type-symtab-block-contents">
+<span id="type-symtab-block"></span><h3><a class="toc-backref" href="#id69">TYPE_SYMTAB_BLOCK Contents</a><a class="headerlink" href="#type-symtab-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TYPE_SYMTAB_BLOCK</span></tt> block (id 13) contains entries which map between
+module-level named types and their corresponding type indices.</p>
+<div class="section" id="tst-code-entry-record">
+<span id="tst-code-entry"></span><h4><a class="toc-backref" href="#id70">TST_CODE_ENTRY Record</a><a class="headerlink" href="#tst-code-entry-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ENTRY,</span> <span class="pre">typeid,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ENTRY</span></tt> record (code 1) contains a variable number of values, with the
+first giving the type index of the designated type, and the remaining values
+giving the character codes of the type name. Each entry corresponds to a single
+named type.</p>
+</div>
+</div>
+<div class="section" id="value-symtab-block-contents">
+<span id="value-symtab-block"></span><h3><a class="toc-backref" href="#id71">VALUE_SYMTAB_BLOCK Contents</a><a class="headerlink" href="#value-symtab-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">VALUE_SYMTAB_BLOCK</span></tt> block (id 14) ...</p>
+</div>
+<div class="section" id="metadata-block-contents">
+<span id="metadata-block"></span><h3><a class="toc-backref" href="#id72">METADATA_BLOCK Contents</a><a class="headerlink" href="#metadata-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">METADATA_BLOCK</span></tt> block (id 15) ...</p>
+</div>
+<div class="section" id="metadata-attachment-contents">
+<span id="metadata-attachment"></span><h3><a class="toc-backref" href="#id73">METADATA_ATTACHMENT Contents</a><a class="headerlink" href="#metadata-attachment-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">METADATA_ATTACHMENT</span></tt> block (id 16) ...</p>
+</div>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="AliasAnalysis.html" title="LLVM Alias Analysis Infrastructure"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/BranchWeightMetadata.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/BranchWeightMetadata.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/BranchWeightMetadata.html (added)
+++ www-releases/trunk/3.4.1/docs/BranchWeightMetadata.html Wed May  7 15:09:32 2014
@@ -0,0 +1,205 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>LLVM Branch Weight Metadata — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="LLVM bugpoint tool: design and usage" href="Bugpoint.html" />
+    <link rel="prev" title="LLVM Bitcode File Format" href="BitCodeFormat.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="BitCodeFormat.html" title="LLVM Bitcode File Format"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-branch-weight-metadata">
+<h1>LLVM Branch Weight Metadata<a class="headerlink" href="#llvm-branch-weight-metadata" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#supported-instructions" id="id2">Supported Instructions</a><ul>
+<li><a class="reference internal" href="#branchinst" id="id3"><tt class="docutils literal"><span class="pre">BranchInst</span></tt></a></li>
+<li><a class="reference internal" href="#switchinst" id="id4"><tt class="docutils literal"><span class="pre">SwitchInst</span></tt></a></li>
+<li><a class="reference internal" href="#indirectbrinst" id="id5"><tt class="docutils literal"><span class="pre">IndirectBrInst</span></tt></a></li>
+<li><a class="reference internal" href="#other" id="id6">Other</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#built-in-expect-instructions" id="id7">Built-in <tt class="docutils literal"><span class="pre">expect</span></tt> Instructions</a><ul>
+<li><a class="reference internal" href="#if-statement" id="id8"><tt class="docutils literal"><span class="pre">if</span></tt> statement</a></li>
+<li><a class="reference internal" href="#switch-statement" id="id9"><tt class="docutils literal"><span class="pre">switch</span></tt> statement</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#cfg-modifications" id="id10">CFG Modifications</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>Branch Weight Metadata represents branch weights as its likeliness to be
+taken. Metadata is assigned to the <tt class="docutils literal"><span class="pre">TerminatorInst</span></tt> as a <tt class="docutils literal"><span class="pre">MDNode</span></tt> of the
+<tt class="docutils literal"><span class="pre">MD_prof</span></tt> kind. The first operator is always a <tt class="docutils literal"><span class="pre">MDString</span></tt> node with the
+string “branch_weights”. Number of operators depends on the terminator type.</p>
+<p>Branch weights might be fetch from the profiling file, or generated based on
+<a class="reference internal" href="#builtin-expect">__builtin_expect</a> instruction.</p>
+<p>All weights are represented as an unsigned 32-bit values, where higher value
+indicates greater chance to be taken.</p>
+</div>
+<div class="section" id="supported-instructions">
+<h2><a class="toc-backref" href="#id2">Supported Instructions</a><a class="headerlink" href="#supported-instructions" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="branchinst">
+<h3><a class="toc-backref" href="#id3"><tt class="docutils literal"><span class="pre">BranchInst</span></tt></a><a class="headerlink" href="#branchinst" title="Permalink to this headline">¶</a></h3>
+<p>Metadata is only assigned to the conditional branches. There are two extra
+operarands for the true and the false branch.</p>
+<div class="highlight-llvm"><pre>!0 = metadata !{
+  metadata !"branch_weights",
+  i32 <TRUE_BRANCH_WEIGHT>,
+  i32 <FALSE_BRANCH_WEIGHT>
+}</pre>
+</div>
+</div>
+<div class="section" id="switchinst">
+<h3><a class="toc-backref" href="#id4"><tt class="docutils literal"><span class="pre">SwitchInst</span></tt></a><a class="headerlink" href="#switchinst" title="Permalink to this headline">¶</a></h3>
+<p>Branch weights are assigned to every case (including the <tt class="docutils literal"><span class="pre">default</span></tt> case which
+is always case #0).</p>
+<div class="highlight-llvm"><pre>!0 = metadata !{
+  metadata !"branch_weights",
+  i32 <DEFAULT_BRANCH_WEIGHT>
+  [ , i32 <CASE_BRANCH_WEIGHT> ... ]
+}</pre>
+</div>
+</div>
+<div class="section" id="indirectbrinst">
+<h3><a class="toc-backref" href="#id5"><tt class="docutils literal"><span class="pre">IndirectBrInst</span></tt></a><a class="headerlink" href="#indirectbrinst" title="Permalink to this headline">¶</a></h3>
+<p>Branch weights are assigned to every destination.</p>
+<div class="highlight-llvm"><pre>!0 = metadata !{
+  metadata !"branch_weights",
+  i32 <LABEL_BRANCH_WEIGHT>
+  [ , i32 <LABEL_BRANCH_WEIGHT> ... ]
+}</pre>
+</div>
+</div>
+<div class="section" id="other">
+<h3><a class="toc-backref" href="#id6">Other</a><a class="headerlink" href="#other" title="Permalink to this headline">¶</a></h3>
+<p>Other terminator instructions are not allowed to contain Branch Weight Metadata.</p>
+</div>
+</div>
+<div class="section" id="built-in-expect-instructions">
+<span id="builtin-expect"></span><h2><a class="toc-backref" href="#id7">Built-in <tt class="docutils literal"><span class="pre">expect</span></tt> Instructions</a><a class="headerlink" href="#built-in-expect-instructions" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">__builtin_expect(long</span> <span class="pre">exp,</span> <span class="pre">long</span> <span class="pre">c)</span></tt> instruction provides branch prediction
+information. The return value is the value of <tt class="docutils literal"><span class="pre">exp</span></tt>.</p>
+<p>It is especially useful in conditional statements. Currently Clang supports two
+conditional statements:</p>
+<div class="section" id="if-statement">
+<h3><a class="toc-backref" href="#id8"><tt class="docutils literal"><span class="pre">if</span></tt> statement</a><a class="headerlink" href="#if-statement" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">exp</span></tt> parameter is the condition. The <tt class="docutils literal"><span class="pre">c</span></tt> parameter is the expected
+comparison value. If it is equal to 1 (true), the condition is likely to be
+true, in other case condition is likely to be false. For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">(</span><span class="n">__builtin_expect</span><span class="p">(</span><span class="n">x</span> <span class="o">></span> <span class="mi">0</span><span class="p">,</span> <span class="mi">1</span><span class="p">))</span> <span class="p">{</span>
+  <span class="c1">// This block is likely to be taken.</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="switch-statement">
+<h3><a class="toc-backref" href="#id9"><tt class="docutils literal"><span class="pre">switch</span></tt> statement</a><a class="headerlink" href="#switch-statement" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">exp</span></tt> parameter is the value. The <tt class="docutils literal"><span class="pre">c</span></tt> parameter is the expected
+value. If the expected value doesn’t show on the cases list, the <tt class="docutils literal"><span class="pre">default</span></tt>
+case is assumed to be likely taken.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">switch</span> <span class="p">(</span><span class="n">__builtin_expect</span><span class="p">(</span><span class="n">x</span><span class="p">,</span> <span class="mi">5</span><span class="p">))</span> <span class="p">{</span>
+<span class="nl">default:</span> <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="mi">0</span>:  <span class="c1">// ...</span>
+<span class="k">case</span> <span class="mi">3</span>:  <span class="c1">// ...</span>
+<span class="k">case</span> <span class="mi">5</span>:  <span class="c1">// This case is likely to be taken.</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="cfg-modifications">
+<h2><a class="toc-backref" href="#id10">CFG Modifications</a><a class="headerlink" href="#cfg-modifications" title="Permalink to this headline">¶</a></h2>
+<p>Branch Weight Metatada is not proof against CFG changes. If terminator operands’
+are changed some action should be taken. In other case some misoptimizations may
+occur due to incorrent branch prediction information.</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="BitCodeFormat.html" title="LLVM Bitcode File Format"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/Bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/Bugpoint.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/Bugpoint.html (added)
+++ www-releases/trunk/3.4.1/docs/Bugpoint.html Wed May  7 15:09:32 2014
@@ -0,0 +1,295 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>LLVM bugpoint tool: design and usage — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="The LLVM Target-Independent Code Generator" href="CodeGenerator.html" />
+    <link rel="prev" title="LLVM Branch Weight Metadata" href="BranchWeightMetadata.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="CodeGenerator.html" title="The LLVM Target-Independent Code Generator"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-bugpoint-tool-design-and-usage">
+<h1>LLVM bugpoint tool: design and usage<a class="headerlink" href="#llvm-bugpoint-tool-design-and-usage" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#description" id="id4">Description</a></li>
+<li><a class="reference internal" href="#design-philosophy" id="id5">Design Philosophy</a><ul>
+<li><a class="reference internal" href="#automatic-debugger-selection" id="id6">Automatic Debugger Selection</a></li>
+<li><a class="reference internal" href="#crash-debugger" id="id7">Crash debugger</a></li>
+<li><a class="reference internal" href="#code-generator-debugger" id="id8">Code generator debugger</a></li>
+<li><a class="reference internal" href="#miscompilation-debugger" id="id9">Miscompilation debugger</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#advice-for-using-bugpoint" id="id10">Advice for using bugpoint</a></li>
+<li><a class="reference internal" href="#what-to-do-when-bugpoint-isn-t-enough" id="id11">What to do when bugpoint isn’t enough</a></li>
+</ul>
+</div>
+<div class="section" id="description">
+<h2><a class="toc-backref" href="#id4">Description</a><a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></tt> narrows down the source of problems in LLVM tools and passes.  It
+can be used to debug three types of failures: optimizer crashes, miscompilations
+by optimizers, or bad native code generation (including problems in the static
+and JIT compilers).  It aims to reduce large test cases to small, useful ones.
+For example, if <tt class="docutils literal"><span class="pre">opt</span></tt> crashes while optimizing a file, it will identify the
+optimization (or combination of optimizations) that causes the crash, and reduce
+the file down to a small example which triggers the crash.</p>
+<p>For detailed case scenarios, such as debugging <tt class="docutils literal"><span class="pre">opt</span></tt>, or one of the LLVM code
+generators, see <a class="reference external" href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p>
+</div>
+<div class="section" id="design-philosophy">
+<h2><a class="toc-backref" href="#id5">Design Philosophy</a><a class="headerlink" href="#design-philosophy" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></tt> is designed to be a useful tool without requiring any hooks into
+the LLVM infrastructure at all.  It works with any and all LLVM passes and code
+generators, and does not need to “know” how they work.  Because of this, it may
+appear to do stupid things or miss obvious simplifications.  <tt class="docutils literal"><span class="pre">bugpoint</span></tt> is
+also designed to trade off programmer time for computer time in the
+compiler-debugging process; consequently, it may take a long period of
+(unattended) time to reduce a test case, but we feel it is still worth it. Note
+that <tt class="docutils literal"><span class="pre">bugpoint</span></tt> is generally very quick unless debugging a miscompilation
+where each test of the program (which requires executing it) takes a long time.</p>
+<div class="section" id="automatic-debugger-selection">
+<h3><a class="toc-backref" href="#id6">Automatic Debugger Selection</a><a class="headerlink" href="#automatic-debugger-selection" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></tt> reads each <tt class="docutils literal"><span class="pre">.bc</span></tt> or <tt class="docutils literal"><span class="pre">.ll</span></tt> file specified on the command line
+and links them together into a single module, called the test program.  If any
+LLVM passes are specified on the command line, it runs these passes on the test
+program.  If any of the passes crash, or if they produce malformed output (which
+causes the verifier to abort), <tt class="docutils literal"><span class="pre">bugpoint</span></tt> starts the <a class="reference internal" href="#crash-debugger">crash debugger</a>.</p>
+<p>Otherwise, if the <tt class="docutils literal"><span class="pre">-output</span></tt> option was not specified, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> runs the
+test program with the “safe” backend (which is assumed to generate good code) to
+generate a reference output.  Once <tt class="docutils literal"><span class="pre">bugpoint</span></tt> has a reference output for the
+test program, it tries executing it with the selected code generator.  If the
+selected code generator crashes, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> starts the <a class="reference internal" href="#crash-debugger">crash debugger</a> on
+the code generator.  Otherwise, if the resulting output differs from the
+reference output, it assumes the difference resulted from a code generator
+failure, and starts the <a class="reference internal" href="#code-generator-debugger">code generator debugger</a>.</p>
+<p>Finally, if the output of the selected code generator matches the reference
+output, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> runs the test program after all of the LLVM passes have
+been applied to it.  If its output differs from the reference output, it assumes
+the difference resulted from a failure in one of the LLVM passes, and enters the
+<a class="reference internal" href="#miscompilation-debugger">miscompilation debugger</a>.  Otherwise, there is no problem <tt class="docutils literal"><span class="pre">bugpoint</span></tt> can
+debug.</p>
+</div>
+<div class="section" id="crash-debugger">
+<span id="id1"></span><h3><a class="toc-backref" href="#id7">Crash debugger</a><a class="headerlink" href="#crash-debugger" title="Permalink to this headline">¶</a></h3>
+<p>If an optimizer or code generator crashes, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> will try as hard as it
+can to reduce the list of passes (for optimizer crashes) and the size of the
+test program.  First, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> figures out which combination of optimizer
+passes triggers the bug. This is useful when debugging a problem exposed by
+<tt class="docutils literal"><span class="pre">opt</span></tt>, for example, because it runs over 38 passes.</p>
+<p>Next, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> tries removing functions from the test program, to reduce its
+size.  Usually it is able to reduce a test program to a single function, when
+debugging intraprocedural optimizations.  Once the number of functions has been
+reduced, it attempts to delete various edges in the control flow graph, to
+reduce the size of the function as much as possible.  Finally, <tt class="docutils literal"><span class="pre">bugpoint</span></tt>
+deletes any individual LLVM instructions whose absence does not eliminate the
+failure.  At the end, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> should tell you what passes crash, give you a
+bitcode file, and give you instructions on how to reproduce the failure with
+<tt class="docutils literal"><span class="pre">opt</span></tt> or <tt class="docutils literal"><span class="pre">llc</span></tt>.</p>
+</div>
+<div class="section" id="code-generator-debugger">
+<span id="id2"></span><h3><a class="toc-backref" href="#id8">Code generator debugger</a><a class="headerlink" href="#code-generator-debugger" title="Permalink to this headline">¶</a></h3>
+<p>The code generator debugger attempts to narrow down the amount of code that is
+being miscompiled by the selected code generator.  To do this, it takes the test
+program and partitions it into two pieces: one piece which it compiles with the
+“safe” backend (into a shared object), and one piece which it runs with either
+the JIT or the static LLC compiler.  It uses several techniques to reduce the
+amount of code pushed through the LLVM code generator, to reduce the potential
+scope of the problem.  After it is finished, it emits two bitcode files (called
+“test” [to be compiled with the code generator] and “safe” [to be compiled with
+the “safe” backend], respectively), and instructions for reproducing the
+problem.  The code generator debugger assumes that the “safe” backend produces
+good code.</p>
+</div>
+<div class="section" id="miscompilation-debugger">
+<span id="id3"></span><h3><a class="toc-backref" href="#id9">Miscompilation debugger</a><a class="headerlink" href="#miscompilation-debugger" title="Permalink to this headline">¶</a></h3>
+<p>The miscompilation debugger works similarly to the code generator debugger.  It
+works by splitting the test program into two pieces, running the optimizations
+specified on one piece, linking the two pieces back together, and then executing
+the result.  It attempts to narrow down the list of passes to the one (or few)
+which are causing the miscompilation, then reduce the portion of the test
+program which is being miscompiled.  The miscompilation debugger assumes that
+the selected code generator is working properly.</p>
+</div>
+</div>
+<div class="section" id="advice-for-using-bugpoint">
+<h2><a class="toc-backref" href="#id10">Advice for using bugpoint</a><a class="headerlink" href="#advice-for-using-bugpoint" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></tt> can be a remarkably useful tool, but it sometimes works in
+non-obvious ways.  Here are some hints and tips:</p>
+<ul>
+<li><p class="first">In the code generator and miscompilation debuggers, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> only works
+with programs that have deterministic output.  Thus, if the program outputs
+<tt class="docutils literal"><span class="pre">argv[0]</span></tt>, the date, time, or any other “random” data, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> may
+misinterpret differences in these data, when output, as the result of a
+miscompilation.  Programs should be temporarily modified to disable outputs
+that are likely to vary from run to run.</p>
+</li>
+<li><p class="first">In the code generator and miscompilation debuggers, debugging will go faster
+if you manually modify the program or its inputs to reduce the runtime, but
+still exhibit the problem.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> is extremely useful when working on a new optimization: it helps
+track down regressions quickly.  To avoid having to relink <tt class="docutils literal"><span class="pre">bugpoint</span></tt> every
+time you change your optimization however, have <tt class="docutils literal"><span class="pre">bugpoint</span></tt> dynamically load
+your optimization with the <tt class="docutils literal"><span class="pre">-load</span></tt> option.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> can generate a lot of output and run for a long period of time.
+It is often useful to capture the output of the program to file.  For example,
+in the C shell, you can run:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> bugpoint  ... |& tee bugpoint.log
+</pre></div>
+</div>
+<p>to get a copy of <tt class="docutils literal"><span class="pre">bugpoint</span></tt>‘s output in the file <tt class="docutils literal"><span class="pre">bugpoint.log</span></tt>, as well
+as on your terminal.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> cannot debug problems with the LLVM linker. If <tt class="docutils literal"><span class="pre">bugpoint</span></tt>
+crashes before you see its “All input ok” message, you might try <tt class="docutils literal"><span class="pre">llvm-link</span>
+<span class="pre">-v</span></tt> on the same set of input files. If that also crashes, you may be
+experiencing a linker bug.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> is useful for proactively finding bugs in LLVM.  Invoking
+<tt class="docutils literal"><span class="pre">bugpoint</span></tt> with the <tt class="docutils literal"><span class="pre">-find-bugs</span></tt> option will cause the list of specified
+optimizations to be randomized and applied to the program. This process will
+repeat until a bug is found or the user kills <tt class="docutils literal"><span class="pre">bugpoint</span></tt>.</p>
+</li>
+</ul>
+</div>
+<div class="section" id="what-to-do-when-bugpoint-isn-t-enough">
+<h2><a class="toc-backref" href="#id11">What to do when bugpoint isn’t enough</a><a class="headerlink" href="#what-to-do-when-bugpoint-isn-t-enough" title="Permalink to this headline">¶</a></h2>
+<p>Sometimes, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> is not enough. In particular, InstCombine and
+TargetLowering both have visitor structured code with lots of potential
+transformations.  If the process of using bugpoint has left you with still too
+much code to figure out and the problem seems to be in instcombine, the
+following steps may help.  These same techniques are useful with TargetLowering
+as well.</p>
+<p>Turn on <tt class="docutils literal"><span class="pre">-debug-only=instcombine</span></tt> and see which transformations within
+instcombine are firing by selecting out lines with “<tt class="docutils literal"><span class="pre">IC</span></tt>” in them.</p>
+<p>At this point, you have a decision to make.  Is the number of transformations
+small enough to step through them using a debugger?  If so, then try that.</p>
+<p>If there are too many transformations, then a source modification approach may
+be helpful.  In this approach, you can modify the source code of instcombine to
+disable just those transformations that are being performed on your test input
+and perform a binary search over the set of transformations.  One set of places
+to modify are the “<tt class="docutils literal"><span class="pre">visit*</span></tt>” methods of <tt class="docutils literal"><span class="pre">InstCombiner</span></tt> (<em>e.g.</em>
+<tt class="docutils literal"><span class="pre">visitICmpInst</span></tt>) by adding a “<tt class="docutils literal"><span class="pre">return</span> <span class="pre">false</span></tt>” as the first line of the
+method.</p>
+<p>If that still doesn’t remove enough, then change the caller of
+<tt class="docutils literal"><span class="pre">InstCombiner::DoOneIteration</span></tt>, <tt class="docutils literal"><span class="pre">InstCombiner::runOnFunction</span></tt> to limit the
+number of iterations.</p>
+<p>You may also find it useful to use “<tt class="docutils literal"><span class="pre">-stats</span></tt>” now to see what parts of
+instcombine are firing.  This can guide where to put additional reporting code.</p>
+<p>At this point, if the amount of transformations is still too large, then
+inserting code to limit whether or not to execute the body of the code in the
+visit function can be helpful.  Add a static counter which is incremented on
+every invocation of the function.  Then add code which simply returns false on
+desired ranges.  For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">static</span> <span class="kt">int</span> <span class="n">calledCount</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+<span class="n">calledCount</span><span class="o">++</span><span class="p">;</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o"><</span> <span class="mi">212</span><span class="p">)</span> <span class="k">return</span> <span class="nb">false</span><span class="p">);</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">></span> <span class="mi">217</span><span class="p">)</span> <span class="k">return</span> <span class="nb">false</span><span class="p">);</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">213</span><span class="p">)</span> <span class="k">return</span> <span class="nb">false</span><span class="p">);</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">214</span><span class="p">)</span> <span class="k">return</span> <span class="nb">false</span><span class="p">);</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">215</span><span class="p">)</span> <span class="k">return</span> <span class="nb">false</span><span class="p">);</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">216</span><span class="p">)</span> <span class="k">return</span> <span class="nb">false</span><span class="p">);</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="n">dbgs</span><span class="p">()</span> <span class="o"><<</span> <span class="s">"visitXOR calledCount: "</span> <span class="o"><<</span> <span class="n">calledCount</span> <span class="o"><<</span> <span class="s">"</span><span class="se">\n</span><span class="s">"</span><span class="p">);</span>
+<span class="n">DEBUG</span><span class="p">(</span><span class="n">dbgs</span><span class="p">()</span> <span class="o"><<</span> <span class="s">"I: "</span><span class="p">;</span> <span class="n">I</span><span class="o">-></span><span class="n">dump</span><span class="p">());</span>
+</pre></div>
+</div>
+<p>could be added to <tt class="docutils literal"><span class="pre">visitXOR</span></tt> to limit <tt class="docutils literal"><span class="pre">visitXor</span></tt> to being applied only to
+calls 212 and 217. This is from an actual test case and raises an important
+point—a simple binary search may not be sufficient, as transformations that
+interact may require isolating more than one call.  In TargetLowering, use
+<tt class="docutils literal"><span class="pre">return</span> <span class="pre">SDNode();</span></tt> instead of <tt class="docutils literal"><span class="pre">return</span> <span class="pre">false;</span></tt>.</p>
+<p>Now that that the number of transformations is down to a manageable number, try
+examining the output to see if you can figure out which transformations are
+being done.  If that can be figured out, then do the usual debugging.  If which
+code corresponds to the transformation being performed isn’t obvious, set a
+breakpoint after the call count based disabling and step through the code.
+Alternatively, you can use “<tt class="docutils literal"><span class="pre">printf</span></tt>” style debugging to report waypoints.</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="CodeGenerator.html" title="The LLVM Target-Independent Code Generator"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CMake.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CMake.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CMake.html (added)
+++ www-releases/trunk/3.4.1/docs/CMake.html Wed May  7 15:09:32 2014
@@ -0,0 +1,461 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>Building LLVM with CMake — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="How To Build On ARM" href="HowToBuildOnARM.html" />
+    <link rel="prev" title="LLVM Language Reference Manual" href="LangRef.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="HowToBuildOnARM.html" title="How To Build On ARM"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="LangRef.html" title="LLVM Language Reference Manual"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="building-llvm-with-cmake">
+<h1>Building LLVM with CMake<a class="headerlink" href="#building-llvm-with-cmake" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id5">Introduction</a></li>
+<li><a class="reference internal" href="#quick-start" id="id6">Quick start</a></li>
+<li><a class="reference internal" href="#usage" id="id7">Basic CMake usage</a></li>
+<li><a class="reference internal" href="#options-and-variables" id="id8">Options and variables</a><ul>
+<li><a class="reference internal" href="#frequently-used-cmake-variables" id="id9">Frequently-used CMake variables</a></li>
+<li><a class="reference internal" href="#llvm-specific-variables" id="id10">LLVM-specific variables</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#executing-the-test-suite" id="id11">Executing the test suite</a></li>
+<li><a class="reference internal" href="#cross-compiling" id="id12">Cross compiling</a></li>
+<li><a class="reference internal" href="#embedding-llvm-in-your-project" id="id13">Embedding LLVM in your project</a><ul>
+<li><a class="reference internal" href="#developing-llvm-pass-out-of-source" id="id14">Developing LLVM pass out of source</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#compiler-platform-specific-topics" id="id15">Compiler/Platform specific topics</a><ul>
+<li><a class="reference internal" href="#microsoft-visual-c" id="id16">Microsoft Visual C++</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id5">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p><a class="reference external" href="http://www.cmake.org/">CMake</a> is a cross-platform build-generator tool. CMake
+does not build the project, it generates the files needed by your build tool
+(GNU make, Visual Studio, etc) for building LLVM.</p>
+<p>If you are really anxious about getting a functional LLVM build, go to the
+<a class="reference internal" href="#quick-start">Quick start</a> section. If you are a CMake novice, start on <a class="reference internal" href="#basic-cmake-usage">Basic CMake usage</a>
+and then go back to the <a class="reference internal" href="#quick-start">Quick start</a> once you know what you are doing. The
+<a class="reference internal" href="#options-and-variables">Options and variables</a> section is a reference for customizing your build. If
+you already have experience with CMake, this is the recommended starting point.</p>
+</div>
+<div class="section" id="quick-start">
+<span id="id1"></span><h2><a class="toc-backref" href="#id6">Quick start</a><a class="headerlink" href="#quick-start" title="Permalink to this headline">¶</a></h2>
+<p>We use here the command-line, non-interactive CMake interface.</p>
+<ol class="arabic">
+<li><p class="first"><a class="reference external" href="http://www.cmake.org/cmake/resources/software.html">Download</a> and install
+CMake. Version 2.8 is the minimum required.</p>
+</li>
+<li><p class="first">Open a shell. Your development tools must be reachable from this shell
+through the PATH environment variable.</p>
+</li>
+<li><p class="first">Create a directory for containing the build. It is not supported to build
+LLVM on the source directory. cd to this directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> mkdir mybuilddir
+<span class="gp">$</span> <span class="nb">cd </span>mybuilddir
+</pre></div>
+</div>
+</li>
+<li><p class="first">Execute this command on the shell replacing <cite>path/to/llvm/source/root</cite> with
+the path to the root of your LLVM source tree:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake path/to/llvm/source/root
+</pre></div>
+</div>
+<p>CMake will detect your development environment, perform a series of test and
+generate the files required for building LLVM. CMake will use default values
+for all build parameters. See the <a class="reference internal" href="#options-and-variables">Options and variables</a> section for
+fine-tuning your build</p>
+<p>This can fail if CMake can’t detect your toolset, or if it thinks that the
+environment is not sane enough. On this case make sure that the toolset that
+you intend to use is the only one reachable from the shell and that the shell
+itself is the correct one for you development environment. CMake will refuse
+to build MinGW makefiles if you have a POSIX shell reachable through the PATH
+environment variable, for instance. You can force CMake to use a given build
+tool, see the <a class="reference internal" href="#usage">Usage</a> section.</p>
+</li>
+</ol>
+</div>
+<div class="section" id="usage">
+<span id="basic-cmake-usage"></span><span id="id2"></span><h2><a class="toc-backref" href="#id7">Basic CMake usage</a><a class="headerlink" href="#usage" title="Permalink to this headline">¶</a></h2>
+<p>This section explains basic aspects of CMake, mostly for explaining those
+options which you may need on your day-to-day usage.</p>
+<p>CMake comes with extensive documentation in the form of html files and on the
+cmake executable itself. Execute <tt class="docutils literal"><span class="pre">cmake</span> <span class="pre">--help</span></tt> for further help options.</p>
+<p>CMake requires to know for which build tool it shall generate files (GNU make,
+Visual Studio, Xcode, etc). If not specified on the command line, it tries to
+guess it based on you environment. Once identified the build tool, CMake uses
+the corresponding <em>Generator</em> for creating files for your build tool. You can
+explicitly specify the generator with the command line option <tt class="docutils literal"><span class="pre">-G</span> <span class="pre">"Name</span> <span class="pre">of</span> <span class="pre">the</span>
+<span class="pre">generator"</span></tt>. For knowing the available generators on your platform, execute</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake --help
+</pre></div>
+</div>
+<p>This will list the generator’s names at the end of the help text. Generator’s
+names are case-sensitive. Example:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -G <span class="s2">"Visual Studio 10"</span> path/to/llvm/source/root
+</pre></div>
+</div>
+<p>For a given development platform there can be more than one adequate
+generator. If you use Visual Studio “NMake Makefiles” is a generator you can use
+for building with NMake. By default, CMake chooses the more specific generator
+supported by your development environment. If you want an alternative generator,
+you must tell this to CMake with the <tt class="docutils literal"><span class="pre">-G</span></tt> option.</p>
+</div>
+<div class="section" id="options-and-variables">
+<span id="id3"></span><h2><a class="toc-backref" href="#id8">Options and variables</a><a class="headerlink" href="#options-and-variables" title="Permalink to this headline">¶</a></h2>
+<p>Variables customize how the build will be generated. Options are boolean
+variables, with possible values ON/OFF. Options and variables are defined on the
+CMake command line like this:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -DVARIABLE<span class="o">=</span>value path/to/llvm/source
+</pre></div>
+</div>
+<p>You can set a variable after the initial CMake invocation for changing its
+value. You can also undefine a variable:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -UVARIABLE path/to/llvm/source
+</pre></div>
+</div>
+<p>Variables are stored on the CMake cache. This is a file named <tt class="docutils literal"><span class="pre">CMakeCache.txt</span></tt>
+on the root of the build directory. Do not hand-edit it.</p>
+<p>Variables are listed here appending its type after a colon. It is correct to
+write the variable and the type on the CMake command line:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -DVARIABLE:TYPE<span class="o">=</span>value path/to/llvm/source
+</pre></div>
+</div>
+<div class="section" id="frequently-used-cmake-variables">
+<h3><a class="toc-backref" href="#id9">Frequently-used CMake variables</a><a class="headerlink" href="#frequently-used-cmake-variables" title="Permalink to this headline">¶</a></h3>
+<p>Here are listed some of the CMake variables that are used often, along with a
+brief explanation and LLVM-specific notes. For full documentation, check the
+CMake docs or execute <tt class="docutils literal"><span class="pre">cmake</span> <span class="pre">--help-variable</span> <span class="pre">VARIABLE_NAME</span></tt>.</p>
+<dl class="docutils">
+<dt><strong>CMAKE_BUILD_TYPE</strong>:STRING</dt>
+<dd>Sets the build type for <tt class="docutils literal"><span class="pre">make</span></tt> based generators. Possible values are
+Release, Debug, RelWithDebInfo and MinSizeRel. On systems like Visual Studio
+the user sets the build type with the IDE settings.</dd>
+<dt><strong>CMAKE_INSTALL_PREFIX</strong>:PATH</dt>
+<dd>Path where LLVM will be installed if “make install” is invoked or the
+“INSTALL” target is built.</dd>
+<dt><strong>LLVM_LIBDIR_SUFFIX</strong>:STRING</dt>
+<dd>Extra suffix to append to the directory where libraries are to be
+installed. On a 64-bit architecture, one could use <tt class="docutils literal"><span class="pre">-DLLVM_LIBDIR_SUFFIX=64</span></tt>
+to install libraries to <tt class="docutils literal"><span class="pre">/usr/lib64</span></tt>.</dd>
+<dt><strong>CMAKE_C_FLAGS</strong>:STRING</dt>
+<dd>Extra flags to use when compiling C source files.</dd>
+<dt><strong>CMAKE_CXX_FLAGS</strong>:STRING</dt>
+<dd>Extra flags to use when compiling C++ source files.</dd>
+<dt><strong>BUILD_SHARED_LIBS</strong>:BOOL</dt>
+<dd>Flag indicating is shared libraries will be built. Its default value is
+OFF. Shared libraries are not supported on Windows and not recommended in the
+other OSes.</dd>
+</dl>
+</div>
+<div class="section" id="llvm-specific-variables">
+<span id="id4"></span><h3><a class="toc-backref" href="#id10">LLVM-specific variables</a><a class="headerlink" href="#llvm-specific-variables" title="Permalink to this headline">¶</a></h3>
+<dl class="docutils">
+<dt><strong>LLVM_TARGETS_TO_BUILD</strong>:STRING</dt>
+<dd>Semicolon-separated list of targets to build, or <em>all</em> for building all
+targets. Case-sensitive. Defaults to <em>all</em>. Example:
+<tt class="docutils literal"><span class="pre">-DLLVM_TARGETS_TO_BUILD="X86;PowerPC"</span></tt>.</dd>
+<dt><strong>LLVM_BUILD_TOOLS</strong>:BOOL</dt>
+<dd>Build LLVM tools. Defaults to ON. Targets for building each tool are generated
+in any case. You can build an tool separately by invoking its target. For
+example, you can build <em>llvm-as</em> with a makefile-based system executing <em>make
+llvm-as</em> on the root of your build directory.</dd>
+<dt><strong>LLVM_INCLUDE_TOOLS</strong>:BOOL</dt>
+<dd>Generate build targets for the LLVM tools. Defaults to ON. You can use that
+option for disabling the generation of build targets for the LLVM tools.</dd>
+<dt><strong>LLVM_BUILD_EXAMPLES</strong>:BOOL</dt>
+<dd>Build LLVM examples. Defaults to OFF. Targets for building each example are
+generated in any case. See documentation for <em>LLVM_BUILD_TOOLS</em> above for more
+details.</dd>
+<dt><strong>LLVM_INCLUDE_EXAMPLES</strong>:BOOL</dt>
+<dd>Generate build targets for the LLVM examples. Defaults to ON. You can use that
+option for disabling the generation of build targets for the LLVM examples.</dd>
+<dt><strong>LLVM_BUILD_TESTS</strong>:BOOL</dt>
+<dd>Build LLVM unit tests. Defaults to OFF. Targets for building each unit test
+are generated in any case. You can build a specific unit test with the target
+<em>UnitTestNameTests</em> (where at this time <em>UnitTestName</em> can be ADT, Analysis,
+ExecutionEngine, JIT, Support, Transform, VMCore; see the subdirectories of
+<em>unittests</em> for an updated list.) It is possible to build all unit tests with
+the target <em>UnitTests</em>.</dd>
+<dt><strong>LLVM_INCLUDE_TESTS</strong>:BOOL</dt>
+<dd>Generate build targets for the LLVM unit tests. Defaults to ON. You can use
+that option for disabling the generation of build targets for the LLVM unit
+tests.</dd>
+<dt><strong>LLVM_APPEND_VC_REV</strong>:BOOL</dt>
+<dd>Append version control revision info (svn revision number or Git revision id)
+to LLVM version string (stored in the PACKAGE_VERSION macro). For this to work
+cmake must be invoked before the build. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_THREADS</strong>:BOOL</dt>
+<dd>Build with threads support, if available. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_ASSERTIONS</strong>:BOOL</dt>
+<dd>Enables code assertions. Defaults to OFF if and only if <tt class="docutils literal"><span class="pre">CMAKE_BUILD_TYPE</span></tt>
+is <em>Release</em>.</dd>
+<dt><strong>LLVM_ENABLE_PIC</strong>:BOOL</dt>
+<dd>Add the <tt class="docutils literal"><span class="pre">-fPIC</span></tt> flag for the compiler command-line, if the compiler supports
+this flag. Some systems, like Windows, do not need this flag. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_WARNINGS</strong>:BOOL</dt>
+<dd>Enable all compiler warnings. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_PEDANTIC</strong>:BOOL</dt>
+<dd>Enable pedantic mode. This disable compiler specific extensions, is
+possible. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_WERROR</strong>:BOOL</dt>
+<dd>Stop and fail build, if a compiler warning is triggered. Defaults to OFF.</dd>
+<dt><strong>LLVM_BUILD_32_BITS</strong>:BOOL</dt>
+<dd>Build 32-bits executables and libraries on 64-bits systems. This option is
+available only on some 64-bits unix systems. Defaults to OFF.</dd>
+<dt><strong>LLVM_TARGET_ARCH</strong>:STRING</dt>
+<dd>LLVM target to use for native code generation. This is required for JIT
+generation. It defaults to “host”, meaning that it shall pick the architecture
+of the machine where LLVM is being built. If you are cross-compiling, set it
+to the target architecture name.</dd>
+<dt><strong>LLVM_TABLEGEN</strong>:STRING</dt>
+<dd>Full path to a native TableGen executable (usually named <tt class="docutils literal"><span class="pre">tblgen</span></tt>). This is
+intended for cross-compiling: if the user sets this variable, no native
+TableGen will be created.</dd>
+<dt><strong>LLVM_LIT_ARGS</strong>:STRING</dt>
+<dd>Arguments given to lit.  <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check</span></tt> and <tt class="docutils literal"><span class="pre">make</span> <span class="pre">clang-test</span></tt> are affected.
+By default, <tt class="docutils literal"><span class="pre">'-sv</span> <span class="pre">--no-progress-bar'</span></tt> on Visual C++ and Xcode, <tt class="docutils literal"><span class="pre">'-sv'</span></tt> on
+others.</dd>
+<dt><strong>LLVM_LIT_TOOLS_DIR</strong>:PATH</dt>
+<dd>The path to GnuWin32 tools for tests. Valid on Windows host.  Defaults to “”,
+then Lit seeks tools according to %PATH%.  Lit can find tools(eg. grep, sort,
+&c) on LLVM_LIT_TOOLS_DIR at first, without specifying GnuWin32 to %PATH%.</dd>
+<dt><strong>LLVM_ENABLE_FFI</strong>:BOOL</dt>
+<dd>Indicates whether LLVM Interpreter will be linked with Foreign Function
+Interface library. If the library or its headers are installed on a custom
+location, you can set the variables FFI_INCLUDE_DIR and
+FFI_LIBRARY_DIR. Defaults to OFF.</dd>
+<dt><strong>LLVM_EXTERNAL_{CLANG,LLD,POLLY}_SOURCE_DIR</strong>:PATH</dt>
+<dd>Path to <tt class="docutils literal"><span class="pre">{Clang,lld,Polly}</span></tt>‘s source directory. Defaults to
+<tt class="docutils literal"><span class="pre">tools/{clang,lld,polly}</span></tt>. <tt class="docutils literal"><span class="pre">{Clang,lld,Polly}</span></tt> will not be built when it
+is empty or it does not point valid path.</dd>
+<dt><strong>LLVM_USE_OPROFILE</strong>:BOOL</dt>
+<dd>Enable building OProfile JIT support. Defaults to OFF</dd>
+<dt><strong>LLVM_USE_INTEL_JITEVENTS</strong>:BOOL</dt>
+<dd>Enable building support for Intel JIT Events API. Defaults to OFF</dd>
+<dt><strong>LLVM_ENABLE_ZLIB</strong>:BOOL</dt>
+<dd>Build with zlib to support compression/uncompression in LLVM tools.
+Defaults to ON.</dd>
+<dt><strong>LLVM_USE_SANITIZER</strong>:STRING</dt>
+<dd>Define the sanitizer used to build LLVM binaries and tests. Possible values
+are <tt class="docutils literal"><span class="pre">Address</span></tt>, <tt class="docutils literal"><span class="pre">Memory</span></tt> and <tt class="docutils literal"><span class="pre">MemoryWithOrigins</span></tt>. Defaults to empty
+string.</dd>
+</dl>
+</div>
+</div>
+<div class="section" id="executing-the-test-suite">
+<h2><a class="toc-backref" href="#id11">Executing the test suite</a><a class="headerlink" href="#executing-the-test-suite" title="Permalink to this headline">¶</a></h2>
+<p>Testing is performed when the <em>check</em> target is built. For instance, if you are
+using makefiles, execute this command while on the top level of your build
+directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> make check
+</pre></div>
+</div>
+<p>On Visual Studio, you may run tests to build the project “check”.</p>
+</div>
+<div class="section" id="cross-compiling">
+<h2><a class="toc-backref" href="#id12">Cross compiling</a><a class="headerlink" href="#cross-compiling" title="Permalink to this headline">¶</a></h2>
+<p>See <a class="reference external" href="http://www.vtk.org/Wiki/CMake_Cross_Compiling">this wiki page</a> for
+generic instructions on how to cross-compile with CMake. It goes into detailed
+explanations and may seem daunting, but it is not. On the wiki page there are
+several examples including toolchain files. Go directly to <a class="reference external" href="http://www.vtk.org/Wiki/CMake_Cross_Compiling#Information_how_to_set_up_various_cross_compiling_toolchains">this section</a>
+for a quick solution.</p>
+<p>Also see the <a class="reference internal" href="#llvm-specific-variables">LLVM-specific variables</a> section for variables used when
+cross-compiling.</p>
+</div>
+<div class="section" id="embedding-llvm-in-your-project">
+<h2><a class="toc-backref" href="#id13">Embedding LLVM in your project</a><a class="headerlink" href="#embedding-llvm-in-your-project" title="Permalink to this headline">¶</a></h2>
+<p>The most difficult part of adding LLVM to the build of a project is to determine
+the set of LLVM libraries corresponding to the set of required LLVM
+features. What follows is an example of how to obtain this information:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="c"># A convenience variable:</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">LLVM_ROOT</span> <span class="s2">""</span> <span class="s">CACHE</span> <span class="s">PATH</span> <span class="s2">"Root of LLVM install."</span><span class="p">)</span>
+
+<span class="c"># A bit of a sanity check:</span>
+<span class="nb">if</span><span class="p">(</span> <span class="s">NOT</span> <span class="s">EXISTS</span> <span class="o">${</span><span class="nv">LLVM_ROOT</span><span class="o">}</span><span class="s">/include/llvm</span> <span class="p">)</span>
+<span class="nb">message</span><span class="p">(</span><span class="s">FATAL_ERROR</span> <span class="s2">"LLVM_ROOT (${LLVM_ROOT}) is not a valid LLVM install"</span><span class="p">)</span>
+<span class="nb">endif</span><span class="p">()</span>
+
+<span class="c"># We incorporate the CMake features provided by LLVM:</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">CMAKE_MODULE_PATH</span> <span class="o">${</span><span class="nv">CMAKE_MODULE_PATH</span><span class="o">}</span> <span class="s2">"${LLVM_ROOT}/share/llvm/cmake"</span><span class="p">)</span>
+<span class="nb">include</span><span class="p">(</span><span class="s">LLVMConfig</span><span class="p">)</span>
+
+<span class="c"># Now set the header and library paths:</span>
+<span class="nb">include_directories</span><span class="p">(</span> <span class="o">${</span><span class="nv">LLVM_INCLUDE_DIRS</span><span class="o">}</span> <span class="p">)</span>
+<span class="nb">link_directories</span><span class="p">(</span> <span class="o">${</span><span class="nv">LLVM_LIBRARY_DIRS</span><span class="o">}</span> <span class="p">)</span>
+<span class="nb">add_definitions</span><span class="p">(</span> <span class="o">${</span><span class="nv">LLVM_DEFINITIONS</span><span class="o">}</span> <span class="p">)</span>
+
+<span class="c"># Let's suppose we want to build a JIT compiler with support for</span>
+<span class="c"># binary code (no interpreter):</span>
+<span class="nb">llvm_map_components_to_libraries</span><span class="p">(</span><span class="s">REQ_LLVM_LIBRARIES</span> <span class="s">jit</span> <span class="s">native</span><span class="p">)</span>
+
+<span class="c"># Finally, we link the LLVM libraries to our executable:</span>
+<span class="nb">target_link_libraries</span><span class="p">(</span><span class="s">mycompiler</span> <span class="o">${</span><span class="nv">REQ_LLVM_LIBRARIES</span><span class="o">}</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>This assumes that LLVM_ROOT points to an install of LLVM. The procedure works
+too for uninstalled builds although we need to take care to add an
+<cite>include_directories</cite> for the location of the headers on the LLVM source
+directory (if we are building out-of-source.)</p>
+<p>Alternativaly, you can utilize CMake’s <tt class="docutils literal"><span class="pre">find_package</span></tt> functionality. Here is
+an equivalent variant of snippet shown above:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">find_package</span><span class="p">(</span><span class="s">LLVM</span><span class="p">)</span>
+
+<span class="nb">if</span><span class="p">(</span> <span class="s">NOT</span> <span class="s">LLVM_FOUND</span> <span class="p">)</span>
+  <span class="nb">message</span><span class="p">(</span><span class="s">FATAL_ERROR</span> <span class="s2">"LLVM package can't be found. Set CMAKE_PREFIX_PATH variable to LLVM's installation prefix."</span><span class="p">)</span>
+<span class="nb">endif</span><span class="p">()</span>
+
+<span class="nb">include_directories</span><span class="p">(</span> <span class="o">${</span><span class="nv">LLVM_INCLUDE_DIRS</span><span class="o">}</span> <span class="p">)</span>
+<span class="nb">link_directories</span><span class="p">(</span> <span class="o">${</span><span class="nv">LLVM_LIBRARY_DIRS</span><span class="o">}</span> <span class="p">)</span>
+
+<span class="nb">llvm_map_components_to_libraries</span><span class="p">(</span><span class="s">REQ_LLVM_LIBRARIES</span> <span class="s">jit</span> <span class="s">native</span><span class="p">)</span>
+
+<span class="nb">target_link_libraries</span><span class="p">(</span><span class="s">mycompiler</span> <span class="o">${</span><span class="nv">REQ_LLVM_LIBRARIES</span><span class="o">}</span><span class="p">)</span>
+</pre></div>
+</div>
+<div class="section" id="developing-llvm-pass-out-of-source">
+<span id="cmake-out-of-source-pass"></span><h3><a class="toc-backref" href="#id14">Developing LLVM pass out of source</a><a class="headerlink" href="#developing-llvm-pass-out-of-source" title="Permalink to this headline">¶</a></h3>
+<p>It is possible to develop LLVM passes against installed LLVM.  An example of
+project layout provided below:</p>
+<div class="highlight-none"><div class="highlight"><pre><project dir>/
+    |
+    CMakeLists.txt
+    <pass name>/
+        |
+        CMakeLists.txt
+        Pass.cpp
+        ...
+</pre></div>
+</div>
+<p>Contents of <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/CMakeLists.txt</span></tt>:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">find_package</span><span class="p">(</span><span class="s">LLVM</span><span class="p">)</span>
+
+<span class="c"># Define add_llvm_* macro's.</span>
+<span class="nb">include</span><span class="p">(</span><span class="s">AddLLVM</span><span class="p">)</span>
+
+<span class="nb">add_definitions</span><span class="p">(</span><span class="o">${</span><span class="nv">LLVM_DEFINITIONS</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">include_directories</span><span class="p">(</span><span class="o">${</span><span class="nv">LLVM_INCLUDE_DIRS</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">link_directories</span><span class="p">(</span><span class="o">${</span><span class="nv">LLVM_LIBRARY_DIRS</span><span class="o">}</span><span class="p">)</span>
+
+<span class="nb">add_subdirectory</span><span class="p">(</span><span class="s"><pass</span> <span class="s">name></span><span class="p">)</span>
+</pre></div>
+</div>
+<p>Contents of <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/<pass</span> <span class="pre">name>/CMakeLists.txt</span></tt>:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">add_llvm_loadable_module</span><span class="p">(</span><span class="s">LLVMPassname</span>
+  <span class="s">Pass.cpp</span>
+  <span class="p">)</span>
+</pre></div>
+</div>
+<p>When you are done developing your pass, you may wish to integrate it
+into LLVM source tree. You can achieve it in two easy steps:</p>
+<ol class="arabic simple">
+<li>Copying <tt class="docutils literal"><span class="pre"><pass</span> <span class="pre">name></span></tt> folder into <tt class="docutils literal"><span class="pre"><LLVM</span> <span class="pre">root>/lib/Transform</span></tt> directory.</li>
+<li>Adding <tt class="docutils literal"><span class="pre">add_subdirectory(<pass</span> <span class="pre">name>)</span></tt> line into
+<tt class="docutils literal"><span class="pre"><LLVM</span> <span class="pre">root>/lib/Transform/CMakeLists.txt</span></tt>.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="compiler-platform-specific-topics">
+<h2><a class="toc-backref" href="#id15">Compiler/Platform specific topics</a><a class="headerlink" href="#compiler-platform-specific-topics" title="Permalink to this headline">¶</a></h2>
+<p>Notes for specific compilers and/or platforms.</p>
+<div class="section" id="microsoft-visual-c">
+<h3><a class="toc-backref" href="#id16">Microsoft Visual C++</a><a class="headerlink" href="#microsoft-visual-c" title="Permalink to this headline">¶</a></h3>
+<dl class="docutils">
+<dt><strong>LLVM_COMPILER_JOBS</strong>:STRING</dt>
+<dd>Specifies the maximum number of parallell compiler jobs to use per project
+when building with msbuild or Visual Studio. Only supported for the Visual
+Studio 2010 CMake generator. 0 means use all processors. Default is 0.</dd>
+</dl>
+</div>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="HowToBuildOnARM.html" title="How To Build On ARM"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="LangRef.html" title="LLVM Language Reference Manual"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CodeGenerator.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CodeGenerator.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CodeGenerator.html (added)
+++ www-releases/trunk/3.4.1/docs/CodeGenerator.html Wed May  7 15:09:32 2014
@@ -0,0 +1,2274 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>The LLVM Target-Independent Code Generator — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="Exception Handling in LLVM" href="ExceptionHandling.html" />
+    <link rel="prev" title="LLVM bugpoint tool: design and usage" href="Bugpoint.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="ExceptionHandling.html" title="Exception Handling in LLVM"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="the-llvm-target-independent-code-generator">
+<h1>The LLVM Target-Independent Code Generator<a class="headerlink" href="#the-llvm-target-independent-code-generator" title="Permalink to this headline">¶</a></h1>
+<style>
+  .unknown { background-color: #C0C0C0; text-align: center; }
+  .unknown:before { content: "?" }
+  .no { background-color: #C11B17 }
+  .no:before { content: "N" }
+  .partial { background-color: #F88017 }
+  .yes { background-color: #0F0; }
+  .yes:before { content: "Y" }
+  .na { background-color: #6666FF; }
+  .na:before { content: "N/A" }
+</style><div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id8">Introduction</a><ul>
+<li><a class="reference internal" href="#required-components-in-the-code-generator" id="id9">Required components in the code generator</a></li>
+<li><a class="reference internal" href="#the-high-level-design-of-the-code-generator" id="id10">The high-level design of the code generator</a></li>
+<li><a class="reference internal" href="#using-tablegen-for-target-description" id="id11">Using TableGen for target description</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#target-description-classes" id="id12">Target description classes</a><ul>
+<li><a class="reference internal" href="#the-targetmachine-class" id="id13">The <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-datalayout-class" id="id14">The <tt class="docutils literal"><span class="pre">DataLayout</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetlowering-class" id="id15">The <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetregisterinfo-class" id="id16">The <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetinstrinfo-class" id="id17">The <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetframeinfo-class" id="id18">The <tt class="docutils literal"><span class="pre">TargetFrameInfo</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetsubtarget-class" id="id19">The <tt class="docutils literal"><span class="pre">TargetSubtarget</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetjitinfo-class" id="id20">The <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> class</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#machine-code-description-classes" id="id21">Machine code description classes</a><ul>
+<li><a class="reference internal" href="#the-machineinstr-class" id="id22">The <tt class="docutils literal"><span class="pre">MachineInstr</span></tt> class</a><ul>
+<li><a class="reference internal" href="#using-the-machineinstrbuilder-h-functions" id="id23">Using the <tt class="docutils literal"><span class="pre">MachineInstrBuilder.h</span></tt> functions</a></li>
+<li><a class="reference internal" href="#fixed-preassigned-registers" id="id24">Fixed (preassigned) registers</a></li>
+<li><a class="reference internal" href="#call-clobbered-registers" id="id25">Call-clobbered registers</a></li>
+<li><a class="reference internal" href="#machine-code-in-ssa-form" id="id26">Machine code in SSA form</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-machinebasicblock-class" id="id27">The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-machinefunction-class" id="id28">The <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> class</a></li>
+<li><a class="reference internal" href="#machineinstr-bundles" id="id29"><tt class="docutils literal"><span class="pre">MachineInstr</span> <span class="pre">Bundles</span></tt></a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-mc-layer" id="id30">The “MC” Layer</a><ul>
+<li><a class="reference internal" href="#the-mcstreamer-api" id="id31">The <tt class="docutils literal"><span class="pre">MCStreamer</span></tt> API</a></li>
+<li><a class="reference internal" href="#the-mccontext-class" id="id32">The <tt class="docutils literal"><span class="pre">MCContext</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-mcsymbol-class" id="id33">The <tt class="docutils literal"><span class="pre">MCSymbol</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-mcsection-class" id="id34">The <tt class="docutils literal"><span class="pre">MCSection</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-mcinst-class" id="id35">The <tt class="docutils literal"><span class="pre">MCInst</span></tt> class</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#target-independent-code-generation-algorithms" id="id36">Target-independent code generation algorithms</a><ul>
+<li><a class="reference internal" href="#instruction-selection-section" id="id37">Instruction Selection</a><ul>
+<li><a class="reference internal" href="#introduction-to-selectiondags" id="id38">Introduction to SelectionDAGs</a></li>
+<li><a class="reference internal" href="#selectiondag-instruction-selection-process" id="id39">SelectionDAG Instruction Selection Process</a></li>
+<li><a class="reference internal" href="#initial-selectiondag-construction" id="id40">Initial SelectionDAG Construction</a></li>
+<li><a class="reference internal" href="#selectiondag-legalizetypes-phase" id="id41">SelectionDAG LegalizeTypes Phase</a></li>
+<li><a class="reference internal" href="#selectiondag-legalize-phase" id="id42">SelectionDAG Legalize Phase</a></li>
+<li><a class="reference internal" href="#selectiondag-optimization-phase-the-dag-combiner" id="id43">SelectionDAG Optimization Phase: the DAG Combiner</a></li>
+<li><a class="reference internal" href="#selectiondag-select-phase" id="id44">SelectionDAG Select Phase</a></li>
+<li><a class="reference internal" href="#selectiondag-scheduling-and-formation-phase" id="id45">SelectionDAG Scheduling and Formation Phase</a></li>
+<li><a class="reference internal" href="#future-directions-for-the-selectiondag" id="id46">Future directions for the SelectionDAG</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#ssa-based-machine-code-optimizations" id="id47">SSA-based Machine Code Optimizations</a></li>
+<li><a class="reference internal" href="#live-intervals" id="id48">Live Intervals</a><ul>
+<li><a class="reference internal" href="#live-variable-analysis" id="id49">Live Variable Analysis</a></li>
+<li><a class="reference internal" href="#live-intervals-analysis" id="id50">Live Intervals Analysis</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#register-allocator" id="id51">Register Allocation</a><ul>
+<li><a class="reference internal" href="#how-registers-are-represented-in-llvm" id="id52">How registers are represented in LLVM</a></li>
+<li><a class="reference internal" href="#mapping-virtual-registers-to-physical-registers" id="id53">Mapping virtual registers to physical registers</a></li>
+<li><a class="reference internal" href="#handling-two-address-instructions" id="id54">Handling two address instructions</a></li>
+<li><a class="reference internal" href="#the-ssa-deconstruction-phase" id="id55">The SSA deconstruction phase</a></li>
+<li><a class="reference internal" href="#instruction-folding" id="id56">Instruction folding</a></li>
+<li><a class="reference internal" href="#built-in-register-allocators" id="id57">Built in register allocators</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#prolog-epilog-code-insertion" id="id58">Prolog/Epilog Code Insertion</a></li>
+<li><a class="reference internal" href="#late-machine-code-optimizations" id="id59">Late Machine Code Optimizations</a></li>
+<li><a class="reference internal" href="#code-emission" id="id60">Code Emission</a></li>
+<li><a class="reference internal" href="#vliw-packetizer" id="id61">VLIW Packetizer</a><ul>
+<li><a class="reference internal" href="#mapping-from-instructions-to-functional-units" id="id62">Mapping from instructions to functional units</a></li>
+<li><a class="reference internal" href="#how-the-packetization-tables-are-generated-and-used" id="id63">How the packetization tables are generated and used</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#implementing-a-native-assembler" id="id64">Implementing a Native Assembler</a><ul>
+<li><a class="reference internal" href="#instruction-parsing" id="id65">Instruction Parsing</a></li>
+<li><a class="reference internal" href="#instruction-alias-processing" id="id66">Instruction Alias Processing</a><ul>
+<li><a class="reference internal" href="#mnemonic-aliases" id="id67">Mnemonic Aliases</a></li>
+<li><a class="reference internal" href="#instruction-aliases" id="id68">Instruction Aliases</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#instruction-matching" id="id69">Instruction Matching</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#target-specific-implementation-notes" id="id70">Target-specific Implementation Notes</a><ul>
+<li><a class="reference internal" href="#target-feature-matrix" id="id71">Target Feature Matrix</a><ul>
+<li><a class="reference internal" href="#is-generally-reliable" id="id72">Is Generally Reliable</a></li>
+<li><a class="reference internal" href="#assembly-parser" id="id73">Assembly Parser</a></li>
+<li><a class="reference internal" href="#disassembler" id="id74">Disassembler</a></li>
+<li><a class="reference internal" href="#inline-asm" id="id75">Inline Asm</a></li>
+<li><a class="reference internal" href="#jit-support" id="id76">JIT Support</a></li>
+<li><a class="reference internal" href="#o-file-writing" id="id77">.o File Writing</a></li>
+<li><a class="reference internal" href="#tail-calls" id="id78">Tail Calls</a></li>
+<li><a class="reference internal" href="#segmented-stacks" id="id79">Segmented Stacks</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#tail-call-optimization" id="id80">Tail call optimization</a></li>
+<li><a class="reference internal" href="#sibling-call-optimization" id="id81">Sibling call optimization</a></li>
+<li><a class="reference internal" href="#the-x86-backend" id="id82">The X86 backend</a><ul>
+<li><a class="reference internal" href="#x86-target-triples-supported" id="id83">X86 Target Triples supported</a></li>
+<li><a class="reference internal" href="#x86-calling-conventions-supported" id="id84">X86 Calling Conventions supported</a></li>
+<li><a class="reference internal" href="#representing-x86-addressing-modes-in-machineinstrs" id="id85">Representing X86 addressing modes in MachineInstrs</a></li>
+<li><a class="reference internal" href="#x86-address-spaces-supported" id="id86">X86 address spaces supported</a></li>
+<li><a class="reference internal" href="#instruction-naming" id="id87">Instruction naming</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-powerpc-backend" id="id88">The PowerPC backend</a><ul>
+<li><a class="reference internal" href="#llvm-powerpc-abi" id="id89">LLVM PowerPC ABI</a></li>
+<li><a class="reference internal" href="#frame-layout" id="id90">Frame Layout</a></li>
+<li><a class="reference internal" href="#prolog-epilog" id="id91">Prolog/Epilog</a></li>
+<li><a class="reference internal" href="#dynamic-allocation" id="id92">Dynamic Allocation</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-nvptx-backend" id="id93">The NVPTX backend</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">This is a work in progress.</p>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id8">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM target-independent code generator is a framework that provides a suite
+of reusable components for translating the LLVM internal representation to the
+machine code for a specified target—either in assembly form (suitable for a
+static compiler) or in binary machine code format (usable for a JIT
+compiler). The LLVM target-independent code generator consists of six main
+components:</p>
+<ol class="arabic simple">
+<li><a class="reference internal" href="#abstract-target-description">Abstract target description</a> interfaces which capture important properties
+about various aspects of the machine, independently of how they will be used.
+These interfaces are defined in <tt class="docutils literal"><span class="pre">include/llvm/Target/</span></tt>.</li>
+<li>Classes used to represent the <a class="reference internal" href="#code-being-generated">code being generated</a> for a target.  These
+classes are intended to be abstract enough to represent the machine code for
+<em>any</em> target machine.  These classes are defined in
+<tt class="docutils literal"><span class="pre">include/llvm/CodeGen/</span></tt>. At this level, concepts like “constant pool
+entries” and “jump tables” are explicitly exposed.</li>
+<li>Classes and algorithms used to represent code as the object file level, the
+<a class="reference internal" href="#mc-layer">MC Layer</a>.  These classes represent assembly level constructs like labels,
+sections, and instructions.  At this level, concepts like “constant pool
+entries” and “jump tables” don’t exist.</li>
+<li><a class="reference internal" href="#target-independent-algorithms">Target-independent algorithms</a> used to implement various phases of native
+code generation (register allocation, scheduling, stack frame representation,
+etc).  This code lives in <tt class="docutils literal"><span class="pre">lib/CodeGen/</span></tt>.</li>
+<li><a class="reference internal" href="#implementations-of-the-abstract-target-description-interfaces">Implementations of the abstract target description interfaces</a> for
+particular targets.  These machine descriptions make use of the components
+provided by LLVM, and can optionally provide custom target-specific passes,
+to build complete code generators for a specific target.  Target descriptions
+live in <tt class="docutils literal"><span class="pre">lib/Target/</span></tt>.</li>
+<li>The target-independent JIT components.  The LLVM JIT is completely target
+independent (it uses the <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> structure to interface for
+target-specific issues.  The code for the target-independent JIT lives in
+<tt class="docutils literal"><span class="pre">lib/ExecutionEngine/JIT</span></tt>.</li>
+</ol>
+<p>Depending on which part of the code generator you are interested in working on,
+different pieces of this will be useful to you.  In any case, you should be
+familiar with the <a class="reference internal" href="#target-description">target description</a> and <a class="reference internal" href="#machine-code-representation">machine code representation</a>
+classes.  If you want to add a backend for a new target, you will need to
+<a class="reference internal" href="#implement-the-target-description">implement the target description</a> classes for your new target and understand
+the <a class="reference external" href="LangRef.html">LLVM code representation</a>.  If you are interested in
+implementing a new <a class="reference internal" href="#code-generation-algorithm">code generation algorithm</a>, it should only depend on the
+target-description and machine code representation classes, ensuring that it is
+portable.</p>
+<div class="section" id="required-components-in-the-code-generator">
+<h3><a class="toc-backref" href="#id9">Required components in the code generator</a><a class="headerlink" href="#required-components-in-the-code-generator" title="Permalink to this headline">¶</a></h3>
+<p>The two pieces of the LLVM code generator are the high-level interface to the
+code generator and the set of reusable components that can be used to build
+target-specific backends.  The two most important interfaces (<span class="raw-html"><tt></span>
+<a class="reference internal" href="#targetmachine">TargetMachine</a> <span class="raw-html"></tt></span> and <span class="raw-html"><tt></span> <a class="reference internal" href="#datalayout">DataLayout</a>
+<span class="raw-html"></tt></span>) are the only ones that are required to be defined for a
+backend to fit into the LLVM system, but the others must be defined if the
+reusable code generator components are going to be used.</p>
+<p>This design has two important implications.  The first is that LLVM can support
+completely non-traditional code generation targets.  For example, the C backend
+does not require register allocation, instruction selection, or any of the other
+standard components provided by the system.  As such, it only implements these
+two interfaces, and does its own thing. Note that C backend was removed from the
+trunk since LLVM 3.1 release. Another example of a code generator like this is a
+(purely hypothetical) backend that converts LLVM to the GCC RTL form and uses
+GCC to emit machine code for a target.</p>
+<p>This design also implies that it is possible to design and implement radically
+different code generators in the LLVM system that do not make use of any of the
+built-in components.  Doing so is not recommended at all, but could be required
+for radically different targets that do not fit into the LLVM machine
+description model: FPGAs for example.</p>
+</div>
+<div class="section" id="the-high-level-design-of-the-code-generator">
+<span id="high-level-design-of-the-code-generator"></span><h3><a class="toc-backref" href="#id10">The high-level design of the code generator</a><a class="headerlink" href="#the-high-level-design-of-the-code-generator" title="Permalink to this headline">¶</a></h3>
+<p>The LLVM target-independent code generator is designed to support efficient and
+quality code generation for standard register-based microprocessors.  Code
+generation in this model is divided into the following stages:</p>
+<ol class="arabic simple">
+<li><a class="reference internal" href="#instruction-selection">Instruction Selection</a> — This phase determines an efficient way to
+express the input LLVM code in the target instruction set.  This stage
+produces the initial code for the program in the target instruction set, then
+makes use of virtual registers in SSA form and physical registers that
+represent any required register assignments due to target constraints or
+calling conventions.  This step turns the LLVM code into a DAG of target
+instructions.</li>
+<li><a class="reference internal" href="#scheduling-and-formation">Scheduling and Formation</a> — This phase takes the DAG of target
+instructions produced by the instruction selection phase, determines an
+ordering of the instructions, then emits the instructions as <span class="raw-html"><tt></span>
+<a class="reference internal" href="#machineinstr">MachineInstr</a>s <span class="raw-html"></tt></span> with that ordering.  Note that we
+describe this in the <a class="reference internal" href="#instruction-selection-section">instruction selection section</a> because it operates on
+a <a class="reference internal" href="#selectiondag">SelectionDAG</a>.</li>
+<li><a class="reference internal" href="#ssa-based-machine-code-optimizations">SSA-based Machine Code Optimizations</a> — This optional stage consists of a
+series of machine-code optimizations that operate on the SSA-form produced by
+the instruction selector.  Optimizations like modulo-scheduling or peephole
+optimization work here.</li>
+<li><a class="reference internal" href="#register-allocation">Register Allocation</a> — The target code is transformed from an infinite
+virtual register file in SSA form to the concrete register file used by the
+target.  This phase introduces spill code and eliminates all virtual register
+references from the program.</li>
+<li><a class="reference internal" href="#prolog-epilog-code-insertion">Prolog/Epilog Code Insertion</a> — Once the machine code has been generated
+for the function and the amount of stack space required is known (used for
+LLVM alloca’s and spill slots), the prolog and epilog code for the function
+can be inserted and “abstract stack location references” can be eliminated.
+This stage is responsible for implementing optimizations like frame-pointer
+elimination and stack packing.</li>
+<li><a class="reference internal" href="#late-machine-code-optimizations">Late Machine Code Optimizations</a> — Optimizations that operate on “final”
+machine code can go here, such as spill code scheduling and peephole
+optimizations.</li>
+<li><a class="reference internal" href="#code-emission">Code Emission</a> — The final stage actually puts out the code for the
+current function, either in the target assembler format or in machine
+code.</li>
+</ol>
+<p>The code generator is based on the assumption that the instruction selector will
+use an optimal pattern matching selector to create high-quality sequences of
+native instructions.  Alternative code generator designs based on pattern
+expansion and aggressive iterative peephole optimization are much slower.  This
+design permits efficient compilation (important for JIT environments) and
+aggressive optimization (used when generating code offline) by allowing
+components of varying levels of sophistication to be used for any step of
+compilation.</p>
+<p>In addition to these stages, target implementations can insert arbitrary
+target-specific passes into the flow.  For example, the X86 target uses a
+special pass to handle the 80x87 floating point stack architecture.  Other
+targets with unusual requirements can be supported with custom passes as needed.</p>
+</div>
+<div class="section" id="using-tablegen-for-target-description">
+<h3><a class="toc-backref" href="#id11">Using TableGen for target description</a><a class="headerlink" href="#using-tablegen-for-target-description" title="Permalink to this headline">¶</a></h3>
+<p>The target description classes require a detailed description of the target
+architecture.  These target descriptions often have a large amount of common
+information (e.g., an <tt class="docutils literal"><span class="pre">add</span></tt> instruction is almost identical to a <tt class="docutils literal"><span class="pre">sub</span></tt>
+instruction).  In order to allow the maximum amount of commonality to be
+factored out, the LLVM code generator uses the
+<a class="reference internal" href="TableGenFundamentals.html"><em>TableGen</em></a> tool to describe big chunks of the
+target machine, which allows the use of domain-specific and target-specific
+abstractions to reduce the amount of repetition.</p>
+<p>As LLVM continues to be developed and refined, we plan to move more and more of
+the target description to the <tt class="docutils literal"><span class="pre">.td</span></tt> form.  Doing so gives us a number of
+advantages.  The most important is that it makes it easier to port LLVM because
+it reduces the amount of C++ code that has to be written, and the surface area
+of the code generator that needs to be understood before someone can get
+something working.  Second, it makes it easier to change things. In particular,
+if tables and other things are all emitted by <tt class="docutils literal"><span class="pre">tblgen</span></tt>, we only need a change
+in one place (<tt class="docutils literal"><span class="pre">tblgen</span></tt>) to update all of the targets to a new interface.</p>
+</div>
+</div>
+<div class="section" id="target-description-classes">
+<span id="target-description"></span><span id="abstract-target-description"></span><h2><a class="toc-backref" href="#id12">Target description classes</a><a class="headerlink" href="#target-description-classes" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM target description classes (located in the <tt class="docutils literal"><span class="pre">include/llvm/Target</span></tt>
+directory) provide an abstract description of the target machine independent of
+any particular client.  These classes are designed to capture the <em>abstract</em>
+properties of the target (such as the instructions and registers it has), and do
+not incorporate any particular pieces of code generation algorithms.</p>
+<p>All of the target description classes (except the <span class="raw-html"><tt></span> <a class="reference internal" href="#datalayout">DataLayout</a>
+<span class="raw-html"></tt></span> class) are designed to be subclassed by the concrete target
+implementation, and have virtual methods implemented.  To get to these
+implementations, the <span class="raw-html"><tt></span> <a class="reference internal" href="#targetmachine">TargetMachine</a> <span class="raw-html"></tt></span> class
+provides accessors that should be implemented by the target.</p>
+<div class="section" id="the-targetmachine-class">
+<span id="targetmachine"></span><h3><a class="toc-backref" href="#id13">The <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class</a><a class="headerlink" href="#the-targetmachine-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class provides virtual methods that are used to access the
+target-specific implementations of the various target description classes via
+the <tt class="docutils literal"><span class="pre">get*Info</span></tt> methods (<tt class="docutils literal"><span class="pre">getInstrInfo</span></tt>, <tt class="docutils literal"><span class="pre">getRegisterInfo</span></tt>,
+<tt class="docutils literal"><span class="pre">getFrameInfo</span></tt>, etc.).  This class is designed to be specialized by a concrete
+target implementation (e.g., <tt class="docutils literal"><span class="pre">X86TargetMachine</span></tt>) which implements the various
+virtual methods.  The only required target description class is the
+<span class="raw-html"><tt></span> <a class="reference internal" href="#datalayout">DataLayout</a> <span class="raw-html"></tt></span> class, but if the code
+generator components are to be used, the other interfaces should be implemented
+as well.</p>
+</div>
+<div class="section" id="the-datalayout-class">
+<span id="datalayout"></span><h3><a class="toc-backref" href="#id14">The <tt class="docutils literal"><span class="pre">DataLayout</span></tt> class</a><a class="headerlink" href="#the-datalayout-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">DataLayout</span></tt> class is the only required target description class, and it
+is the only class that is not extensible (you cannot derive a new class from
+it).  <tt class="docutils literal"><span class="pre">DataLayout</span></tt> specifies information about how the target lays out memory
+for structures, the alignment requirements for various data types, the size of
+pointers in the target, and whether the target is little-endian or
+big-endian.</p>
+</div>
+<div class="section" id="the-targetlowering-class">
+<span id="targetlowering"></span><h3><a class="toc-backref" href="#id15">The <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> class</a><a class="headerlink" href="#the-targetlowering-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> class is used by SelectionDAG based instruction selectors
+primarily to describe how LLVM code should be lowered to SelectionDAG
+operations.  Among other things, this class indicates:</p>
+<ul class="simple">
+<li>an initial register class to use for various <tt class="docutils literal"><span class="pre">ValueType</span></tt>s,</li>
+<li>which operations are natively supported by the target machine,</li>
+<li>the return type of <tt class="docutils literal"><span class="pre">setcc</span></tt> operations,</li>
+<li>the type to use for shift amounts, and</li>
+<li>various high-level characteristics, like whether it is profitable to turn
+division by a constant into a multiplication sequence.</li>
+</ul>
+</div>
+<div class="section" id="the-targetregisterinfo-class">
+<span id="targetregisterinfo"></span><h3><a class="toc-backref" href="#id16">The <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class</a><a class="headerlink" href="#the-targetregisterinfo-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class is used to describe the register file of the
+target and any interactions between the registers.</p>
+<p>Registers are represented in the code generator by unsigned integers.  Physical
+registers (those that actually exist in the target description) are unique
+small numbers, and virtual registers are generally large.  Note that
+register <tt class="docutils literal"><span class="pre">#0</span></tt> is reserved as a flag value.</p>
+<p>Each register in the processor description has an associated
+<tt class="docutils literal"><span class="pre">TargetRegisterDesc</span></tt> entry, which provides a textual name for the register
+(used for assembly output and debugging dumps) and a set of aliases (used to
+indicate whether one register overlaps with another).</p>
+<p>In addition to the per-register description, the <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class
+exposes a set of processor specific register classes (instances of the
+<tt class="docutils literal"><span class="pre">TargetRegisterClass</span></tt> class).  Each register class contains sets of registers
+that have the same properties (for example, they are all 32-bit integer
+registers).  Each SSA virtual register created by the instruction selector has
+an associated register class.  When the register allocator runs, it replaces
+virtual registers with a physical register in the set.</p>
+<p>The target-specific implementations of these classes is auto-generated from a
+<a class="reference external" href="TableGenFundamentals.html">TableGen</a> description of the register file.</p>
+</div>
+<div class="section" id="the-targetinstrinfo-class">
+<span id="targetinstrinfo"></span><h3><a class="toc-backref" href="#id17">The <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt> class</a><a class="headerlink" href="#the-targetinstrinfo-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt> class is used to describe the machine instructions
+supported by the target.  Descriptions define things like the mnemonic for
+the opcode, the number of operands, the list of implicit register uses and defs,
+whether the instruction has certain target-independent properties (accesses
+memory, is commutable, etc), and holds any target-specific flags.</p>
+</div>
+<div class="section" id="the-targetframeinfo-class">
+<h3><a class="toc-backref" href="#id18">The <tt class="docutils literal"><span class="pre">TargetFrameInfo</span></tt> class</a><a class="headerlink" href="#the-targetframeinfo-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetFrameInfo</span></tt> class is used to provide information about the stack
+frame layout of the target. It holds the direction of stack growth, the known
+stack alignment on entry to each function, and the offset to the local area.
+The offset to the local area is the offset from the stack pointer on function
+entry to the first location where function data (local variables, spill
+locations) can be stored.</p>
+</div>
+<div class="section" id="the-targetsubtarget-class">
+<h3><a class="toc-backref" href="#id19">The <tt class="docutils literal"><span class="pre">TargetSubtarget</span></tt> class</a><a class="headerlink" href="#the-targetsubtarget-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetSubtarget</span></tt> class is used to provide information about the specific
+chip set being targeted.  A sub-target informs code generation of which
+instructions are supported, instruction latencies and instruction execution
+itinerary; i.e., which processing units are used, in what order, and for how
+long.</p>
+</div>
+<div class="section" id="the-targetjitinfo-class">
+<h3><a class="toc-backref" href="#id20">The <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> class</a><a class="headerlink" href="#the-targetjitinfo-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> class exposes an abstract interface used by the
+Just-In-Time code generator to perform target-specific activities, such as
+emitting stubs.  If a <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> supports JIT code generation, it should
+provide one of these objects through the <tt class="docutils literal"><span class="pre">getJITInfo</span></tt> method.</p>
+</div>
+</div>
+<div class="section" id="machine-code-description-classes">
+<span id="machine-code-representation"></span><span id="code-being-generated"></span><h2><a class="toc-backref" href="#id21">Machine code description classes</a><a class="headerlink" href="#machine-code-description-classes" title="Permalink to this headline">¶</a></h2>
+<p>At the high-level, LLVM code is translated to a machine specific representation
+formed out of <span class="raw-html"><tt></span> <a class="reference internal" href="#machinefunction">MachineFunction</a> <span class="raw-html"></tt></span>,
+<span class="raw-html"><tt></span> <a class="reference internal" href="#machinebasicblock">MachineBasicBlock</a> <span class="raw-html"></tt></span>, and <span class="raw-html"><tt></span>
+<a class="reference internal" href="#machineinstr">MachineInstr</a> <span class="raw-html"></tt></span> instances (defined in
+<tt class="docutils literal"><span class="pre">include/llvm/CodeGen</span></tt>).  This representation is completely target agnostic,
+representing instructions in their most abstract form: an opcode and a series of
+operands.  This representation is designed to support both an SSA representation
+for machine code, as well as a register allocated, non-SSA form.</p>
+<div class="section" id="the-machineinstr-class">
+<span id="machineinstr"></span><h3><a class="toc-backref" href="#id22">The <tt class="docutils literal"><span class="pre">MachineInstr</span></tt> class</a><a class="headerlink" href="#the-machineinstr-class" title="Permalink to this headline">¶</a></h3>
+<p>Target machine instructions are represented as instances of the <tt class="docutils literal"><span class="pre">MachineInstr</span></tt>
+class.  This class is an extremely abstract way of representing machine
+instructions.  In particular, it only keeps track of an opcode number and a set
+of operands.</p>
+<p>The opcode number is a simple unsigned integer that only has meaning to a
+specific backend.  All of the instructions for a target should be defined in the
+<tt class="docutils literal"><span class="pre">*InstrInfo.td</span></tt> file for the target. The opcode enum values are auto-generated
+from this description.  The <tt class="docutils literal"><span class="pre">MachineInstr</span></tt> class does not have any information
+about how to interpret the instruction (i.e., what the semantics of the
+instruction are); for that you must refer to the <span class="raw-html"><tt></span>
+<a class="reference internal" href="#targetinstrinfo">TargetInstrInfo</a> <span class="raw-html"></tt></span> class.</p>
+<p>The operands of a machine instruction can be of several different types: a
+register reference, a constant integer, a basic block reference, etc.  In
+addition, a machine operand should be marked as a def or a use of the value
+(though only registers are allowed to be defs).</p>
+<p>By convention, the LLVM code generator orders instruction operands so that all
+register definitions come before the register uses, even on architectures that
+are normally printed in other orders.  For example, the SPARC add instruction:
+“<tt class="docutils literal"><span class="pre">add</span> <span class="pre">%i1,</span> <span class="pre">%i2,</span> <span class="pre">%i3</span></tt>” adds the “%i1”, and “%i2” registers and stores the
+result into the “%i3” register.  In the LLVM code generator, the operands should
+be stored as “<tt class="docutils literal"><span class="pre">%i3,</span> <span class="pre">%i1,</span> <span class="pre">%i2</span></tt>”: with the destination first.</p>
+<p>Keeping destination (definition) operands at the beginning of the operand list
+has several advantages.  In particular, the debugging printer will print the
+instruction like this:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="nv">%r3</span> <span class="p">=</span> <span class="k">add</span> <span class="nv">%i1</span><span class="p">,</span> <span class="nv">%i2</span>
+</pre></div>
+</div>
+<p>Also if the first operand is a def, it is easier to <a class="reference internal" href="#create-instructions">create instructions</a> whose
+only def is the first operand.</p>
+<div class="section" id="using-the-machineinstrbuilder-h-functions">
+<span id="create-instructions"></span><h4><a class="toc-backref" href="#id23">Using the <tt class="docutils literal"><span class="pre">MachineInstrBuilder.h</span></tt> functions</a><a class="headerlink" href="#using-the-machineinstrbuilder-h-functions" title="Permalink to this headline">¶</a></h4>
+<p>Machine instructions are created by using the <tt class="docutils literal"><span class="pre">BuildMI</span></tt> functions, located in
+the <tt class="docutils literal"><span class="pre">include/llvm/CodeGen/MachineInstrBuilder.h</span></tt> file.  The <tt class="docutils literal"><span class="pre">BuildMI</span></tt>
+functions make it easy to build arbitrary machine instructions.  Usage of the
+<tt class="docutils literal"><span class="pre">BuildMI</span></tt> functions look like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')</span>
+<span class="c1">// instruction.  The '1' specifies how many operands will be added.</span>
+<span class="n">MachineInstr</span> <span class="o">*</span><span class="n">MI</span> <span class="o">=</span> <span class="n">BuildMI</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">MOV32ri</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="n">DestReg</span><span class="p">).</span><span class="n">addImm</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+
+<span class="c1">// Create the same instr, but insert it at the end of a basic block.</span>
+<span class="n">MachineBasicBlock</span> <span class="o">&</span><span class="n">MBB</span> <span class="o">=</span> <span class="p">...</span>
+<span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">X86</span><span class="o">::</span><span class="n">MOV32ri</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="n">DestReg</span><span class="p">).</span><span class="n">addImm</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+
+<span class="c1">// Create the same instr, but insert it before a specified iterator point.</span>
+<span class="n">MachineBasicBlock</span><span class="o">::</span><span class="n">iterator</span> <span class="n">MBBI</span> <span class="o">=</span> <span class="p">...</span>
+<span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">MBBI</span><span class="p">,</span> <span class="n">X86</span><span class="o">::</span><span class="n">MOV32ri</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="n">DestReg</span><span class="p">).</span><span class="n">addImm</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+
+<span class="c1">// Create a 'cmp Reg, 0' instruction, no destination reg.</span>
+<span class="n">MI</span> <span class="o">=</span> <span class="n">BuildMI</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">CMP32ri</span><span class="p">,</span> <span class="mi">2</span><span class="p">).</span><span class="n">addReg</span><span class="p">(</span><span class="n">Reg</span><span class="p">).</span><span class="n">addImm</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
+
+<span class="c1">// Create an 'sahf' instruction which takes no operands and stores nothing.</span>
+<span class="n">MI</span> <span class="o">=</span> <span class="n">BuildMI</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">SAHF</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
+
+<span class="c1">// Create a self looping branch instruction.</span>
+<span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">X86</span><span class="o">::</span><span class="n">JNE</span><span class="p">,</span> <span class="mi">1</span><span class="p">).</span><span class="n">addMBB</span><span class="p">(</span><span class="o">&</span><span class="n">MBB</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The key thing to remember with the <tt class="docutils literal"><span class="pre">BuildMI</span></tt> functions is that you have to
+specify the number of operands that the machine instruction will take.  This
+allows for efficient memory allocation.  You also need to specify if operands
+default to be uses of values, not definitions.  If you need to add a definition
+operand (other than the optional destination register), you must explicitly mark
+it as such:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">MI</span><span class="p">.</span><span class="n">addReg</span><span class="p">(</span><span class="n">Reg</span><span class="p">,</span> <span class="n">RegState</span><span class="o">::</span><span class="n">Define</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="fixed-preassigned-registers">
+<h4><a class="toc-backref" href="#id24">Fixed (preassigned) registers</a><a class="headerlink" href="#fixed-preassigned-registers" title="Permalink to this headline">¶</a></h4>
+<p>One important issue that the code generator needs to be aware of is the presence
+of fixed registers.  In particular, there are often places in the instruction
+stream where the register allocator <em>must</em> arrange for a particular value to be
+in a particular register.  This can occur due to limitations of the instruction
+set (e.g., the X86 can only do a 32-bit divide with the <tt class="docutils literal"><span class="pre">EAX</span></tt>/<tt class="docutils literal"><span class="pre">EDX</span></tt>
+registers), or external factors like calling conventions.  In any case, the
+instruction selector should emit code that copies a virtual register into or out
+of a physical register when needed.</p>
+<p>For example, consider this simple LLVM example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="k">i32</span> <span class="vg">@test</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%X</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%Y</span><span class="p">)</span> <span class="p">{</span>
+  <span class="nv">%Z</span> <span class="p">=</span> <span class="k">udiv</span> <span class="k">i32</span> <span class="nv">%X</span><span class="p">,</span> <span class="nv">%Y</span>
+  <span class="k">ret</span> <span class="k">i32</span> <span class="nv">%Z</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The X86 instruction selector produces this machine code for the <tt class="docutils literal"><span class="pre">div</span></tt> and
+<tt class="docutils literal"><span class="pre">ret</span></tt> (use “<tt class="docutils literal"><span class="pre">llc</span> <span class="pre">X.bc</span> <span class="pre">-march=x86</span> <span class="pre">-print-machineinstrs</span></tt>” to get this):</p>
+<div class="highlight-llvm"><pre>;; Start of div
+%EAX = mov %reg1024           ;; Copy X (in reg1024) into EAX
+%reg1027 = sar %reg1024, 31
+%EDX = mov %reg1027           ;; Sign extend X into EDX
+idiv %reg1025                 ;; Divide by Y (in reg1025)
+%reg1026 = mov %EAX           ;; Read the result (Z) out of EAX
+
+;; Start of ret
+%EAX = mov %reg1026           ;; 32-bit return value goes in EAX
+ret</pre>
+</div>
+<p>By the end of code generation, the register allocator has coalesced the
+registers and deleted the resultant identity moves producing the following
+code:</p>
+<div class="highlight-llvm"><pre>;; X is in EAX, Y is in ECX
+mov %EAX, %EDX
+sar %EDX, 31
+idiv %ECX
+ret</pre>
+</div>
+<p>This approach is extremely general (if it can handle the X86 architecture, it
+can handle anything!) and allows all of the target specific knowledge about the
+instruction stream to be isolated in the instruction selector.  Note that
+physical registers should have a short lifetime for good code generation, and
+all physical registers are assumed dead on entry to and exit from basic blocks
+(before register allocation).  Thus, if you need a value to be live across basic
+block boundaries, it <em>must</em> live in a virtual register.</p>
+</div>
+<div class="section" id="call-clobbered-registers">
+<h4><a class="toc-backref" href="#id25">Call-clobbered registers</a><a class="headerlink" href="#call-clobbered-registers" title="Permalink to this headline">¶</a></h4>
+<p>Some machine instructions, like calls, clobber a large number of physical
+registers.  Rather than adding <tt class="docutils literal"><span class="pre"><def,dead></span></tt> operands for all of them, it is
+possible to use an <tt class="docutils literal"><span class="pre">MO_RegisterMask</span></tt> operand instead.  The register mask
+operand holds a bit mask of preserved registers, and everything else is
+considered to be clobbered by the instruction.</p>
+</div>
+<div class="section" id="machine-code-in-ssa-form">
+<h4><a class="toc-backref" href="#id26">Machine code in SSA form</a><a class="headerlink" href="#machine-code-in-ssa-form" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">MachineInstr</span></tt>‘s are initially selected in SSA-form, and are maintained in
+SSA-form until register allocation happens.  For the most part, this is
+trivially simple since LLVM is already in SSA form; LLVM PHI nodes become
+machine code PHI nodes, and virtual registers are only allowed to have a single
+definition.</p>
+<p>After register allocation, machine code is no longer in SSA-form because there
+are no virtual registers left in the code.</p>
+</div>
+</div>
+<div class="section" id="the-machinebasicblock-class">
+<span id="machinebasicblock"></span><h3><a class="toc-backref" href="#id27">The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class</a><a class="headerlink" href="#the-machinebasicblock-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class contains a list of machine instructions
+(<span class="raw-html"><tt></span> <a class="reference internal" href="#machineinstr">MachineInstr</a> <span class="raw-html"></tt></span> instances).  It roughly
+corresponds to the LLVM code input to the instruction selector, but there can be
+a one-to-many mapping (i.e. one LLVM basic block can map to multiple machine
+basic blocks). The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class has a “<tt class="docutils literal"><span class="pre">getBasicBlock</span></tt>” method,
+which returns the LLVM basic block that it comes from.</p>
+</div>
+<div class="section" id="the-machinefunction-class">
+<span id="machinefunction"></span><h3><a class="toc-backref" href="#id28">The <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> class</a><a class="headerlink" href="#the-machinefunction-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> class contains a list of machine basic blocks
+(<span class="raw-html"><tt></span> <a class="reference internal" href="#machinebasicblock">MachineBasicBlock</a> <span class="raw-html"></tt></span> instances).  It
+corresponds one-to-one with the LLVM function input to the instruction selector.
+In addition to a list of basic blocks, the <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> contains a a
+<tt class="docutils literal"><span class="pre">MachineConstantPool</span></tt>, a <tt class="docutils literal"><span class="pre">MachineFrameInfo</span></tt>, a <tt class="docutils literal"><span class="pre">MachineFunctionInfo</span></tt>, and
+a <tt class="docutils literal"><span class="pre">MachineRegisterInfo</span></tt>.  See <tt class="docutils literal"><span class="pre">include/llvm/CodeGen/MachineFunction.h</span></tt> for
+more information.</p>
+</div>
+<div class="section" id="machineinstr-bundles">
+<h3><a class="toc-backref" href="#id29"><tt class="docutils literal"><span class="pre">MachineInstr</span> <span class="pre">Bundles</span></tt></a><a class="headerlink" href="#machineinstr-bundles" title="Permalink to this headline">¶</a></h3>
+<p>LLVM code generator can model sequences of instructions as MachineInstr
+bundles. A MI bundle can model a VLIW group / pack which contains an arbitrary
+number of parallel instructions. It can also be used to model a sequential list
+of instructions (potentially with data dependencies) that cannot be legally
+separated (e.g. ARM Thumb2 IT blocks).</p>
+<p>Conceptually a MI bundle is a MI with a number of other MIs nested within:</p>
+<div class="highlight-python"><pre>--------------
+|   Bundle   | ---------
+--------------          \
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |
+--------------
+|   Bundle   | --------
+--------------         \
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |                  ...
+       |
+--------------
+|   Bundle   | --------
+--------------         \
+       |
+      ...</pre>
+</div>
+<p>MI bundle support does not change the physical representations of
+MachineBasicBlock and MachineInstr. All the MIs (including top level and nested
+ones) are stored as sequential list of MIs. The “bundled” MIs are marked with
+the ‘InsideBundle’ flag. A top level MI with the special BUNDLE opcode is used
+to represent the start of a bundle. It’s legal to mix BUNDLE MIs with indiviual
+MIs that are not inside bundles nor represent bundles.</p>
+<p>MachineInstr passes should operate on a MI bundle as a single unit. Member
+methods have been taught to correctly handle bundles and MIs inside bundles.
+The MachineBasicBlock iterator has been modified to skip over bundled MIs to
+enforce the bundle-as-a-single-unit concept. An alternative iterator
+instr_iterator has been added to MachineBasicBlock to allow passes to iterate
+over all of the MIs in a MachineBasicBlock, including those which are nested
+inside bundles. The top level BUNDLE instruction must have the correct set of
+register MachineOperand’s that represent the cumulative inputs and outputs of
+the bundled MIs.</p>
+<p>Packing / bundling of MachineInstr’s should be done as part of the register
+allocation super-pass. More specifically, the pass which determines what MIs
+should be bundled together must be done after code generator exits SSA form
+(i.e. after two-address pass, PHI elimination, and copy coalescing).  Bundles
+should only be finalized (i.e. adding BUNDLE MIs and input and output register
+MachineOperands) after virtual registers have been rewritten into physical
+registers. This requirement eliminates the need to add virtual register operands
+to BUNDLE instructions which would effectively double the virtual register def
+and use lists.</p>
+</div>
+</div>
+<div class="section" id="the-mc-layer">
+<span id="mc-layer"></span><h2><a class="toc-backref" href="#id30">The “MC” Layer</a><a class="headerlink" href="#the-mc-layer" title="Permalink to this headline">¶</a></h2>
+<p>The MC Layer is used to represent and process code at the raw machine code
+level, devoid of “high level” information like “constant pools”, “jump tables”,
+“global variables” or anything like that.  At this level, LLVM handles things
+like label names, machine instructions, and sections in the object file.  The
+code in this layer is used for a number of important purposes: the tail end of
+the code generator uses it to write a .s or .o file, and it is also used by the
+llvm-mc tool to implement standalone machine code assemblers and disassemblers.</p>
+<p>This section describes some of the important classes.  There are also a number
+of important subsystems that interact at this layer, they are described later in
+this manual.</p>
+<div class="section" id="the-mcstreamer-api">
+<span id="mcstreamer"></span><h3><a class="toc-backref" href="#id31">The <tt class="docutils literal"><span class="pre">MCStreamer</span></tt> API</a><a class="headerlink" href="#the-mcstreamer-api" title="Permalink to this headline">¶</a></h3>
+<p>MCStreamer is best thought of as an assembler API.  It is an abstract API which
+is <em>implemented</em> in different ways (e.g. to output a .s file, output an ELF .o
+file, etc) but whose API correspond directly to what you see in a .s file.
+MCStreamer has one method per directive, such as EmitLabel, EmitSymbolAttribute,
+SwitchSection, EmitValue (for .byte, .word), etc, which directly correspond to
+assembly level directives.  It also has an EmitInstruction method, which is used
+to output an MCInst to the streamer.</p>
+<p>This API is most important for two clients: the llvm-mc stand-alone assembler is
+effectively a parser that parses a line, then invokes a method on MCStreamer. In
+the code generator, the <a class="reference internal" href="#code-emission">Code Emission</a> phase of the code generator lowers
+higher level LLVM IR and Machine* constructs down to the MC layer, emitting
+directives through MCStreamer.</p>
+<p>On the implementation side of MCStreamer, there are two major implementations:
+one for writing out a .s file (MCAsmStreamer), and one for writing out a .o
+file (MCObjectStreamer).  MCAsmStreamer is a straight-forward implementation
+that prints out a directive for each method (e.g. <tt class="docutils literal"><span class="pre">EmitValue</span> <span class="pre">-></span> <span class="pre">.byte</span></tt>), but
+MCObjectStreamer implements a full assembler.</p>
+<p>For target specific directives, the MCStreamer has a MCTargetStreamer instance.
+Each target that needs it defines a class that inherits from it and is a lot
+like MCStreamer itself: It has one method per directive and two classes that
+inherit from it, a target object streamer and a target asm streamer. The target
+asm streamer just prints it (<tt class="docutils literal"><span class="pre">emitFnStart</span> <span class="pre">-></span> <span class="pre">.fnstrart</span></tt>), and the object
+streamer implement the assembler logic for it.</p>
+<p>To make llvm use these classes, the target initialization must call
+TargetRegistry::RegisterAsmStreamer and TargetRegistry::RegisterMCObjectStreamer
+passing callbacks that allocate the corresponding target streamer and pass it
+to createAsmStreamer or to the appropriate object streamer constructor.</p>
+</div>
+<div class="section" id="the-mccontext-class">
+<h3><a class="toc-backref" href="#id32">The <tt class="docutils literal"><span class="pre">MCContext</span></tt> class</a><a class="headerlink" href="#the-mccontext-class" title="Permalink to this headline">¶</a></h3>
+<p>The MCContext class is the owner of a variety of uniqued data structures at the
+MC layer, including symbols, sections, etc.  As such, this is the class that you
+interact with to create symbols and sections.  This class can not be subclassed.</p>
+</div>
+<div class="section" id="the-mcsymbol-class">
+<h3><a class="toc-backref" href="#id33">The <tt class="docutils literal"><span class="pre">MCSymbol</span></tt> class</a><a class="headerlink" href="#the-mcsymbol-class" title="Permalink to this headline">¶</a></h3>
+<p>The MCSymbol class represents a symbol (aka label) in the assembly file.  There
+are two interesting kinds of symbols: assembler temporary symbols, and normal
+symbols.  Assembler temporary symbols are used and processed by the assembler
+but are discarded when the object file is produced.  The distinction is usually
+represented by adding a prefix to the label, for example “L” labels are
+assembler temporary labels in MachO.</p>
+<p>MCSymbols are created by MCContext and uniqued there.  This means that MCSymbols
+can be compared for pointer equivalence to find out if they are the same symbol.
+Note that pointer inequality does not guarantee the labels will end up at
+different addresses though.  It’s perfectly legal to output something like this
+to the .s file:</p>
+<div class="highlight-python"><pre>foo:
+bar:
+  .byte 4</pre>
+</div>
+<p>In this case, both the foo and bar symbols will have the same address.</p>
+</div>
+<div class="section" id="the-mcsection-class">
+<h3><a class="toc-backref" href="#id34">The <tt class="docutils literal"><span class="pre">MCSection</span></tt> class</a><a class="headerlink" href="#the-mcsection-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MCSection</span></tt> class represents an object-file specific section. It is
+subclassed by object file specific implementations (e.g. <tt class="docutils literal"><span class="pre">MCSectionMachO</span></tt>,
+<tt class="docutils literal"><span class="pre">MCSectionCOFF</span></tt>, <tt class="docutils literal"><span class="pre">MCSectionELF</span></tt>) and these are created and uniqued by
+MCContext.  The MCStreamer has a notion of the current section, which can be
+changed with the SwitchToSection method (which corresponds to a ”.section”
+directive in a .s file).</p>
+</div>
+<div class="section" id="the-mcinst-class">
+<span id="mcinst"></span><h3><a class="toc-backref" href="#id35">The <tt class="docutils literal"><span class="pre">MCInst</span></tt> class</a><a class="headerlink" href="#the-mcinst-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MCInst</span></tt> class is a target-independent representation of an instruction.
+It is a simple class (much more so than <a class="reference internal" href="#machineinstr">MachineInstr</a>) that holds a
+target-specific opcode and a vector of MCOperands.  MCOperand, in turn, is a
+simple discriminated union of three cases: 1) a simple immediate, 2) a target
+register ID, 3) a symbolic expression (e.g. “<tt class="docutils literal"><span class="pre">Lfoo-Lbar+42</span></tt>”) as an MCExpr.</p>
+<p>MCInst is the common currency used to represent machine instructions at the MC
+layer.  It is the type used by the instruction encoder, the instruction printer,
+and the type generated by the assembly parser and disassembler.</p>
+</div>
+</div>
+<div class="section" id="target-independent-code-generation-algorithms">
+<span id="code-generation-algorithm"></span><span id="target-independent-algorithms"></span><h2><a class="toc-backref" href="#id36">Target-independent code generation algorithms</a><a class="headerlink" href="#target-independent-code-generation-algorithms" title="Permalink to this headline">¶</a></h2>
+<p>This section documents the phases described in the <a class="reference internal" href="#high-level-design-of-the-code-generator">high-level design of the
+code generator</a>.  It explains how they work and some of the rationale behind
+their design.</p>
+<div class="section" id="instruction-selection-section">
+<span id="instruction-selection"></span><span id="id1"></span><h3><a class="toc-backref" href="#id37">Instruction Selection</a><a class="headerlink" href="#instruction-selection-section" title="Permalink to this headline">¶</a></h3>
+<p>Instruction Selection is the process of translating LLVM code presented to the
+code generator into target-specific machine instructions.  There are several
+well-known ways to do this in the literature.  LLVM uses a SelectionDAG based
+instruction selector.</p>
+<p>Portions of the DAG instruction selector are generated from the target
+description (<tt class="docutils literal"><span class="pre">*.td</span></tt>) files.  Our goal is for the entire instruction selector
+to be generated from these <tt class="docutils literal"><span class="pre">.td</span></tt> files, though currently there are still
+things that require custom C++ code.</p>
+<div class="section" id="introduction-to-selectiondags">
+<span id="selectiondag"></span><h4><a class="toc-backref" href="#id38">Introduction to SelectionDAGs</a><a class="headerlink" href="#introduction-to-selectiondags" title="Permalink to this headline">¶</a></h4>
+<p>The SelectionDAG provides an abstraction for code representation in a way that
+is amenable to instruction selection using automatic techniques
+(e.g. dynamic-programming based optimal pattern matching selectors). It is also
+well-suited to other phases of code generation; in particular, instruction
+scheduling (SelectionDAG’s are very close to scheduling DAGs post-selection).
+Additionally, the SelectionDAG provides a host representation where a large
+variety of very-low-level (but target-independent) <a class="reference internal" href="#optimizations">optimizations</a> may be
+performed; ones which require extensive information about the instructions
+efficiently supported by the target.</p>
+<p>The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
+<tt class="docutils literal"><span class="pre">SDNode</span></tt> class.  The primary payload of the <tt class="docutils literal"><span class="pre">SDNode</span></tt> is its operation code
+(Opcode) that indicates what operation the node performs and the operands to the
+operation.  The various operation node types are described at the top of the
+<tt class="docutils literal"><span class="pre">include/llvm/CodeGen/SelectionDAGNodes.h</span></tt> file.</p>
+<p>Although most operations define a single value, each node in the graph may
+define multiple values.  For example, a combined div/rem operation will define
+both the dividend and the remainder. Many other situations require multiple
+values as well.  Each node also has some number of operands, which are edges to
+the node defining the used value.  Because nodes may define multiple values,
+edges are represented by instances of the <tt class="docutils literal"><span class="pre">SDValue</span></tt> class, which is a
+<tt class="docutils literal"><span class="pre"><SDNode,</span> <span class="pre">unsigned></span></tt> pair, indicating the node and result value being used,
+respectively.  Each value produced by an <tt class="docutils literal"><span class="pre">SDNode</span></tt> has an associated <tt class="docutils literal"><span class="pre">MVT</span></tt>
+(Machine Value Type) indicating what the type of the value is.</p>
+<p>SelectionDAGs contain two different kinds of values: those that represent data
+flow and those that represent control flow dependencies.  Data values are simple
+edges with an integer or floating point value type.  Control edges are
+represented as “chain” edges which are of type <tt class="docutils literal"><span class="pre">MVT::Other</span></tt>.  These edges
+provide an ordering between nodes that have side effects (such as loads, stores,
+calls, returns, etc).  All nodes that have side effects should take a token
+chain as input and produce a new one as output.  By convention, token chain
+inputs are always operand #0, and chain results are always the last value
+produced by an operation.</p>
+<p>A SelectionDAG has designated “Entry” and “Root” nodes.  The Entry node is
+always a marker node with an Opcode of <tt class="docutils literal"><span class="pre">ISD::EntryToken</span></tt>.  The Root node is
+the final side-effecting node in the token chain. For example, in a single basic
+block function it would be the return node.</p>
+<p>One important concept for SelectionDAGs is the notion of a “legal” vs.
+“illegal” DAG.  A legal DAG for a target is one that only uses supported
+operations and supported types.  On a 32-bit PowerPC, for example, a DAG with a
+value of type i1, i8, i16, or i64 would be illegal, as would a DAG that uses a
+SREM or UREM operation.  The <a class="reference internal" href="#legalize-types">legalize types</a> and <a class="reference internal" href="#legalize-operations">legalize operations</a> phases
+are responsible for turning an illegal DAG into a legal DAG.</p>
+</div>
+<div class="section" id="selectiondag-instruction-selection-process">
+<span id="selectiondag-process"></span><h4><a class="toc-backref" href="#id39">SelectionDAG Instruction Selection Process</a><a class="headerlink" href="#selectiondag-instruction-selection-process" title="Permalink to this headline">¶</a></h4>
+<p>SelectionDAG-based instruction selection consists of the following steps:</p>
+<ol class="arabic simple">
+<li><a class="reference internal" href="#build-initial-dag">Build initial DAG</a> — This stage performs a simple translation from the
+input LLVM code to an illegal SelectionDAG.</li>
+<li><a class="reference internal" href="#optimize-selectiondag">Optimize SelectionDAG</a> — This stage performs simple optimizations on the
+SelectionDAG to simplify it, and recognize meta instructions (like rotates
+and <tt class="docutils literal"><span class="pre">div</span></tt>/<tt class="docutils literal"><span class="pre">rem</span></tt> pairs) for targets that support these meta operations.
+This makes the resultant code more efficient and the <a class="reference internal" href="#select-instructions-from-dag">select instructions
+from DAG</a> phase (below) simpler.</li>
+<li><a class="reference internal" href="#legalize-selectiondag-types">Legalize SelectionDAG Types</a> — This stage transforms SelectionDAG nodes
+to eliminate any types that are unsupported on the target.</li>
+<li><a class="reference internal" href="#optimize-selectiondag">Optimize SelectionDAG</a> — The SelectionDAG optimizer is run to clean up
+redundancies exposed by type legalization.</li>
+<li><a class="reference internal" href="#legalize-selectiondag-ops">Legalize SelectionDAG Ops</a> — This stage transforms SelectionDAG nodes to
+eliminate any operations that are unsupported on the target.</li>
+<li><a class="reference internal" href="#optimize-selectiondag">Optimize SelectionDAG</a> — The SelectionDAG optimizer is run to eliminate
+inefficiencies introduced by operation legalization.</li>
+<li><a class="reference internal" href="#select-instructions-from-dag">Select instructions from DAG</a> — Finally, the target instruction selector
+matches the DAG operations to target instructions.  This process translates
+the target-independent input DAG into another DAG of target instructions.</li>
+<li><a class="reference internal" href="#selectiondag-scheduling-and-formation">SelectionDAG Scheduling and Formation</a> — The last phase assigns a linear
+order to the instructions in the target-instruction DAG and emits them into
+the MachineFunction being compiled.  This step uses traditional prepass
+scheduling techniques.</li>
+</ol>
+<p>After all of these steps are complete, the SelectionDAG is destroyed and the
+rest of the code generation passes are run.</p>
+<p>One great way to visualize what is going on here is to take advantage of a few
+LLC command line options.  The following options pop up a window displaying the
+SelectionDAG at specific times (if you only get errors printed to the console
+while using this, you probably <a class="reference external" href="ProgrammersManual.html#ViewGraph">need to configure your
+system</a> to add support for it).</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">-view-dag-combine1-dags</span></tt> displays the DAG after being built, before the
+first optimization pass.</li>
+<li><tt class="docutils literal"><span class="pre">-view-legalize-dags</span></tt> displays the DAG before Legalization.</li>
+<li><tt class="docutils literal"><span class="pre">-view-dag-combine2-dags</span></tt> displays the DAG before the second optimization
+pass.</li>
+<li><tt class="docutils literal"><span class="pre">-view-isel-dags</span></tt> displays the DAG before the Select phase.</li>
+<li><tt class="docutils literal"><span class="pre">-view-sched-dags</span></tt> displays the DAG before Scheduling.</li>
+</ul>
+<p>The <tt class="docutils literal"><span class="pre">-view-sunit-dags</span></tt> displays the Scheduler’s dependency graph.  This graph
+is based on the final SelectionDAG, with nodes that must be scheduled together
+bundled into a single scheduling-unit node, and with immediate operands and
+other nodes that aren’t relevant for scheduling omitted.</p>
+</div>
+<div class="section" id="initial-selectiondag-construction">
+<span id="build-initial-dag"></span><h4><a class="toc-backref" href="#id40">Initial SelectionDAG Construction</a><a class="headerlink" href="#initial-selectiondag-construction" title="Permalink to this headline">¶</a></h4>
+<p>The initial SelectionDAG is na<span class="raw-html">ï</span>vely peephole expanded from
+the LLVM input by the <tt class="docutils literal"><span class="pre">SelectionDAGBuilder</span></tt> class.  The intent of this pass
+is to expose as much low-level, target-specific details to the SelectionDAG as
+possible.  This pass is mostly hard-coded (e.g. an LLVM <tt class="docutils literal"><span class="pre">add</span></tt> turns into an
+<tt class="docutils literal"><span class="pre">SDNode</span> <span class="pre">add</span></tt> while a <tt class="docutils literal"><span class="pre">getelementptr</span></tt> is expanded into the obvious
+arithmetic). This pass requires target-specific hooks to lower calls, returns,
+varargs, etc.  For these features, the <span class="raw-html"><tt></span> <a class="reference internal" href="#targetlowering">TargetLowering</a>
+<span class="raw-html"></tt></span> interface is used.</p>
+</div>
+<div class="section" id="selectiondag-legalizetypes-phase">
+<span id="legalize-selectiondag-ops"></span><span id="legalize-selectiondag-types"></span><span id="legalize-types"></span><h4><a class="toc-backref" href="#id41">SelectionDAG LegalizeTypes Phase</a><a class="headerlink" href="#selectiondag-legalizetypes-phase" title="Permalink to this headline">¶</a></h4>
+<p>The Legalize phase is in charge of converting a DAG to only use the types that
+are natively supported by the target.</p>
+<p>There are two main ways of converting values of unsupported scalar types to
+values of supported types: converting small types to larger types (“promoting”),
+and breaking up large integer types into smaller ones (“expanding”).  For
+example, a target might require that all f32 values are promoted to f64 and that
+all i1/i8/i16 values are promoted to i32.  The same target might require that
+all i64 values be expanded into pairs of i32 values.  These changes can insert
+sign and zero extensions as needed to make sure that the final code has the same
+behavior as the input.</p>
+<p>There are two main ways of converting values of unsupported vector types to
+value of supported types: splitting vector types, multiple times if necessary,
+until a legal type is found, and extending vector types by adding elements to
+the end to round them out to legal types (“widening”).  If a vector gets split
+all the way down to single-element parts with no supported vector type being
+found, the elements are converted to scalars (“scalarizing”).</p>
+<p>A target implementation tells the legalizer which types are supported (and which
+register class to use for them) by calling the <tt class="docutils literal"><span class="pre">addRegisterClass</span></tt> method in
+its <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> constructor.</p>
+</div>
+<div class="section" id="selectiondag-legalize-phase">
+<span id="legalizer"></span><span id="legalize-operations"></span><h4><a class="toc-backref" href="#id42">SelectionDAG Legalize Phase</a><a class="headerlink" href="#selectiondag-legalize-phase" title="Permalink to this headline">¶</a></h4>
+<p>The Legalize phase is in charge of converting a DAG to only use the operations
+that are natively supported by the target.</p>
+<p>Targets often have weird constraints, such as not supporting every operation on
+every supported datatype (e.g. X86 does not support byte conditional moves and
+PowerPC does not support sign-extending loads from a 16-bit memory location).
+Legalize takes care of this by open-coding another sequence of operations to
+emulate the operation (“expansion”), by promoting one type to a larger type that
+supports the operation (“promotion”), or by using a target-specific hook to
+implement the legalization (“custom”).</p>
+<p>A target implementation tells the legalizer which operations are not supported
+(and which of the above three actions to take) by calling the
+<tt class="docutils literal"><span class="pre">setOperationAction</span></tt> method in its <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> constructor.</p>
+<p>Prior to the existence of the Legalize passes, we required that every target
+<a class="reference internal" href="#selector">selector</a> supported and handled every operator and type even if they are not
+natively supported.  The introduction of the Legalize phases allows all of the
+canonicalization patterns to be shared across targets, and makes it very easy to
+optimize the canonicalized code because it is still in the form of a DAG.</p>
+</div>
+<div class="section" id="selectiondag-optimization-phase-the-dag-combiner">
+<span id="selector"></span><span id="optimize-selectiondag"></span><span id="optimizations"></span><h4><a class="toc-backref" href="#id43">SelectionDAG Optimization Phase: the DAG Combiner</a><a class="headerlink" href="#selectiondag-optimization-phase-the-dag-combiner" title="Permalink to this headline">¶</a></h4>
+<p>The SelectionDAG optimization phase is run multiple times for code generation,
+immediately after the DAG is built and once after each legalization.  The first
+run of the pass allows the initial code to be cleaned up (e.g. performing
+optimizations that depend on knowing that the operators have restricted type
+inputs).  Subsequent runs of the pass clean up the messy code generated by the
+Legalize passes, which allows Legalize to be very simple (it can focus on making
+code legal instead of focusing on generating <em>good</em> and legal code).</p>
+<p>One important class of optimizations performed is optimizing inserted sign and
+zero extension instructions.  We currently use ad-hoc techniques, but could move
+to more rigorous techniques in the future.  Here are some good papers on the
+subject:</p>
+<p>“<a class="reference external" href="http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html">Widening integer arithmetic</a>” <span class="raw-html"><br></span>
+Kevin Redwine and Norman Ramsey <span class="raw-html"><br></span>
+International Conference on Compiler Construction (CC) 2004</p>
+<p>“<a class="reference external" href="http://portal.acm.org/citation.cfm?doid=512529.512552">Effective sign extension elimination</a>”  <span class="raw-html"><br></span>
+Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani <span class="raw-html"><br></span>
+Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
+and Implementation.</p>
+</div>
+<div class="section" id="selectiondag-select-phase">
+<span id="select-instructions-from-dag"></span><h4><a class="toc-backref" href="#id44">SelectionDAG Select Phase</a><a class="headerlink" href="#selectiondag-select-phase" title="Permalink to this headline">¶</a></h4>
+<p>The Select phase is the bulk of the target-specific code for instruction
+selection.  This phase takes a legal SelectionDAG as input, pattern matches the
+instructions supported by the target to this DAG, and produces a new DAG of
+target code.  For example, consider the following LLVM fragment:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="nv">%t1</span> <span class="p">=</span> <span class="k">fadd</span> <span class="kt">float</span> <span class="nv">%W</span><span class="p">,</span> <span class="nv">%X</span>
+<span class="nv">%t2</span> <span class="p">=</span> <span class="k">fmul</span> <span class="kt">float</span> <span class="nv">%t1</span><span class="p">,</span> <span class="nv">%Y</span>
+<span class="nv">%t3</span> <span class="p">=</span> <span class="k">fadd</span> <span class="kt">float</span> <span class="nv">%t2</span><span class="p">,</span> <span class="nv">%Z</span>
+</pre></div>
+</div>
+<p>This LLVM code corresponds to a SelectionDAG that looks basically like this:</p>
+<div class="highlight-llvm"><pre>(fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)</pre>
+</div>
+<p>If a target supports floating point multiply-and-add (FMA) operations, one of
+the adds can be merged with the multiply.  On the PowerPC, for example, the
+output of the instruction selector might look like this DAG:</p>
+<div class="highlight-python"><pre>(FMADDS (FADDS W, X), Y, Z)</pre>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">FMADDS</span></tt> instruction is a ternary instruction that multiplies its first
+two operands and adds the third (as single-precision floating-point numbers).
+The <tt class="docutils literal"><span class="pre">FADDS</span></tt> instruction is a simple binary single-precision add instruction.
+To perform this pattern match, the PowerPC backend includes the following
+instruction definitions:</p>
+<div class="highlight-text"><div class="highlight"><pre>def FMADDS : AForm_1<59, 29,
+                    (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
+                    "fmadds $FRT, $FRA, $FRC, $FRB",
+<span class="hll">                    [(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
+</span><span class="hll">                                           F4RC:$FRB))]>;
+</span>def FADDS : AForm_2<59, 21,
+                    (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
+                    "fadds $FRT, $FRA, $FRB",
+<span class="hll">                    [(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))]>;
+</span></pre></div>
+</div>
+<p>The highlighted portion of the instruction definitions indicates the pattern
+used to match the instructions. The DAG operators (like <tt class="docutils literal"><span class="pre">fmul</span></tt>/<tt class="docutils literal"><span class="pre">fadd</span></tt>)
+are defined in the <tt class="docutils literal"><span class="pre">include/llvm/Target/TargetSelectionDAG.td</span></tt> file.
+“<tt class="docutils literal"><span class="pre">F4RC</span></tt>” is the register class of the input and result values.</p>
+<p>The TableGen DAG instruction selector generator reads the instruction patterns
+in the <tt class="docutils literal"><span class="pre">.td</span></tt> file and automatically builds parts of the pattern matching code
+for your target.  It has the following strengths:</p>
+<ul>
+<li><p class="first">At compiler-compiler time, it analyzes your instruction patterns and tells you
+if your patterns make sense or not.</p>
+</li>
+<li><p class="first">It can handle arbitrary constraints on operands for the pattern match.  In
+particular, it is straight-forward to say things like “match any immediate
+that is a 13-bit sign-extended value”.  For examples, see the <tt class="docutils literal"><span class="pre">immSExt16</span></tt>
+and related <tt class="docutils literal"><span class="pre">tblgen</span></tt> classes in the PowerPC backend.</p>
+</li>
+<li><p class="first">It knows several important identities for the patterns defined.  For example,
+it knows that addition is commutative, so it allows the <tt class="docutils literal"><span class="pre">FMADDS</span></tt> pattern
+above to match “<tt class="docutils literal"><span class="pre">(fadd</span> <span class="pre">X,</span> <span class="pre">(fmul</span> <span class="pre">Y,</span> <span class="pre">Z))</span></tt>” as well as “<tt class="docutils literal"><span class="pre">(fadd</span> <span class="pre">(fmul</span> <span class="pre">X,</span> <span class="pre">Y),</span>
+<span class="pre">Z)</span></tt>”, without the target author having to specially handle this case.</p>
+</li>
+<li><p class="first">It has a full-featured type-inferencing system.  In particular, you should
+rarely have to explicitly tell the system what type parts of your patterns
+are.  In the <tt class="docutils literal"><span class="pre">FMADDS</span></tt> case above, we didn’t have to tell <tt class="docutils literal"><span class="pre">tblgen</span></tt> that all
+of the nodes in the pattern are of type ‘f32’.  It was able to infer and
+propagate this knowledge from the fact that <tt class="docutils literal"><span class="pre">F4RC</span></tt> has type ‘f32’.</p>
+</li>
+<li><p class="first">Targets can define their own (and rely on built-in) “pattern fragments”.
+Pattern fragments are chunks of reusable patterns that get inlined into your
+patterns during compiler-compiler time.  For example, the integer “<tt class="docutils literal"><span class="pre">(not</span>
+<span class="pre">x)</span></tt>” operation is actually defined as a pattern fragment that expands as
+“<tt class="docutils literal"><span class="pre">(xor</span> <span class="pre">x,</span> <span class="pre">-1)</span></tt>”, since the SelectionDAG does not have a native ‘<tt class="docutils literal"><span class="pre">not</span></tt>‘
+operation.  Targets can define their own short-hand fragments as they see fit.
+See the definition of ‘<tt class="docutils literal"><span class="pre">not</span></tt>‘ and ‘<tt class="docutils literal"><span class="pre">ineg</span></tt>‘ for examples.</p>
+</li>
+<li><p class="first">In addition to instructions, targets can specify arbitrary patterns that map
+to one or more instructions using the ‘Pat’ class.  For example, the PowerPC
+has no way to load an arbitrary integer immediate into a register in one
+instruction. To tell tblgen how to do this, it defines:</p>
+<div class="highlight-python"><pre>// Arbitrary immediate support.  Implement in terms of LIS/ORI.
+def : Pat<(i32 imm:$imm),
+          (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;</pre>
+</div>
+<p>If none of the single-instruction patterns for loading an immediate into a
+register match, this will be used.  This rule says “match an arbitrary i32
+immediate, turning it into an <tt class="docutils literal"><span class="pre">ORI</span></tt> (‘or a 16-bit immediate’) and an <tt class="docutils literal"><span class="pre">LIS</span></tt>
+(‘load 16-bit immediate, where the immediate is shifted to the left 16 bits’)
+instruction”.  To make this work, the <tt class="docutils literal"><span class="pre">LO16</span></tt>/<tt class="docutils literal"><span class="pre">HI16</span></tt> node transformations
+are used to manipulate the input immediate (in this case, take the high or low
+16-bits of the immediate).</p>
+</li>
+<li><p class="first">When using the ‘Pat’ class to map a pattern to an instruction that has one
+or more complex operands (like e.g. <a class="reference internal" href="#x86-addressing-mode">X86 addressing mode</a>), the pattern may
+either specify the operand as a whole using a <tt class="docutils literal"><span class="pre">ComplexPattern</span></tt>, or else it
+may specify the components of the complex operand separately.  The latter is
+done e.g. for pre-increment instructions by the PowerPC back end:</p>
+<div class="highlight-python"><pre>def STWU  : DForm_1<37, (outs ptr_rc:$ea_res), (ins GPRC:$rS, memri:$dst),
+                "stwu $rS, $dst", LdStStoreUpd, []>,
+                RegConstraint<"$dst.reg = $ea_res">, NoEncode<"$ea_res">;
+
+def : Pat<(pre_store GPRC:$rS, ptr_rc:$ptrreg, iaddroff:$ptroff),
+          (STWU GPRC:$rS, iaddroff:$ptroff, ptr_rc:$ptrreg)>;</pre>
+</div>
+<p>Here, the pair of <tt class="docutils literal"><span class="pre">ptroff</span></tt> and <tt class="docutils literal"><span class="pre">ptrreg</span></tt> operands is matched onto the
+complex operand <tt class="docutils literal"><span class="pre">dst</span></tt> of class <tt class="docutils literal"><span class="pre">memri</span></tt> in the <tt class="docutils literal"><span class="pre">STWU</span></tt> instruction.</p>
+</li>
+<li><p class="first">While the system does automate a lot, it still allows you to write custom C++
+code to match special cases if there is something that is hard to
+express.</p>
+</li>
+</ul>
+<p>While it has many strengths, the system currently has some limitations,
+primarily because it is a work in progress and is not yet finished:</p>
+<ul class="simple">
+<li>Overall, there is no way to define or match SelectionDAG nodes that define
+multiple values (e.g. <tt class="docutils literal"><span class="pre">SMUL_LOHI</span></tt>, <tt class="docutils literal"><span class="pre">LOAD</span></tt>, <tt class="docutils literal"><span class="pre">CALL</span></tt>, etc).  This is the
+biggest reason that you currently still <em>have to</em> write custom C++ code
+for your instruction selector.</li>
+<li>There is no great way to support matching complex addressing modes yet.  In
+the future, we will extend pattern fragments to allow them to define multiple
+values (e.g. the four operands of the <a class="reference internal" href="#x86-addressing-mode">X86 addressing mode</a>, which are
+currently matched with custom C++ code).  In addition, we’ll extend fragments
+so that a fragment can match multiple different patterns.</li>
+<li>We don’t automatically infer flags like <tt class="docutils literal"><span class="pre">isStore</span></tt>/<tt class="docutils literal"><span class="pre">isLoad</span></tt> yet.</li>
+<li>We don’t automatically generate the set of supported registers and operations
+for the <a class="reference internal" href="#legalizer">Legalizer</a> yet.</li>
+<li>We don’t have a way of tying in custom legalized nodes yet.</li>
+</ul>
+<p>Despite these limitations, the instruction selector generator is still quite
+useful for most of the binary and logical operations in typical instruction
+sets.  If you run into any problems or can’t figure out how to do something,
+please let Chris know!</p>
+</div>
+<div class="section" id="selectiondag-scheduling-and-formation-phase">
+<span id="selectiondag-scheduling-and-formation"></span><span id="scheduling-and-formation"></span><h4><a class="toc-backref" href="#id45">SelectionDAG Scheduling and Formation Phase</a><a class="headerlink" href="#selectiondag-scheduling-and-formation-phase" title="Permalink to this headline">¶</a></h4>
+<p>The scheduling phase takes the DAG of target instructions from the selection
+phase and assigns an order.  The scheduler can pick an order depending on
+various constraints of the machines (i.e. order for minimal register pressure or
+try to cover instruction latencies).  Once an order is established, the DAG is
+converted to a list of <span class="raw-html"><tt></span> <a class="reference internal" href="#machineinstr">MachineInstr</a>s <span class="raw-html"></tt></span> and
+the SelectionDAG is destroyed.</p>
+<p>Note that this phase is logically separate from the instruction selection phase,
+but is tied to it closely in the code because it operates on SelectionDAGs.</p>
+</div>
+<div class="section" id="future-directions-for-the-selectiondag">
+<h4><a class="toc-backref" href="#id46">Future directions for the SelectionDAG</a><a class="headerlink" href="#future-directions-for-the-selectiondag" title="Permalink to this headline">¶</a></h4>
+<ol class="arabic simple">
+<li>Optional function-at-a-time selection.</li>
+<li>Auto-generate entire selector from <tt class="docutils literal"><span class="pre">.td</span></tt> file.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="ssa-based-machine-code-optimizations">
+<span id="id2"></span><h3><a class="toc-backref" href="#id47">SSA-based Machine Code Optimizations</a><a class="headerlink" href="#ssa-based-machine-code-optimizations" title="Permalink to this headline">¶</a></h3>
+<p>To Be Written</p>
+</div>
+<div class="section" id="live-intervals">
+<h3><a class="toc-backref" href="#id48">Live Intervals</a><a class="headerlink" href="#live-intervals" title="Permalink to this headline">¶</a></h3>
+<p>Live Intervals are the ranges (intervals) where a variable is <em>live</em>.  They are
+used by some <a class="reference internal" href="#register-allocator">register allocator</a> passes to determine if two or more virtual
+registers which require the same physical register are live at the same point in
+the program (i.e., they conflict).  When this situation occurs, one virtual
+register must be <em>spilled</em>.</p>
+<div class="section" id="live-variable-analysis">
+<h4><a class="toc-backref" href="#id49">Live Variable Analysis</a><a class="headerlink" href="#live-variable-analysis" title="Permalink to this headline">¶</a></h4>
+<p>The first step in determining the live intervals of variables is to calculate
+the set of registers that are immediately dead after the instruction (i.e., the
+instruction calculates the value, but it is never used) and the set of registers
+that are used by the instruction, but are never used after the instruction
+(i.e., they are killed). Live variable information is computed for
+each <em>virtual</em> register and <em>register allocatable</em> physical register
+in the function.  This is done in a very efficient manner because it uses SSA to
+sparsely compute lifetime information for virtual registers (which are in SSA
+form) and only has to track physical registers within a block.  Before register
+allocation, LLVM can assume that physical registers are only live within a
+single basic block.  This allows it to do a single, local analysis to resolve
+physical register lifetimes within each basic block. If a physical register is
+not register allocatable (e.g., a stack pointer or condition codes), it is not
+tracked.</p>
+<p>Physical registers may be live in to or out of a function. Live in values are
+typically arguments in registers. Live out values are typically return values in
+registers. Live in values are marked as such, and are given a dummy “defining”
+instruction during live intervals analysis. If the last basic block of a
+function is a <tt class="docutils literal"><span class="pre">return</span></tt>, then it’s marked as using all live out values in the
+function.</p>
+<p><tt class="docutils literal"><span class="pre">PHI</span></tt> nodes need to be handled specially, because the calculation of the live
+variable information from a depth first traversal of the CFG of the function
+won’t guarantee that a virtual register used by the <tt class="docutils literal"><span class="pre">PHI</span></tt> node is defined
+before it’s used. When a <tt class="docutils literal"><span class="pre">PHI</span></tt> node is encountered, only the definition is
+handled, because the uses will be handled in other basic blocks.</p>
+<p>For each <tt class="docutils literal"><span class="pre">PHI</span></tt> node of the current basic block, we simulate an assignment at
+the end of the current basic block and traverse the successor basic blocks. If a
+successor basic block has a <tt class="docutils literal"><span class="pre">PHI</span></tt> node and one of the <tt class="docutils literal"><span class="pre">PHI</span></tt> node’s operands
+is coming from the current basic block, then the variable is marked as <em>alive</em>
+within the current basic block and all of its predecessor basic blocks, until
+the basic block with the defining instruction is encountered.</p>
+</div>
+<div class="section" id="live-intervals-analysis">
+<h4><a class="toc-backref" href="#id50">Live Intervals Analysis</a><a class="headerlink" href="#live-intervals-analysis" title="Permalink to this headline">¶</a></h4>
+<p>We now have the information available to perform the live intervals analysis and
+build the live intervals themselves.  We start off by numbering the basic blocks
+and machine instructions.  We then handle the “live-in” values.  These are in
+physical registers, so the physical register is assumed to be killed by the end
+of the basic block.  Live intervals for virtual registers are computed for some
+ordering of the machine instructions <tt class="docutils literal"><span class="pre">[1,</span> <span class="pre">N]</span></tt>.  A live interval is an interval
+<tt class="docutils literal"><span class="pre">[i,</span> <span class="pre">j)</span></tt>, where <tt class="docutils literal"><span class="pre">1</span> <span class="pre">>=</span> <span class="pre">i</span> <span class="pre">>=</span> <span class="pre">j</span> <span class="pre">></span> <span class="pre">N</span></tt>, for which a variable is live.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">More to come...</p>
+</div>
+</div>
+</div>
+<div class="section" id="register-allocator">
+<span id="register-allocation"></span><span id="id3"></span><h3><a class="toc-backref" href="#id51">Register Allocation</a><a class="headerlink" href="#register-allocator" title="Permalink to this headline">¶</a></h3>
+<p>The <em>Register Allocation problem</em> consists in mapping a program
+<span class="raw-html"><b><tt></span> P<sub>v</sub><span class="raw-html"></tt></b></span>, that can use an unbounded
+number of virtual registers, to a program <span class="raw-html"><b><tt></span> P<sub>p</sub><span class="raw-html"></tt></b></span> that contains a finite (possibly small) number of physical
+registers. Each target architecture has a different number of physical
+registers. If the number of physical registers is not enough to accommodate all
+the virtual registers, some of them will have to be mapped into memory. These
+virtuals are called <em>spilled virtuals</em>.</p>
+<div class="section" id="how-registers-are-represented-in-llvm">
+<h4><a class="toc-backref" href="#id52">How registers are represented in LLVM</a><a class="headerlink" href="#how-registers-are-represented-in-llvm" title="Permalink to this headline">¶</a></h4>
+<p>In LLVM, physical registers are denoted by integer numbers that normally range
+from 1 to 1023. To see how this numbering is defined for a particular
+architecture, you can read the <tt class="docutils literal"><span class="pre">GenRegisterNames.inc</span></tt> file for that
+architecture. For instance, by inspecting
+<tt class="docutils literal"><span class="pre">lib/Target/X86/X86GenRegisterInfo.inc</span></tt> we see that the 32-bit register
+<tt class="docutils literal"><span class="pre">EAX</span></tt> is denoted by 43, and the MMX register <tt class="docutils literal"><span class="pre">MM0</span></tt> is mapped to 65.</p>
+<p>Some architectures contain registers that share the same physical location. A
+notable example is the X86 platform. For instance, in the X86 architecture, the
+registers <tt class="docutils literal"><span class="pre">EAX</span></tt>, <tt class="docutils literal"><span class="pre">AX</span></tt> and <tt class="docutils literal"><span class="pre">AL</span></tt> share the first eight bits. These physical
+registers are marked as <em>aliased</em> in LLVM. Given a particular architecture, you
+can check which registers are aliased by inspecting its <tt class="docutils literal"><span class="pre">RegisterInfo.td</span></tt>
+file. Moreover, the class <tt class="docutils literal"><span class="pre">MCRegAliasIterator</span></tt> enumerates all the physical
+registers aliased to a register.</p>
+<p>Physical registers, in LLVM, are grouped in <em>Register Classes</em>.  Elements in the
+same register class are functionally equivalent, and can be interchangeably
+used. Each virtual register can only be mapped to physical registers of a
+particular class. For instance, in the X86 architecture, some virtuals can only
+be allocated to 8 bit registers.  A register class is described by
+<tt class="docutils literal"><span class="pre">TargetRegisterClass</span></tt> objects.  To discover if a virtual register is
+compatible with a given physical, this code can be used:</p></p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">bool</span> <span class="n">RegMapping_Fer</span><span class="o">::</span><span class="n">compatible_class</span><span class="p">(</span><span class="n">MachineFunction</span> <span class="o">&</span><span class="n">mf</span><span class="p">,</span>
+                                      <span class="kt">unsigned</span> <span class="n">v_reg</span><span class="p">,</span>
+                                      <span class="kt">unsigned</span> <span class="n">p_reg</span><span class="p">)</span> <span class="p">{</span>
+  <span class="n">assert</span><span class="p">(</span><span class="n">TargetRegisterInfo</span><span class="o">::</span><span class="n">isPhysicalRegister</span><span class="p">(</span><span class="n">p_reg</span><span class="p">)</span> <span class="o">&&</span>
+         <span class="s">"Target register must be physical"</span><span class="p">);</span>
+  <span class="k">const</span> <span class="n">TargetRegisterClass</span> <span class="o">*</span><span class="n">trc</span> <span class="o">=</span> <span class="n">mf</span><span class="p">.</span><span class="n">getRegInfo</span><span class="p">().</span><span class="n">getRegClass</span><span class="p">(</span><span class="n">v_reg</span><span class="p">);</span>
+  <span class="k">return</span> <span class="n">trc</span><span class="o">-></span><span class="n">contains</span><span class="p">(</span><span class="n">p_reg</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Sometimes, mostly for debugging purposes, it is useful to change the number of
+physical registers available in the target architecture. This must be done
+statically, inside the <tt class="docutils literal"><span class="pre">TargetRegsterInfo.td</span></tt> file. Just <tt class="docutils literal"><span class="pre">grep</span></tt> for
+<tt class="docutils literal"><span class="pre">RegisterClass</span></tt>, the last parameter of which is a list of registers. Just
+commenting some out is one simple way to avoid them being used. A more polite
+way is to explicitly exclude some registers from the <em>allocation order</em>. See the
+definition of the <tt class="docutils literal"><span class="pre">GR8</span></tt> register class in
+<tt class="docutils literal"><span class="pre">lib/Target/X86/X86RegisterInfo.td</span></tt> for an example of this.</p>
+<p>Virtual registers are also denoted by integer numbers. Contrary to physical
+registers, different virtual registers never share the same number. Whereas
+physical registers are statically defined in a <tt class="docutils literal"><span class="pre">TargetRegisterInfo.td</span></tt> file
+and cannot be created by the application developer, that is not the case with
+virtual registers. In order to create new virtual registers, use the method
+<tt class="docutils literal"><span class="pre">MachineRegisterInfo::createVirtualRegister()</span></tt>. This method will return a new
+virtual register. Use an <tt class="docutils literal"><span class="pre">IndexedMap<Foo,</span> <span class="pre">VirtReg2IndexFunctor></span></tt> to hold
+information per virtual register. If you need to enumerate all virtual
+registers, use the function <tt class="docutils literal"><span class="pre">TargetRegisterInfo::index2VirtReg()</span></tt> to find the
+virtual register numbers:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">e</span> <span class="o">=</span> <span class="n">MRI</span><span class="o">-></span><span class="n">getNumVirtRegs</span><span class="p">();</span> <span class="n">i</span> <span class="o">!=</span> <span class="n">e</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span> <span class="p">{</span>
+  <span class="kt">unsigned</span> <span class="n">VirtReg</span> <span class="o">=</span> <span class="n">TargetRegisterInfo</span><span class="o">::</span><span class="n">index2VirtReg</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+  <span class="n">stuff</span><span class="p">(</span><span class="n">VirtReg</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Before register allocation, the operands of an instruction are mostly virtual
+registers, although physical registers may also be used. In order to check if a
+given machine operand is a register, use the boolean function
+<tt class="docutils literal"><span class="pre">MachineOperand::isRegister()</span></tt>. To obtain the integer code of a register, use
+<tt class="docutils literal"><span class="pre">MachineOperand::getReg()</span></tt>. An instruction may define or use a register. For
+instance, <tt class="docutils literal"><span class="pre">ADD</span> <span class="pre">reg:1026</span> <span class="pre">:=</span> <span class="pre">reg:1025</span> <span class="pre">reg:1024</span></tt> defines the registers 1024, and
+uses registers 1025 and 1026. Given a register operand, the method
+<tt class="docutils literal"><span class="pre">MachineOperand::isUse()</span></tt> informs if that register is being used by the
+instruction. The method <tt class="docutils literal"><span class="pre">MachineOperand::isDef()</span></tt> informs if that registers is
+being defined.</p>
+<p>We will call physical registers present in the LLVM bitcode before register
+allocation <em>pre-colored registers</em>. Pre-colored registers are used in many
+different situations, for instance, to pass parameters of functions calls, and
+to store results of particular instructions. There are two types of pre-colored
+registers: the ones <em>implicitly</em> defined, and those <em>explicitly</em>
+defined. Explicitly defined registers are normal operands, and can be accessed
+with <tt class="docutils literal"><span class="pre">MachineInstr::getOperand(int)::getReg()</span></tt>.  In order to check which
+registers are implicitly defined by an instruction, use the
+<tt class="docutils literal"><span class="pre">TargetInstrInfo::get(opcode)::ImplicitDefs</span></tt>, where <tt class="docutils literal"><span class="pre">opcode</span></tt> is the opcode
+of the target instruction. One important difference between explicit and
+implicit physical registers is that the latter are defined statically for each
+instruction, whereas the former may vary depending on the program being
+compiled. For example, an instruction that represents a function call will
+always implicitly define or use the same set of physical registers. To read the
+registers implicitly used by an instruction, use
+<tt class="docutils literal"><span class="pre">TargetInstrInfo::get(opcode)::ImplicitUses</span></tt>. Pre-colored registers impose
+constraints on any register allocation algorithm. The register allocator must
+make sure that none of them are overwritten by the values of virtual registers
+while still alive.</p>
+</div>
+<div class="section" id="mapping-virtual-registers-to-physical-registers">
+<h4><a class="toc-backref" href="#id53">Mapping virtual registers to physical registers</a><a class="headerlink" href="#mapping-virtual-registers-to-physical-registers" title="Permalink to this headline">¶</a></h4>
+<p>There are two ways to map virtual registers to physical registers (or to memory
+slots). The first way, that we will call <em>direct mapping</em>, is based on the use
+of methods of the classes <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt>, and <tt class="docutils literal"><span class="pre">MachineOperand</span></tt>. The
+second way, that we will call <em>indirect mapping</em>, relies on the <tt class="docutils literal"><span class="pre">VirtRegMap</span></tt>
+class in order to insert loads and stores sending and getting values to and from
+memory.</p>
+<p>The direct mapping provides more flexibility to the developer of the register
+allocator; however, it is more error prone, and demands more implementation
+work.  Basically, the programmer will have to specify where load and store
+instructions should be inserted in the target function being compiled in order
+to get and store values in memory. To assign a physical register to a virtual
+register present in a given operand, use <tt class="docutils literal"><span class="pre">MachineOperand::setReg(p_reg)</span></tt>. To
+insert a store instruction, use <tt class="docutils literal"><span class="pre">TargetInstrInfo::storeRegToStackSlot(...)</span></tt>,
+and to insert a load instruction, use <tt class="docutils literal"><span class="pre">TargetInstrInfo::loadRegFromStackSlot</span></tt>.</p>
+<p>The indirect mapping shields the application developer from the complexities of
+inserting load and store instructions. In order to map a virtual register to a
+physical one, use <tt class="docutils literal"><span class="pre">VirtRegMap::assignVirt2Phys(vreg,</span> <span class="pre">preg)</span></tt>.  In order to map
+a certain virtual register to memory, use
+<tt class="docutils literal"><span class="pre">VirtRegMap::assignVirt2StackSlot(vreg)</span></tt>. This method will return the stack
+slot where <tt class="docutils literal"><span class="pre">vreg</span></tt>‘s value will be located.  If it is necessary to map another
+virtual register to the same stack slot, use
+<tt class="docutils literal"><span class="pre">VirtRegMap::assignVirt2StackSlot(vreg,</span> <span class="pre">stack_location)</span></tt>. One important point
+to consider when using the indirect mapping, is that even if a virtual register
+is mapped to memory, it still needs to be mapped to a physical register. This
+physical register is the location where the virtual register is supposed to be
+found before being stored or after being reloaded.</p>
+<p>If the indirect strategy is used, after all the virtual registers have been
+mapped to physical registers or stack slots, it is necessary to use a spiller
+object to place load and store instructions in the code. Every virtual that has
+been mapped to a stack slot will be stored to memory after been defined and will
+be loaded before being used. The implementation of the spiller tries to recycle
+load/store instructions, avoiding unnecessary instructions. For an example of
+how to invoke the spiller, see <tt class="docutils literal"><span class="pre">RegAllocLinearScan::runOnMachineFunction</span></tt> in
+<tt class="docutils literal"><span class="pre">lib/CodeGen/RegAllocLinearScan.cpp</span></tt>.</p>
+</div>
+<div class="section" id="handling-two-address-instructions">
+<h4><a class="toc-backref" href="#id54">Handling two address instructions</a><a class="headerlink" href="#handling-two-address-instructions" title="Permalink to this headline">¶</a></h4>
+<p>With very rare exceptions (e.g., function calls), the LLVM machine code
+instructions are three address instructions. That is, each instruction is
+expected to define at most one register, and to use at most two registers.
+However, some architectures use two address instructions. In this case, the
+defined register is also one of the used register. For instance, an instruction
+such as <tt class="docutils literal"><span class="pre">ADD</span> <span class="pre">%EAX,</span> <span class="pre">%EBX</span></tt>, in X86 is actually equivalent to <tt class="docutils literal"><span class="pre">%EAX</span> <span class="pre">=</span> <span class="pre">%EAX</span> <span class="pre">+</span>
+<span class="pre">%EBX</span></tt>.</p>
+<p>In order to produce correct code, LLVM must convert three address instructions
+that represent two address instructions into true two address instructions. LLVM
+provides the pass <tt class="docutils literal"><span class="pre">TwoAddressInstructionPass</span></tt> for this specific purpose. It
+must be run before register allocation takes place. After its execution, the
+resulting code may no longer be in SSA form. This happens, for instance, in
+situations where an instruction such as <tt class="docutils literal"><span class="pre">%a</span> <span class="pre">=</span> <span class="pre">ADD</span> <span class="pre">%b</span> <span class="pre">%c</span></tt> is converted to two
+instructions such as:</p>
+<div class="highlight-python"><pre>%a = MOVE %b
+%a = ADD %a %c</pre>
+</div>
+<p>Notice that, internally, the second instruction is represented as <tt class="docutils literal"><span class="pre">ADD</span>
+<span class="pre">%a[def/use]</span> <span class="pre">%c</span></tt>. I.e., the register operand <tt class="docutils literal"><span class="pre">%a</span></tt> is both used and defined by
+the instruction.</p>
+</div>
+<div class="section" id="the-ssa-deconstruction-phase">
+<h4><a class="toc-backref" href="#id55">The SSA deconstruction phase</a><a class="headerlink" href="#the-ssa-deconstruction-phase" title="Permalink to this headline">¶</a></h4>
+<p>An important transformation that happens during register allocation is called
+the <em>SSA Deconstruction Phase</em>. The SSA form simplifies many analyses that are
+performed on the control flow graph of programs. However, traditional
+instruction sets do not implement PHI instructions. Thus, in order to generate
+executable code, compilers must replace PHI instructions with other instructions
+that preserve their semantics.</p>
+<p>There are many ways in which PHI instructions can safely be removed from the
+target code. The most traditional PHI deconstruction algorithm replaces PHI
+instructions with copy instructions. That is the strategy adopted by LLVM. The
+SSA deconstruction algorithm is implemented in
+<tt class="docutils literal"><span class="pre">lib/CodeGen/PHIElimination.cpp</span></tt>. In order to invoke this pass, the identifier
+<tt class="docutils literal"><span class="pre">PHIEliminationID</span></tt> must be marked as required in the code of the register
+allocator.</p>
+</div>
+<div class="section" id="instruction-folding">
+<h4><a class="toc-backref" href="#id56">Instruction folding</a><a class="headerlink" href="#instruction-folding" title="Permalink to this headline">¶</a></h4>
+<p><em>Instruction folding</em> is an optimization performed during register allocation
+that removes unnecessary copy instructions. For instance, a sequence of
+instructions such as:</p>
+<div class="highlight-python"><pre>%EBX = LOAD %mem_address
+%EAX = COPY %EBX</pre>
+</div>
+<p>can be safely substituted by the single instruction:</p>
+<div class="highlight-python"><pre>%EAX = LOAD %mem_address</pre>
+</div>
+<p>Instructions can be folded with the
+<tt class="docutils literal"><span class="pre">TargetRegisterInfo::foldMemoryOperand(...)</span></tt> method. Care must be taken when
+folding instructions; a folded instruction can be quite different from the
+original instruction. See <tt class="docutils literal"><span class="pre">LiveIntervals::addIntervalsForSpills</span></tt> in
+<tt class="docutils literal"><span class="pre">lib/CodeGen/LiveIntervalAnalysis.cpp</span></tt> for an example of its use.</p>
+</div>
+<div class="section" id="built-in-register-allocators">
+<h4><a class="toc-backref" href="#id57">Built in register allocators</a><a class="headerlink" href="#built-in-register-allocators" title="Permalink to this headline">¶</a></h4>
+<p>The LLVM infrastructure provides the application developer with three different
+register allocators:</p>
+<ul class="simple">
+<li><em>Fast</em> — This register allocator is the default for debug builds. It
+allocates registers on a basic block level, attempting to keep values in
+registers and reusing registers as appropriate.</li>
+<li><em>Basic</em> — This is an incremental approach to register allocation. Live
+ranges are assigned to registers one at a time in an order that is driven by
+heuristics. Since code can be rewritten on-the-fly during allocation, this
+framework allows interesting allocators to be developed as extensions. It is
+not itself a production register allocator but is a potentially useful
+stand-alone mode for triaging bugs and as a performance baseline.</li>
+<li><em>Greedy</em> — <em>The default allocator</em>. This is a highly tuned implementation of
+the <em>Basic</em> allocator that incorporates global live range splitting. This
+allocator works hard to minimize the cost of spill code.</li>
+<li><em>PBQP</em> — A Partitioned Boolean Quadratic Programming (PBQP) based register
+allocator. This allocator works by constructing a PBQP problem representing
+the register allocation problem under consideration, solving this using a PBQP
+solver, and mapping the solution back to a register assignment.</li>
+</ul>
+<p>The type of register allocator used in <tt class="docutils literal"><span class="pre">llc</span></tt> can be chosen with the command
+line option <tt class="docutils literal"><span class="pre">-regalloc=...</span></tt>:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>llc -regalloc<span class="o">=</span>linearscan file.bc -o ln.s
+<span class="nv">$ </span>llc -regalloc<span class="o">=</span>fast file.bc -o fa.s
+<span class="nv">$ </span>llc -regalloc<span class="o">=</span>pbqp file.bc -o pbqp.s
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="prolog-epilog-code-insertion">
+<span id="id4"></span><h3><a class="toc-backref" href="#id58">Prolog/Epilog Code Insertion</a><a class="headerlink" href="#prolog-epilog-code-insertion" title="Permalink to this headline">¶</a></h3>
+<p>Compact Unwind</p>
+<p>Throwing an exception requires <em>unwinding</em> out of a function. The information on
+how to unwind a given function is traditionally expressed in DWARF unwind
+(a.k.a. frame) info. But that format was originally developed for debuggers to
+backtrace, and each Frame Description Entry (FDE) requires ~20-30 bytes per
+function. There is also the cost of mapping from an address in a function to the
+corresponding FDE at runtime. An alternative unwind encoding is called <em>compact
+unwind</em> and requires just 4-bytes per function.</p>
+<p>The compact unwind encoding is a 32-bit value, which is encoded in an
+architecture-specific way. It specifies which registers to restore and from
+where, and how to unwind out of the function. When the linker creates a final
+linked image, it will create a <tt class="docutils literal"><span class="pre">__TEXT,__unwind_info</span></tt> section. This section is
+a small and fast way for the runtime to access unwind info for any given
+function. If we emit compact unwind info for the function, that compact unwind
+info will be encoded in the <tt class="docutils literal"><span class="pre">__TEXT,__unwind_info</span></tt> section. If we emit DWARF
+unwind info, the <tt class="docutils literal"><span class="pre">__TEXT,__unwind_info</span></tt> section will contain the offset of the
+FDE in the <tt class="docutils literal"><span class="pre">__TEXT,__eh_frame</span></tt> section in the final linked image.</p>
+<p>For X86, there are three modes for the compact unwind encoding:</p>
+<dl class="docutils">
+<dt><em>Function with a Frame Pointer (``EBP`` or ``RBP``)</em></dt>
+<dd><p class="first"><tt class="docutils literal"><span class="pre">EBP/RBP</span></tt>-based frame, where <tt class="docutils literal"><span class="pre">EBP/RBP</span></tt> is pushed onto the stack
+immediately after the return address, then <tt class="docutils literal"><span class="pre">ESP/RSP</span></tt> is moved to
+<tt class="docutils literal"><span class="pre">EBP/RBP</span></tt>. Thus to unwind, <tt class="docutils literal"><span class="pre">ESP/RSP</span></tt> is restored with the current
+<tt class="docutils literal"><span class="pre">EBP/RBP</span></tt> value, then <tt class="docutils literal"><span class="pre">EBP/RBP</span></tt> is restored by popping the stack, and the
+return is done by popping the stack once more into the PC. All non-volatile
+registers that need to be restored must have been saved in a small range on
+the stack that starts <tt class="docutils literal"><span class="pre">EBP-4</span></tt> to <tt class="docutils literal"><span class="pre">EBP-1020</span></tt> (<tt class="docutils literal"><span class="pre">RBP-8</span></tt> to
+<tt class="docutils literal"><span class="pre">RBP-1020</span></tt>). The offset (divided by 4 in 32-bit mode and 8 in 64-bit mode)
+is encoded in bits 16-23 (mask: <tt class="docutils literal"><span class="pre">0x00FF0000</span></tt>).  The registers saved are
+encoded in bits 0-14 (mask: <tt class="docutils literal"><span class="pre">0x00007FFF</span></tt>) as five 3-bit entries from the
+following table:</p>
+<blockquote class="last">
+<div><table border="1" class="docutils">
+<colgroup>
+<col width="33%" />
+<col width="31%" />
+<col width="36%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Compact Number</th>
+<th class="head">i386 Register</th>
+<th class="head">x86-64 Register</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>1</td>
+<td><tt class="docutils literal"><span class="pre">EBX</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">RBX</span></tt></td>
+</tr>
+<tr class="row-odd"><td>2</td>
+<td><tt class="docutils literal"><span class="pre">ECX</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R12</span></tt></td>
+</tr>
+<tr class="row-even"><td>3</td>
+<td><tt class="docutils literal"><span class="pre">EDX</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R13</span></tt></td>
+</tr>
+<tr class="row-odd"><td>4</td>
+<td><tt class="docutils literal"><span class="pre">EDI</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R14</span></tt></td>
+</tr>
+<tr class="row-even"><td>5</td>
+<td><tt class="docutils literal"><span class="pre">ESI</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R15</span></tt></td>
+</tr>
+<tr class="row-odd"><td>6</td>
+<td><tt class="docutils literal"><span class="pre">EBP</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">RBP</span></tt></td>
+</tr>
+</tbody>
+</table>
+</div></blockquote>
+</dd>
+<dt><em>Frameless with a Small Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)</em></dt>
+<dd>To return, a constant (encoded in the compact unwind encoding) is added to the
+<tt class="docutils literal"><span class="pre">ESP/RSP</span></tt>.  Then the return is done by popping the stack into the PC. All
+non-volatile registers that need to be restored must have been saved on the
+stack immediately after the return address. The stack size (divided by 4 in
+32-bit mode and 8 in 64-bit mode) is encoded in bits 16-23 (mask:
+<tt class="docutils literal"><span class="pre">0x00FF0000</span></tt>). There is a maximum stack size of 1024 bytes in 32-bit mode
+and 2048 in 64-bit mode. The number of registers saved is encoded in bits 9-12
+(mask: <tt class="docutils literal"><span class="pre">0x00001C00</span></tt>). Bits 0-9 (mask: <tt class="docutils literal"><span class="pre">0x000003FF</span></tt>) contain which
+registers were saved and their order. (See the
+<tt class="docutils literal"><span class="pre">encodeCompactUnwindRegistersWithoutFrame()</span></tt> function in
+<tt class="docutils literal"><span class="pre">lib/Target/X86FrameLowering.cpp</span></tt> for the encoding algorithm.)</dd>
+<dt><em>Frameless with a Large Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)</em></dt>
+<dd>This case is like the “Frameless with a Small Constant Stack Size” case, but
+the stack size is too large to encode in the compact unwind encoding. Instead
+it requires that the function contains “<tt class="docutils literal"><span class="pre">subl</span> <span class="pre">$nnnnnn,</span> <span class="pre">%esp</span></tt>” in its
+prolog. The compact encoding contains the offset to the <tt class="docutils literal"><span class="pre">$nnnnnn</span></tt> value in
+the function in bits 9-12 (mask: <tt class="docutils literal"><span class="pre">0x00001C00</span></tt>).</dd>
+</dl>
+</div>
+<div class="section" id="late-machine-code-optimizations">
+<span id="id5"></span><h3><a class="toc-backref" href="#id59">Late Machine Code Optimizations</a><a class="headerlink" href="#late-machine-code-optimizations" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">To Be Written</p>
+</div>
+</div>
+<div class="section" id="code-emission">
+<span id="id6"></span><h3><a class="toc-backref" href="#id60">Code Emission</a><a class="headerlink" href="#code-emission" title="Permalink to this headline">¶</a></h3>
+<p>The code emission step of code generation is responsible for lowering from the
+code generator abstractions (like <a class="reference internal" href="#machinefunction">MachineFunction</a>, <a class="reference internal" href="#machineinstr">MachineInstr</a>, etc) down
+to the abstractions used by the MC layer (<a class="reference internal" href="#mcinst">MCInst</a>, <a class="reference internal" href="#mcstreamer">MCStreamer</a>, etc).  This
+is done with a combination of several different classes: the (misnamed)
+target-independent AsmPrinter class, target-specific subclasses of AsmPrinter
+(such as SparcAsmPrinter), and the TargetLoweringObjectFile class.</p>
+<p>Since the MC layer works at the level of abstraction of object files, it doesn’t
+have a notion of functions, global variables etc.  Instead, it thinks about
+labels, directives, and instructions.  A key class used at this time is the
+MCStreamer class.  This is an abstract API that is implemented in different ways
+(e.g. to output a .s file, output an ELF .o file, etc) that is effectively an
+“assembler API”.  MCStreamer has one method per directive, such as EmitLabel,
+EmitSymbolAttribute, SwitchSection, etc, which directly correspond to assembly
+level directives.</p>
+<p>If you are interested in implementing a code generator for a target, there are
+three important things that you have to implement for your target:</p>
+<ol class="arabic simple">
+<li>First, you need a subclass of AsmPrinter for your target.  This class
+implements the general lowering process converting MachineFunction’s into MC
+label constructs.  The AsmPrinter base class provides a number of useful
+methods and routines, and also allows you to override the lowering process in
+some important ways.  You should get much of the lowering for free if you are
+implementing an ELF, COFF, or MachO target, because the
+TargetLoweringObjectFile class implements much of the common logic.</li>
+<li>Second, you need to implement an instruction printer for your target.  The
+instruction printer takes an <a class="reference internal" href="#mcinst">MCInst</a> and renders it to a raw_ostream as
+text.  Most of this is automatically generated from the .td file (when you
+specify something like “<tt class="docutils literal"><span class="pre">add</span> <span class="pre">$dst,</span> <span class="pre">$src1,</span> <span class="pre">$src2</span></tt>” in the instructions), but
+you need to implement routines to print operands.</li>
+<li>Third, you need to implement code that lowers a <a class="reference internal" href="#machineinstr">MachineInstr</a> to an MCInst,
+usually implemented in “<target>MCInstLower.cpp”.  This lowering process is
+often target specific, and is responsible for turning jump table entries,
+constant pool indices, global variable addresses, etc into MCLabels as
+appropriate.  This translation layer is also responsible for expanding pseudo
+ops used by the code generator into the actual machine instructions they
+correspond to. The MCInsts that are generated by this are fed into the
+instruction printer or the encoder.</li>
+</ol>
+<p>Finally, at your choosing, you can also implement an subclass of MCCodeEmitter
+which lowers MCInst’s into machine code bytes and relocations.  This is
+important if you want to support direct .o file emission, or would like to
+implement an assembler for your target.</p>
+</div>
+<div class="section" id="vliw-packetizer">
+<h3><a class="toc-backref" href="#id61">VLIW Packetizer</a><a class="headerlink" href="#vliw-packetizer" title="Permalink to this headline">¶</a></h3>
+<p>In a Very Long Instruction Word (VLIW) architecture, the compiler is responsible
+for mapping instructions to functional-units available on the architecture. To
+that end, the compiler creates groups of instructions called <em>packets</em> or
+<em>bundles</em>. The VLIW packetizer in LLVM is a target-independent mechanism to
+enable the packetization of machine instructions.</p>
+<div class="section" id="mapping-from-instructions-to-functional-units">
+<h4><a class="toc-backref" href="#id62">Mapping from instructions to functional units</a><a class="headerlink" href="#mapping-from-instructions-to-functional-units" title="Permalink to this headline">¶</a></h4>
+<p>Instructions in a VLIW target can typically be mapped to multiple functional
+units. During the process of packetizing, the compiler must be able to reason
+about whether an instruction can be added to a packet. This decision can be
+complex since the compiler has to examine all possible mappings of instructions
+to functional units. Therefore to alleviate compilation-time complexity, the
+VLIW packetizer parses the instruction classes of a target and generates tables
+at compiler build time. These tables can then be queried by the provided
+machine-independent API to determine if an instruction can be accommodated in a
+packet.</p>
+</div>
+<div class="section" id="how-the-packetization-tables-are-generated-and-used">
+<h4><a class="toc-backref" href="#id63">How the packetization tables are generated and used</a><a class="headerlink" href="#how-the-packetization-tables-are-generated-and-used" title="Permalink to this headline">¶</a></h4>
+<p>The packetizer reads instruction classes from a target’s itineraries and creates
+a deterministic finite automaton (DFA) to represent the state of a packet. A DFA
+consists of three major elements: inputs, states, and transitions. The set of
+inputs for the generated DFA represents the instruction being added to a
+packet. The states represent the possible consumption of functional units by
+instructions in a packet. In the DFA, transitions from one state to another
+occur on the addition of an instruction to an existing packet. If there is a
+legal mapping of functional units to instructions, then the DFA contains a
+corresponding transition. The absence of a transition indicates that a legal
+mapping does not exist and that the instruction cannot be added to the packet.</p>
+<p>To generate tables for a VLIW target, add <em>Target</em>GenDFAPacketizer.inc as a
+target to the Makefile in the target directory. The exported API provides three
+functions: <tt class="docutils literal"><span class="pre">DFAPacketizer::clearResources()</span></tt>,
+<tt class="docutils literal"><span class="pre">DFAPacketizer::reserveResources(MachineInstr</span> <span class="pre">*MI)</span></tt>, and
+<tt class="docutils literal"><span class="pre">DFAPacketizer::canReserveResources(MachineInstr</span> <span class="pre">*MI)</span></tt>. These functions allow
+a target packetizer to add an instruction to an existing packet and to check
+whether an instruction can be added to a packet. See
+<tt class="docutils literal"><span class="pre">llvm/CodeGen/DFAPacketizer.h</span></tt> for more information.</p>
+</div>
+</div>
+</div>
+<div class="section" id="implementing-a-native-assembler">
+<h2><a class="toc-backref" href="#id64">Implementing a Native Assembler</a><a class="headerlink" href="#implementing-a-native-assembler" title="Permalink to this headline">¶</a></h2>
+<p>Though you’re probably reading this because you want to write or maintain a
+compiler backend, LLVM also fully supports building a native assembler.
+We’ve tried hard to automate the generation of the assembler from the .td files
+(in particular the instruction syntax and encodings), which means that a large
+part of the manual and repetitive data entry can be factored and shared with the
+compiler.</p>
+<div class="section" id="instruction-parsing">
+<h3><a class="toc-backref" href="#id65">Instruction Parsing</a><a class="headerlink" href="#instruction-parsing" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">To Be Written</p>
+</div>
+</div>
+<div class="section" id="instruction-alias-processing">
+<h3><a class="toc-backref" href="#id66">Instruction Alias Processing</a><a class="headerlink" href="#instruction-alias-processing" title="Permalink to this headline">¶</a></h3>
+<p>Once the instruction is parsed, it enters the MatchInstructionImpl function.
+The MatchInstructionImpl function performs alias processing and then does actual
+matching.</p>
+<p>Alias processing is the phase that canonicalizes different lexical forms of the
+same instructions down to one representation.  There are several different kinds
+of alias that are possible to implement and they are listed below in the order
+that they are processed (which is in order from simplest/weakest to most
+complex/powerful).  Generally you want to use the first alias mechanism that
+meets the needs of your instruction, because it will allow a more concise
+description.</p>
+<div class="section" id="mnemonic-aliases">
+<h4><a class="toc-backref" href="#id67">Mnemonic Aliases</a><a class="headerlink" href="#mnemonic-aliases" title="Permalink to this headline">¶</a></h4>
+<p>The first phase of alias processing is simple instruction mnemonic remapping for
+classes of instructions which are allowed with two different mnemonics.  This
+phase is a simple and unconditionally remapping from one input mnemonic to one
+output mnemonic.  It isn’t possible for this form of alias to look at the
+operands at all, so the remapping must apply for all forms of a given mnemonic.
+Mnemonic aliases are defined simply, for example X86 has:</p>
+<div class="highlight-python"><pre>def : MnemonicAlias<"cbw",     "cbtw">;
+def : MnemonicAlias<"smovq",   "movsq">;
+def : MnemonicAlias<"fldcww",  "fldcw">;
+def : MnemonicAlias<"fucompi", "fucomip">;
+def : MnemonicAlias<"ud2a",    "ud2">;</pre>
+</div>
+<p>... and many others.  With a MnemonicAlias definition, the mnemonic is remapped
+simply and directly.  Though MnemonicAlias’s can’t look at any aspect of the
+instruction (such as the operands) they can depend on global modes (the same
+ones supported by the matcher), through a Requires clause:</p>
+<div class="highlight-python"><pre>def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
+def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;</pre>
+</div>
+<p>In this example, the mnemonic gets mapped into different a new one depending on
+the current instruction set.</p>
+</div>
+<div class="section" id="instruction-aliases">
+<h4><a class="toc-backref" href="#id68">Instruction Aliases</a><a class="headerlink" href="#instruction-aliases" title="Permalink to this headline">¶</a></h4>
+<p>The most general phase of alias processing occurs while matching is happening:
+it provides new forms for the matcher to match along with a specific instruction
+to generate.  An instruction alias has two parts: the string to match and the
+instruction to generate.  For example:</p>
+<div class="highlight-python"><pre>def : InstAlias<"movsx $src, $dst", (MOVSX16rr8W GR16:$dst, GR8  :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX16rm8W GR16:$dst, i8mem:$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr8  GR32:$dst, GR8  :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr16 GR32:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr8  GR64:$dst, GR8  :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr16 GR64:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr32 GR64:$dst, GR32 :$src)>;</pre>
+</div>
+<p>This shows a powerful example of the instruction aliases, matching the same
+mnemonic in multiple different ways depending on what operands are present in
+the assembly.  The result of instruction aliases can include operands in a
+different order than the destination instruction, and can use an input multiple
+times, for example:</p>
+<div class="highlight-python"><pre>def : InstAlias<"clrb $reg", (XOR8rr  GR8 :$reg, GR8 :$reg)>;
+def : InstAlias<"clrw $reg", (XOR16rr GR16:$reg, GR16:$reg)>;
+def : InstAlias<"clrl $reg", (XOR32rr GR32:$reg, GR32:$reg)>;
+def : InstAlias<"clrq $reg", (XOR64rr GR64:$reg, GR64:$reg)>;</pre>
+</div>
+<p>This example also shows that tied operands are only listed once.  In the X86
+backend, XOR8rr has two input GR8’s and one output GR8 (where an input is tied
+to the output).  InstAliases take a flattened operand list without duplicates
+for tied operands.  The result of an instruction alias can also use immediates
+and fixed physical registers which are added as simple immediate operands in the
+result, for example:</p>
+<div class="highlight-python"><pre>// Fixed Immediate operand.
+def : InstAlias<"aad", (AAD8i8 10)>;
+
+// Fixed register operand.
+def : InstAlias<"fcomi", (COM_FIr ST1)>;
+
+// Simple alias.
+def : InstAlias<"fcomi $reg", (COM_FIr RST:$reg)>;</pre>
+</div>
+<p>Instruction aliases can also have a Requires clause to make them subtarget
+specific.</p>
+<p>If the back-end supports it, the instruction printer can automatically emit the
+alias rather than what’s being aliased. It typically leads to better, more
+readable code. If it’s better to print out what’s being aliased, then pass a ‘0’
+as the third parameter to the InstAlias definition.</p>
+</div>
+</div>
+<div class="section" id="instruction-matching">
+<h3><a class="toc-backref" href="#id69">Instruction Matching</a><a class="headerlink" href="#instruction-matching" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">To Be Written</p>
+</div>
+</div>
+</div>
+<div class="section" id="target-specific-implementation-notes">
+<span id="implement-the-target-description"></span><span id="implementations-of-the-abstract-target-description-interfaces"></span><h2><a class="toc-backref" href="#id70">Target-specific Implementation Notes</a><a class="headerlink" href="#target-specific-implementation-notes" title="Permalink to this headline">¶</a></h2>
+<p>This section of the document explains features or design decisions that are
+specific to the code generator for a particular target.  First we start with a
+table that summarizes what features are supported by each target.</p>
+<div class="section" id="target-feature-matrix">
+<span id="id7"></span><h3><a class="toc-backref" href="#id71">Target Feature Matrix</a><a class="headerlink" href="#target-feature-matrix" title="Permalink to this headline">¶</a></h3>
+<p>Note that this table does not include the C backend or Cpp backends, since they
+do not use the target independent code generator infrastructure.  It also
+doesn’t list features that are not supported fully by any target yet.  It
+considers a feature to be supported if at least one subtarget supports it.  A
+feature being supported means that it is useful and works for most cases, it
+does not indicate that there are zero known bugs in the implementation.  Here is
+the key:</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><th>Unknown</th></span>
+<span class="raw-html"><th>Not Applicable</th></span>
+<span class="raw-html"><th>No support</th></span>
+<span class="raw-html"><th>Partial Support</th></span>
+<span class="raw-html"><th>Complete Support</th></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td class="unknown"></td></span>
+<span class="raw-html"><td class="na"></td></span>
+<span class="raw-html"><td class="no"></td></span>
+<span class="raw-html"><td class="partial"></td></span>
+<span class="raw-html"><td class="yes"></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>Here is the table:</p>
+<p><span class="raw-html"><table width="689" border="1" cellspacing="0"></span>
+<span class="raw-html"><tr><td></td></span>
+<span class="raw-html"><td colspan="13" align="center" style="background-color:#ffc">Target</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><th>Feature</th></span>
+<span class="raw-html"><th>ARM</th></span>
+<span class="raw-html"><th>Hexagon</th></span>
+<span class="raw-html"><th>MSP430</th></span>
+<span class="raw-html"><th>Mips</th></span>
+<span class="raw-html"><th>NVPTX</th></span>
+<span class="raw-html"><th>PowerPC</th></span>
+<span class="raw-html"><th>Sparc</th></span>
+<span class="raw-html"><th>SystemZ</th></span>
+<span class="raw-html"><th>X86</th></span>
+<span class="raw-html"><th>XCore</th></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_reliable">is generally reliable</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="yes"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_asmparser">assembly parser</a></td></span>
+<span class="raw-html"><td class="no"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="no"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_disassembler">disassembler</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="na"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_inlineasm">inline asm</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="yes"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_jit">jit</a></td></span>
+<span class="raw-html"><td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="na"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_objectwrite">.o file writing</a></td></span>
+<span class="raw-html"><td class="no"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="na"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a hr:raw-html:`ef="#feat_tailcall">tail calls</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="no"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="no"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_segstacks">segmented stacks</a></td></span>
+<span class="raw-html"><td class="no"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="no"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="no"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"></table></span></p>
+<div class="section" id="is-generally-reliable">
+<span id="feat-reliable"></span><h4><a class="toc-backref" href="#id72">Is Generally Reliable</a><a class="headerlink" href="#is-generally-reliable" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target is considered to be production quality.
+This indicates that the target has been used as a static compiler to compile
+large amounts of code by a variety of different people and is in continuous use.</p>
+</div>
+<div class="section" id="assembly-parser">
+<span id="feat-asmparser"></span><h4><a class="toc-backref" href="#id73">Assembly Parser</a><a class="headerlink" href="#assembly-parser" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports parsing target specific .s files
+by implementing the MCAsmParser interface.  This is required for llvm-mc to be
+able to act as a native assembler and is required for inline assembly support in
+the native .o file writer.</p>
+</div>
+<div class="section" id="disassembler">
+<span id="feat-disassembler"></span><h4><a class="toc-backref" href="#id74">Disassembler</a><a class="headerlink" href="#disassembler" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports the MCDisassembler API for
+disassembling machine opcode bytes into MCInst’s.</p>
+</div>
+<div class="section" id="inline-asm">
+<span id="feat-inlineasm"></span><h4><a class="toc-backref" href="#id75">Inline Asm</a><a class="headerlink" href="#inline-asm" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports most popular inline assembly
+constraints and modifiers.</p>
+</div>
+<div class="section" id="jit-support">
+<span id="feat-jit"></span><h4><a class="toc-backref" href="#id76">JIT Support</a><a class="headerlink" href="#jit-support" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports the JIT compiler through the
+ExecutionEngine interface.</p>
+<p id="feat-jit-arm">The ARM backend has basic support for integer code in ARM codegen mode, but
+lacks NEON and full Thumb support.</p>
+</div>
+<div class="section" id="o-file-writing">
+<span id="feat-objectwrite"></span><h4><a class="toc-backref" href="#id77">.o File Writing</a><a class="headerlink" href="#o-file-writing" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports writing .o files (e.g. MachO,
+ELF, and/or COFF) files directly from the target.  Note that the target also
+must include an assembly parser and general inline assembly support for full
+inline assembly support in the .o writer.</p>
+<p>Targets that don’t support this feature can obviously still write out .o files,
+they just rely on having an external assembler to translate from a .s file to a
+.o file (as is the case for many C compilers).</p>
+</div>
+<div class="section" id="tail-calls">
+<span id="feat-tailcall"></span><h4><a class="toc-backref" href="#id78">Tail Calls</a><a class="headerlink" href="#tail-calls" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports guaranteed tail calls.  These are
+calls marked “<a class="reference external" href="LangRef.html#i_call">tail</a>” and use the fastcc calling
+convention.  Please see the <a class="reference internal" href="#tail-call-section-more-more-details">tail call section more more details</a>.</p>
+</div>
+<div class="section" id="segmented-stacks">
+<span id="feat-segstacks"></span><h4><a class="toc-backref" href="#id79">Segmented Stacks</a><a class="headerlink" href="#segmented-stacks" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports segmented stacks. This replaces
+the traditional large C stack with many linked segments. It is compatible with
+the <a class="reference external" href="http://gcc.gnu.org/wiki/SplitStacks">gcc implementation</a> used by the Go
+front end.</p>
+<p id="feat-segstacks-x86">Basic support exists on the X86 backend. Currently vararg doesn’t work and the
+object files are not marked the way the gold linker expects, but simple Go
+programs can be built by dragonegg.</p>
+</div>
+</div>
+<div class="section" id="tail-call-optimization">
+<span id="tail-call-section-more-more-details"></span><h3><a class="toc-backref" href="#id80">Tail call optimization</a><a class="headerlink" href="#tail-call-optimization" title="Permalink to this headline">¶</a></h3>
+<p>Tail call optimization, callee reusing the stack of the caller, is currently
+supported on x86/x86-64 and PowerPC. It is performed if:</p>
+<ul class="simple">
+<li>Caller and callee have the calling convention <tt class="docutils literal"><span class="pre">fastcc</span></tt>, <tt class="docutils literal"><span class="pre">cc</span> <span class="pre">10</span></tt> (GHC
+calling convention) or <tt class="docutils literal"><span class="pre">cc</span> <span class="pre">11</span></tt> (HiPE calling convention).</li>
+<li>The call is a tail call - in tail position (ret immediately follows call and
+ret uses value of call or is void).</li>
+<li>Option <tt class="docutils literal"><span class="pre">-tailcallopt</span></tt> is enabled.</li>
+<li>Platform specific constraints are met.</li>
+</ul>
+<p>x86/x86-64 constraints:</p>
+<ul class="simple">
+<li>No variable argument lists are used.</li>
+<li>On x86-64 when generating GOT/PIC code only module-local calls (visibility =
+hidden or protected) are supported.</li>
+</ul>
+<p>PowerPC constraints:</p>
+<ul class="simple">
+<li>No variable argument lists are used.</li>
+<li>No byval parameters are used.</li>
+<li>On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected)
+are supported.</li>
+</ul>
+<p>Example:</p>
+<p>Call as <tt class="docutils literal"><span class="pre">llc</span> <span class="pre">-tailcallopt</span> <span class="pre">test.ll</span></tt>.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">declare</span> <span class="k">fastcc</span> <span class="k">i32</span> <span class="vg">@tailcallee</span><span class="p">(</span><span class="k">i32</span> <span class="k">inreg</span> <span class="nv">%a1</span><span class="p">,</span> <span class="k">i32</span> <span class="k">inreg</span> <span class="nv">%a2</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%a3</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%a4</span><span class="p">)</span>
+
+<span class="k">define</span> <span class="k">fastcc</span> <span class="k">i32</span> <span class="vg">@tailcaller</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%in1</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%in2</span><span class="p">)</span> <span class="p">{</span>
+  <span class="nv">%l1</span> <span class="p">=</span> <span class="k">add</span> <span class="k">i32</span> <span class="nv">%in1</span><span class="p">,</span> <span class="nv">%in2</span>
+  <span class="nv">%tmp</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">fastcc</span> <span class="k">i32</span> <span class="vg">@tailcallee</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%in1</span> <span class="k">inreg</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%in2</span> <span class="k">inreg</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%in1</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%l1</span><span class="p">)</span>
+  <span class="k">ret</span> <span class="k">i32</span> <span class="nv">%tmp</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Implications of <tt class="docutils literal"><span class="pre">-tailcallopt</span></tt>:</p>
+<p>To support tail call optimization in situations where the callee has more
+arguments than the caller a ‘callee pops arguments’ convention is used. This
+currently causes each <tt class="docutils literal"><span class="pre">fastcc</span></tt> call that is not tail call optimized (because
+one or more of above constraints are not met) to be followed by a readjustment
+of the stack. So performance might be worse in such cases.</p>
+</div>
+<div class="section" id="sibling-call-optimization">
+<h3><a class="toc-backref" href="#id81">Sibling call optimization</a><a class="headerlink" href="#sibling-call-optimization" title="Permalink to this headline">¶</a></h3>
+<p>Sibling call optimization is a restricted form of tail call optimization.
+Unlike tail call optimization described in the previous section, it can be
+performed automatically on any tail calls when <tt class="docutils literal"><span class="pre">-tailcallopt</span></tt> option is not
+specified.</p>
+<p>Sibling call optimization is currently performed on x86/x86-64 when the
+following constraints are met:</p>
+<ul class="simple">
+<li>Caller and callee have the same calling convention. It can be either <tt class="docutils literal"><span class="pre">c</span></tt> or
+<tt class="docutils literal"><span class="pre">fastcc</span></tt>.</li>
+<li>The call is a tail call - in tail position (ret immediately follows call and
+ret uses value of call or is void).</li>
+<li>Caller and callee have matching return type or the callee result is not used.</li>
+<li>If any of the callee arguments are being passed in stack, they must be
+available in caller’s own incoming argument stack and the frame offsets must
+be the same.</li>
+</ul>
+<p>Example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">declare</span> <span class="k">i32</span> <span class="vg">@bar</span><span class="p">(</span><span class="k">i32</span><span class="p">,</span> <span class="k">i32</span><span class="p">)</span>
+
+<span class="k">define</span> <span class="k">i32</span> <span class="vg">@foo</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%a</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%b</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%c</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+  <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">i32</span> <span class="vg">@bar</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%a</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%b</span><span class="p">)</span>
+  <span class="k">ret</span> <span class="k">i32</span> <span class="nv-Anonymous">%0</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="the-x86-backend">
+<h3><a class="toc-backref" href="#id82">The X86 backend</a><a class="headerlink" href="#the-x86-backend" title="Permalink to this headline">¶</a></h3>
+<p>The X86 code generator lives in the <tt class="docutils literal"><span class="pre">lib/Target/X86</span></tt> directory.  This code
+generator is capable of targeting a variety of x86-32 and x86-64 processors, and
+includes support for ISA extensions such as MMX and SSE.</p>
+<div class="section" id="x86-target-triples-supported">
+<h4><a class="toc-backref" href="#id83">X86 Target Triples supported</a><a class="headerlink" href="#x86-target-triples-supported" title="Permalink to this headline">¶</a></h4>
+<p>The following are the known target triples that are supported by the X86
+backend.  This is not an exhaustive list, and it would be useful to add those
+that people test.</p>
+<ul class="simple">
+<li><strong>i686-pc-linux-gnu</strong> — Linux</li>
+<li><strong>i386-unknown-freebsd5.3</strong> — FreeBSD 5.3</li>
+<li><strong>i686-pc-cygwin</strong> — Cygwin on Win32</li>
+<li><strong>i686-pc-mingw32</strong> — MingW on Win32</li>
+<li><strong>i386-pc-mingw32msvc</strong> — MingW crosscompiler on Linux</li>
+<li><strong>i686-apple-darwin*</strong> — Apple Darwin on X86</li>
+<li><strong>x86_64-unknown-linux-gnu</strong> — Linux</li>
+</ul>
+</div>
+<div class="section" id="x86-calling-conventions-supported">
+<h4><a class="toc-backref" href="#id84">X86 Calling Conventions supported</a><a class="headerlink" href="#x86-calling-conventions-supported" title="Permalink to this headline">¶</a></h4>
+<p>The following target-specific calling conventions are known to backend:</p>
+<ul class="simple">
+<li><strong>x86_StdCall</strong> — stdcall calling convention seen on Microsoft Windows
+platform (CC ID = 64).</li>
+<li><strong>x86_FastCall</strong> — fastcall calling convention seen on Microsoft Windows
+platform (CC ID = 65).</li>
+<li><strong>x86_ThisCall</strong> — Similar to X86_StdCall. Passes first argument in ECX,
+others via stack. Callee is responsible for stack cleaning. This convention is
+used by MSVC by default for methods in its ABI (CC ID = 70).</li>
+</ul>
+</div>
+<div class="section" id="representing-x86-addressing-modes-in-machineinstrs">
+<span id="x86-addressing-mode"></span><h4><a class="toc-backref" href="#id85">Representing X86 addressing modes in MachineInstrs</a><a class="headerlink" href="#representing-x86-addressing-modes-in-machineinstrs" title="Permalink to this headline">¶</a></h4>
+<p>The x86 has a very flexible way of accessing memory.  It is capable of forming
+memory addresses of the following expression directly in integer instructions
+(which use ModR/M addressing):</p>
+<div class="highlight-python"><pre>SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32</pre>
+</div>
+<p>In order to represent this, LLVM tracks no less than 5 operands for each memory
+operand of this form.  This means that the “load” form of ‘<tt class="docutils literal"><span class="pre">mov</span></tt>‘ has the
+following <tt class="docutils literal"><span class="pre">MachineOperand</span></tt>s in this order:</p>
+<div class="highlight-python"><pre>Index:        0     |    1        2       3           4          5
+Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement Segment
+OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm  PhysReg</pre>
+</div>
+<p>Stores, and all other instructions, treat the four memory operands in the same
+way and in the same order.  If the segment register is unspecified (regno = 0),
+then no segment override is generated.  “Lea” operations do not have a segment
+register specified, so they only have 4 operands for their memory reference.</p>
+</div>
+<div class="section" id="x86-address-spaces-supported">
+<h4><a class="toc-backref" href="#id86">X86 address spaces supported</a><a class="headerlink" href="#x86-address-spaces-supported" title="Permalink to this headline">¶</a></h4>
+<p>x86 has a feature which provides the ability to perform loads and stores to
+different address spaces via the x86 segment registers.  A segment override
+prefix byte on an instruction causes the instruction’s memory access to go to
+the specified segment.  LLVM address space 0 is the default address space, which
+includes the stack, and any unqualified memory accesses in a program.  Address
+spaces 1-255 are currently reserved for user-defined code.  The GS-segment is
+represented by address space 256, while the FS-segment is represented by address
+space 257. Other x86 segments have yet to be allocated address space
+numbers.</p>
+<p>While these address spaces may seem similar to TLS via the <tt class="docutils literal"><span class="pre">thread_local</span></tt>
+keyword, and often use the same underlying hardware, there are some fundamental
+differences.</p>
+<p>The <tt class="docutils literal"><span class="pre">thread_local</span></tt> keyword applies to global variables and specifies that they
+are to be allocated in thread-local memory. There are no type qualifiers
+involved, and these variables can be pointed to with normal pointers and
+accessed with normal loads and stores.  The <tt class="docutils literal"><span class="pre">thread_local</span></tt> keyword is
+target-independent at the LLVM IR level (though LLVM doesn’t yet have
+implementations of it for some configurations)</p>
+<p>Special address spaces, in contrast, apply to static types. Every load and store
+has a particular address space in its address operand type, and this is what
+determines which address space is accessed.  LLVM ignores these special address
+space qualifiers on global variables, and does not provide a way to directly
+allocate storage in them.  At the LLVM IR level, the behavior of these special
+address spaces depends in part on the underlying OS or runtime environment, and
+they are specific to x86 (and LLVM doesn’t yet handle them correctly in some
+cases).</p>
+<p>Some operating systems and runtime environments use (or may in the future use)
+the FS/GS-segment registers for various low-level purposes, so care should be
+taken when considering them.</p>
+</div>
+<div class="section" id="instruction-naming">
+<h4><a class="toc-backref" href="#id87">Instruction naming</a><a class="headerlink" href="#instruction-naming" title="Permalink to this headline">¶</a></h4>
+<p>An instruction name consists of the base name, a default operand size, and a a
+character per operand with an optional special size. For example:</p>
+<div class="highlight-python"><pre>ADD8rr      -> add, 8-bit register, 8-bit register
+IMUL16rmi   -> imul, 16-bit register, 16-bit memory, 16-bit immediate
+IMUL16rmi8  -> imul, 16-bit register, 16-bit memory, 8-bit immediate
+MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory</pre>
+</div>
+</div>
+</div>
+<div class="section" id="the-powerpc-backend">
+<h3><a class="toc-backref" href="#id88">The PowerPC backend</a><a class="headerlink" href="#the-powerpc-backend" title="Permalink to this headline">¶</a></h3>
+<p>The PowerPC code generator lives in the lib/Target/PowerPC directory.  The code
+generation is retargetable to several variations or <em>subtargets</em> of the PowerPC
+ISA; including ppc32, ppc64 and altivec.</p>
+<div class="section" id="llvm-powerpc-abi">
+<h4><a class="toc-backref" href="#id89">LLVM PowerPC ABI</a><a class="headerlink" href="#llvm-powerpc-abi" title="Permalink to this headline">¶</a></h4>
+<p>LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC relative
+(PIC) or static addressing for accessing global values, so no TOC (r2) is
+used. Second, r31 is used as a frame pointer to allow dynamic growth of a stack
+frame.  LLVM takes advantage of having no TOC to provide space to save the frame
+pointer in the PowerPC linkage area of the caller frame.  Other details of
+PowerPC ABI can be found at <a class="reference external" href="http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html">PowerPC ABI</a>. Note: This link describes the 32 bit ABI.  The 64 bit ABI is similar except
+space for GPRs are 8 bytes wide (not 4) and r13 is reserved for system use.</p>
+</div>
+<div class="section" id="frame-layout">
+<h4><a class="toc-backref" href="#id90">Frame Layout</a><a class="headerlink" href="#frame-layout" title="Permalink to this headline">¶</a></h4>
+<p>The size of a PowerPC frame is usually fixed for the duration of a function’s
+invocation.  Since the frame is fixed size, all references into the frame can be
+accessed via fixed offsets from the stack pointer.  The exception to this is
+when dynamic alloca or variable sized arrays are present, then a base pointer
+(r31) is used as a proxy for the stack pointer and stack pointer is free to grow
+or shrink.  A base pointer is also used if llvm-gcc is not passed the
+-fomit-frame-pointer flag. The stack pointer is always aligned to 16 bytes, so
+that space allocated for altivec vectors will be properly aligned.</p>
+<p>An invocation frame is laid out as follows (low memory at top):</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Linkage<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Parameter area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Dynamic area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Locals area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Saved registers area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr style="border-style: none hidden none hidden;"></span>
+<span class="raw-html"><td><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Previous Frame<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>The <em>linkage</em> area is used by a callee to save special registers prior to
+allocating its own frame.  Only three entries are relevant to LLVM. The first
+entry is the previous stack pointer (sp), aka link.  This allows probing tools
+like gdb or exception handlers to quickly scan the frames in the stack.  A
+function epilog can also use the link to pop the frame from the stack.  The
+third entry in the linkage area is used to save the return address from the lr
+register. Finally, as mentioned above, the last entry is used to save the
+previous frame pointer (r31.)  The entries in the linkage area are the size of a
+GPR, thus the linkage area is 24 bytes long in 32 bit mode and 48 bytes in 64
+bit mode.</p>
+<p>32 bit linkage area:</p>
+<p><span class="raw-html"><table  border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>0</td></span>
+<span class="raw-html"><td>Saved SP (r1)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>4</td></span>
+<span class="raw-html"><td>Saved CR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>8</td></span>
+<span class="raw-html"><td>Saved LR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>12</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>16</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>20</td></span>
+<span class="raw-html"><td>Saved FP (r31)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>64 bit linkage area:</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>0</td></span>
+<span class="raw-html"><td>Saved SP (r1)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>8</td></span>
+<span class="raw-html"><td>Saved CR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>16</td></span>
+<span class="raw-html"><td>Saved LR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>24</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>32</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>40</td></span>
+<span class="raw-html"><td>Saved FP (r31)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>The <em>parameter area</em> is used to store arguments being passed to a callee
+function.  Following the PowerPC ABI, the first few arguments are actually
+passed in registers, with the space in the parameter area unused.  However, if
+there are not enough registers or the callee is a thunk or vararg function,
+these register arguments can be spilled into the parameter area.  Thus, the
+parameter area must be large enough to store all the parameters for the largest
+call sequence made by the caller.  The size must also be minimally large enough
+to spill registers r3-r10.  This allows callees blind to the call signature,
+such as thunks and vararg functions, enough space to cache the argument
+registers.  Therefore, the parameter area is minimally 32 bytes (64 bytes in 64
+bit mode.)  Also note that since the parameter area is a fixed offset from the
+top of the frame, that a callee can access its spilt arguments using fixed
+offsets from the stack pointer (or base pointer.)</p>
+<p>Combining the information about the linkage, parameter areas and alignment. A
+stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit mode.</p>
+<p>The <em>dynamic area</em> starts out as size zero.  If a function uses dynamic alloca
+then space is added to the stack, the linkage and parameter areas are shifted to
+top of stack, and the new space is available immediately below the linkage and
+parameter areas.  The cost of shifting the linkage and parameter areas is minor
+since only the link value needs to be copied.  The link value can be easily
+fetched by adding the original frame size to the base pointer.  Note that
+allocations in the dynamic space need to observe 16 byte alignment.</p>
+<p>The <em>locals area</em> is where the llvm compiler reserves space for local variables.</p>
+<p>The <em>saved registers area</em> is where the llvm compiler spills callee saved
+registers on entry to the callee.</p>
+</div>
+<div class="section" id="prolog-epilog">
+<h4><a class="toc-backref" href="#id91">Prolog/Epilog</a><a class="headerlink" href="#prolog-epilog" title="Permalink to this headline">¶</a></h4>
+<p>The llvm prolog and epilog are the same as described in the PowerPC ABI, with
+the following exceptions.  Callee saved registers are spilled after the frame is
+created.  This allows the llvm epilog/prolog support to be common with other
+targets.  The base pointer callee saved register r31 is saved in the TOC slot of
+linkage area.  This simplifies allocation of space for the base pointer and
+makes it convenient to locate programatically and during debugging.</p>
+</div>
+<div class="section" id="dynamic-allocation">
+<h4><a class="toc-backref" href="#id92">Dynamic Allocation</a><a class="headerlink" href="#dynamic-allocation" title="Permalink to this headline">¶</a></h4>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">TODO - More to come.</p>
+</div>
+</div>
+</div>
+<div class="section" id="the-nvptx-backend">
+<h3><a class="toc-backref" href="#id93">The NVPTX backend</a><a class="headerlink" href="#the-nvptx-backend" title="Permalink to this headline">¶</a></h3>
+<p>The NVPTX code generator under lib/Target/NVPTX is an open-source version of
+the NVIDIA NVPTX code generator for LLVM.  It is contributed by NVIDIA and is
+a port of the code generator used in the CUDA compiler (nvcc).  It targets the
+PTX 3.0/3.1 ISA and can target any compute capability greater than or equal to
+2.0 (Fermi).</p>
+<p>This target is of production quality and should be completely compatible with
+the official NVIDIA toolchain.</p>
+<p>Code Generator Options:</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><th>Option</th></span>
+<span class="raw-html"><th>Description</th></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_20</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 2.0</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_21</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 2.1</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_30</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 3.0</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_35</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 3.5</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>ptx30</td></span>
+<span class="raw-html"><td align="left">Target PTX 3.0</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>ptx31</td></span>
+<span class="raw-html"><td align="left">Target PTX 3.1</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+</div>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="ExceptionHandling.html" title="Exception Handling in LLVM"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CodingStandards.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CodingStandards.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CodingStandards.html (added)
+++ www-releases/trunk/3.4.1/docs/CodingStandards.html Wed May  7 15:09:32 2014
@@ -0,0 +1,1312 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>LLVM Coding Standards — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="_static/jquery.js"></script>
+    <script type="text/javascript" src="_static/underscore.js"></script>
+    <script type="text/javascript" src="_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="index.html" />
+    <link rel="next" title="CommandLine 2.0 Library Manual" href="CommandLine.html" />
+    <link rel="prev" title="LLVM Atomic Instructions and Concurrency Guide" href="Atomics.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="index.html">
+    <img src="_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="CommandLine.html" title="CommandLine 2.0 Library Manual"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="Atomics.html" title="LLVM Atomic Instructions and Concurrency Guide"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-coding-standards">
+<h1>LLVM Coding Standards<a class="headerlink" href="#llvm-coding-standards" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#mechanical-source-issues" id="id2">Mechanical Source Issues</a><ul>
+<li><a class="reference internal" href="#source-code-formatting" id="id3">Source Code Formatting</a><ul>
+<li><a class="reference internal" href="#commenting" id="id4">Commenting</a><ul>
+<li><a class="reference internal" href="#file-headers" id="id5">File Headers</a></li>
+<li><a class="reference internal" href="#class-overviews" id="id6">Class overviews</a></li>
+<li><a class="reference internal" href="#method-information" id="id7">Method information</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#comment-formatting" id="id8">Comment Formatting</a></li>
+<li><a class="reference internal" href="#doxygen-use-in-documentation-comments" id="id9">Doxygen Use in Documentation Comments</a></li>
+<li><a class="reference internal" href="#include-style" id="id10"><tt class="docutils literal"><span class="pre">#include</span></tt> Style</a></li>
+<li><a class="reference internal" href="#source-code-width" id="id11">Source Code Width</a></li>
+<li><a class="reference internal" href="#use-spaces-instead-of-tabs" id="id12">Use Spaces Instead of Tabs</a></li>
+<li><a class="reference internal" href="#indent-code-consistently" id="id13">Indent Code Consistently</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#compiler-issues" id="id14">Compiler Issues</a><ul>
+<li><a class="reference internal" href="#treat-compiler-warnings-like-errors" id="id15">Treat Compiler Warnings Like Errors</a></li>
+<li><a class="reference internal" href="#write-portable-code" id="id16">Write Portable Code</a></li>
+<li><a class="reference internal" href="#do-not-use-rtti-or-exceptions" id="id17">Do not use RTTI or Exceptions</a></li>
+<li><a class="reference internal" href="#do-not-use-static-constructors" id="id18">Do not use Static Constructors</a></li>
+<li><a class="reference internal" href="#use-of-class-and-struct-keywords" id="id19">Use of <tt class="docutils literal"><span class="pre">class</span></tt> and <tt class="docutils literal"><span class="pre">struct</span></tt> Keywords</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#style-issues" id="id20">Style Issues</a><ul>
+<li><a class="reference internal" href="#the-high-level-issues" id="id21">The High-Level Issues</a><ul>
+<li><a class="reference internal" href="#a-public-header-file-is-a-module" id="id22">A Public Header File <strong>is</strong> a Module</a></li>
+<li><a class="reference internal" href="#include-as-little-as-possible" id="id23"><tt class="docutils literal"><span class="pre">#include</span></tt> as Little as Possible</a></li>
+<li><a class="reference internal" href="#keep-internal-headers-private" id="id24">Keep “Internal” Headers Private</a></li>
+<li><a class="reference internal" href="#use-early-exits-and-continue-to-simplify-code" id="id25">Use Early Exits and <tt class="docutils literal"><span class="pre">continue</span></tt> to Simplify Code</a></li>
+<li><a class="reference internal" href="#don-t-use-else-after-a-return" id="id26">Don’t use <tt class="docutils literal"><span class="pre">else</span></tt> after a <tt class="docutils literal"><span class="pre">return</span></tt></a></li>
+<li><a class="reference internal" href="#turn-predicate-loops-into-predicate-functions" id="id27">Turn Predicate Loops into Predicate Functions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-low-level-issues" id="id28">The Low-Level Issues</a><ul>
+<li><a class="reference internal" href="#name-types-functions-variables-and-enumerators-properly" id="id29">Name Types, Functions, Variables, and Enumerators Properly</a></li>
+<li><a class="reference internal" href="#assert-liberally" id="id30">Assert Liberally</a></li>
+<li><a class="reference internal" href="#do-not-use-using-namespace-std" id="id31">Do Not Use <tt class="docutils literal"><span class="pre">using</span> <span class="pre">namespace</span> <span class="pre">std</span></tt></a></li>
+<li><a class="reference internal" href="#provide-a-virtual-method-anchor-for-classes-in-headers" id="id32">Provide a Virtual Method Anchor for Classes in Headers</a></li>
+<li><a class="reference internal" href="#don-t-use-default-labels-in-fully-covered-switches-over-enumerations" id="id33">Don’t use default labels in fully covered switches over enumerations</a></li>
+<li><a class="reference internal" href="#use-llvm-deleted-function-to-mark-uncallable-methods" id="id34">Use <tt class="docutils literal"><span class="pre">LLVM_DELETED_FUNCTION</span></tt> to mark uncallable methods</a></li>
+<li><a class="reference internal" href="#don-t-evaluate-end-every-time-through-a-loop" id="id35">Don’t evaluate <tt class="docutils literal"><span class="pre">end()</span></tt> every time through a loop</a></li>
+<li><a class="reference internal" href="#include-iostream-is-forbidden" id="id36"><tt class="docutils literal"><span class="pre">#include</span> <span class="pre"><iostream></span></tt> is Forbidden</a></li>
+<li><a class="reference internal" href="#use-raw-ostream" id="id37">Use <tt class="docutils literal"><span class="pre">raw_ostream</span></tt></a></li>
+<li><a class="reference internal" href="#avoid-std-endl" id="id38">Avoid <tt class="docutils literal"><span class="pre">std::endl</span></tt></a></li>
+<li><a class="reference internal" href="#don-t-use-inline-when-defining-a-function-in-a-class-definition" id="id39">Don’t use <tt class="docutils literal"><span class="pre">inline</span></tt> when defining a function in a class definition</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#microscopic-details" id="id40">Microscopic Details</a><ul>
+<li><a class="reference internal" href="#spaces-before-parentheses" id="id41">Spaces Before Parentheses</a></li>
+<li><a class="reference internal" href="#prefer-preincrement" id="id42">Prefer Preincrement</a></li>
+<li><a class="reference internal" href="#namespace-indentation" id="id43">Namespace Indentation</a></li>
+<li><a class="reference internal" href="#anonymous-namespaces" id="id44">Anonymous Namespaces</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#see-also" id="id45">See Also</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document attempts to describe a few coding standards that are being used in
+the LLVM source tree.  Although no coding standards should be regarded as
+absolute requirements to be followed in all instances, coding standards are
+particularly important for large-scale code bases that follow a library-based
+design (like LLVM).</p>
+<p>This document intentionally does not prescribe fixed standards for religious
+issues such as brace placement and space usage.  For issues like this, follow
+the golden rule:</p>
+<blockquote id="golden-rule">
+<div><strong>If you are extending, enhancing, or bug fixing already implemented code,
+use the style that is already being used so that the source is uniform and
+easy to follow.</strong></div></blockquote>
+<p>Note that some code bases (e.g. <tt class="docutils literal"><span class="pre">libc++</span></tt>) have really good reasons to deviate
+from the coding standards.  In the case of <tt class="docutils literal"><span class="pre">libc++</span></tt>, this is because the
+naming and other conventions are dictated by the C++ standard.  If you think
+there is a specific good reason to deviate from the standards here, please bring
+it up on the LLVMdev mailing list.</p>
+<p>There are some conventions that are not uniformly followed in the code base
+(e.g. the naming convention).  This is because they are relatively new, and a
+lot of code was written before they were put in place.  Our long term goal is
+for the entire codebase to follow the convention, but we explicitly <em>do not</em>
+want patches that do large-scale reformating of existing code.  On the other
+hand, it is reasonable to rename the methods of a class if you’re about to
+change it in some other way.  Just do the reformating as a separate commit from
+the functionality change.</p>
+<p>The ultimate goal of these guidelines is the increase readability and
+maintainability of our common source base. If you have suggestions for topics to
+be included, please mail them to <a class="reference external" href="mailto:sabre%40nondot.org">Chris</a>.</p>
+</div>
+<div class="section" id="mechanical-source-issues">
+<h2><a class="toc-backref" href="#id2">Mechanical Source Issues</a><a class="headerlink" href="#mechanical-source-issues" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="source-code-formatting">
+<h3><a class="toc-backref" href="#id3">Source Code Formatting</a><a class="headerlink" href="#source-code-formatting" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="commenting">
+<h4><a class="toc-backref" href="#id4">Commenting</a><a class="headerlink" href="#commenting" title="Permalink to this headline">¶</a></h4>
+<p>Comments are one critical part of readability and maintainability.  Everyone
+knows they should comment their code, and so should you.  When writing comments,
+write them as English prose, which means they should use proper capitalization,
+punctuation, etc.  Aim to describe what the code is trying to do and why, not
+<em>how</em> it does it at a micro level. Here are a few critical things to document:</p>
+<div class="section" id="file-headers">
+<span id="header-file-comment"></span><h5><a class="toc-backref" href="#id5">File Headers</a><a class="headerlink" href="#file-headers" title="Permalink to this headline">¶</a></h5>
+<p>Every source file should have a header on it that describes the basic purpose of
+the file.  If a file does not have a header, it should not be checked into the
+tree.  The standard header looks like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">//===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//</span>
+<span class="c1">//</span>
+<span class="c1">//                     The LLVM Compiler Infrastructure</span>
+<span class="c1">//</span>
+<span class="c1">// This file is distributed under the University of Illinois Open Source</span>
+<span class="c1">// License. See LICENSE.TXT for details.</span>
+<span class="c1">//</span>
+<span class="c1">//===----------------------------------------------------------------------===//</span>
+<span class="c1">///</span>
+<span class="c1">/// \file</span>
+<span class="c1">/// \brief This file contains the declaration of the Instruction class, which is</span>
+<span class="c1">/// the base class for all of the VM instructions.</span>
+<span class="c1">///</span>
+<span class="c1">//===----------------------------------------------------------------------===//</span>
+</pre></div>
+</div>
+<p>A few things to note about this particular format: The “<tt class="docutils literal"><span class="pre">-*-</span> <span class="pre">C++</span> <span class="pre">-*-</span></tt>” string
+on the first line is there to tell Emacs that the source file is a C++ file, not
+a C file (Emacs assumes <tt class="docutils literal"><span class="pre">.h</span></tt> files are C files by default).</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This tag is not necessary in <tt class="docutils literal"><span class="pre">.cpp</span></tt> files.  The name of the file is also
+on the first line, along with a very short description of the purpose of the
+file.  This is important when printing out code and flipping though lots of
+pages.</p>
+</div>
+<p>The next section in the file is a concise note that defines the license that the
+file is released under.  This makes it perfectly clear what terms the source
+code can be distributed under and should not be modified in any way.</p>
+<p>The main body is a <tt class="docutils literal"><span class="pre">doxygen</span></tt> comment describing the purpose of the file.  It
+should have a <tt class="docutils literal"><span class="pre">\brief</span></tt> command that describes the file in one or two
+sentences.  Any additional information should be separated by a blank line.  If
+an algorithm is being implemented or something tricky is going on, a reference
+to the paper where it is published should be included, as well as any notes or
+<em>gotchas</em> in the code to watch out for.</p>
+</div>
+<div class="section" id="class-overviews">
+<h5><a class="toc-backref" href="#id6">Class overviews</a><a class="headerlink" href="#class-overviews" title="Permalink to this headline">¶</a></h5>
+<p>Classes are one fundamental part of a good object oriented design.  As such, a
+class definition should have a comment block that explains what the class is
+used for and how it works.  Every non-trivial class is expected to have a
+<tt class="docutils literal"><span class="pre">doxygen</span></tt> comment block.</p>
+</div>
+<div class="section" id="method-information">
+<h5><a class="toc-backref" href="#id7">Method information</a><a class="headerlink" href="#method-information" title="Permalink to this headline">¶</a></h5>
+<p>Methods defined in a class (as well as any global functions) should also be
+documented properly.  A quick note about what it does and a description of the
+borderline behaviour is all that is necessary here (unless something
+particularly tricky or insidious is going on).  The hope is that people can
+figure out how to use your interfaces without reading the code itself.</p>
+<p>Good things to talk about here are what happens when something unexpected
+happens: does the method return null?  Abort?  Format your hard disk?</p>
+</div>
+</div>
+<div class="section" id="comment-formatting">
+<h4><a class="toc-backref" href="#id8">Comment Formatting</a><a class="headerlink" href="#comment-formatting" title="Permalink to this headline">¶</a></h4>
+<p>In general, prefer C++ style (<tt class="docutils literal"><span class="pre">//</span></tt>) comments.  They take less space, require
+less typing, don’t have nesting problems, etc.  There are a few cases when it is
+useful to use C style (<tt class="docutils literal"><span class="pre">/*</span> <span class="pre">*/</span></tt>) comments however:</p>
+<ol class="arabic simple">
+<li>When writing C code: Obviously if you are writing C code, use C style
+comments.</li>
+<li>When writing a header file that may be <tt class="docutils literal"><span class="pre">#include</span></tt>d by a C source file.</li>
+<li>When writing a source file that is used by a tool that only accepts C style
+comments.</li>
+</ol>
+<p>To comment out a large block of code, use <tt class="docutils literal"><span class="pre">#if</span> <span class="pre">0</span></tt> and <tt class="docutils literal"><span class="pre">#endif</span></tt>. These nest
+properly and are better behaved in general than C style comments.</p>
+</div>
+<div class="section" id="doxygen-use-in-documentation-comments">
+<h4><a class="toc-backref" href="#id9">Doxygen Use in Documentation Comments</a><a class="headerlink" href="#doxygen-use-in-documentation-comments" title="Permalink to this headline">¶</a></h4>
+<p>Use the <tt class="docutils literal"><span class="pre">\file</span></tt> command to turn the standard file header into a file-level
+comment.</p>
+<p>Include descriptive <tt class="docutils literal"><span class="pre">\brief</span></tt> paragraphs for all public interfaces (public
+classes, member and non-member functions).  Explain API use and purpose in
+<tt class="docutils literal"><span class="pre">\brief</span></tt> paragraphs, don’t just restate the information that can be inferred
+from the API name.  Put detailed discussion into separate paragraphs.</p>
+<p>To refer to parameter names inside a paragraph, use the <tt class="docutils literal"><span class="pre">\p</span> <span class="pre">name</span></tt> command.
+Don’t use the <tt class="docutils literal"><span class="pre">\arg</span> <span class="pre">name</span></tt> command since it starts a new paragraph that
+contains documentation for the parameter.</p>
+<p>Wrap non-inline code examples in <tt class="docutils literal"><span class="pre">\code</span> <span class="pre">...</span> <span class="pre">\endcode</span></tt>.</p>
+<p>To document a function parameter, start a new paragraph with the
+<tt class="docutils literal"><span class="pre">\param</span> <span class="pre">name</span></tt> command.  If the parameter is used as an out or an in/out
+parameter, use the <tt class="docutils literal"><span class="pre">\param</span> <span class="pre">[out]</span> <span class="pre">name</span></tt> or <tt class="docutils literal"><span class="pre">\param</span> <span class="pre">[in,out]</span> <span class="pre">name</span></tt> command,
+respectively.</p>
+<p>To describe function return value, start a new paragraph with the <tt class="docutils literal"><span class="pre">\returns</span></tt>
+command.</p>
+<p>A minimal documentation comment:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">/// \brief Does foo and bar.</span>
+<span class="kt">void</span> <span class="nf">fooBar</span><span class="p">(</span><span class="kt">bool</span> <span class="n">Baz</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>A documentation comment that uses all Doxygen features in a preferred way:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">/// \brief Does foo and bar.</span>
+<span class="c1">///</span>
+<span class="c1">/// Does not do foo the usual way if \p Baz is true.</span>
+<span class="c1">///</span>
+<span class="c1">/// Typical usage:</span>
+<span class="c1">/// \code</span>
+<span class="c1">///   fooBar(false, "quux", Res);</span>
+<span class="c1">/// \endcode</span>
+<span class="c1">///</span>
+<span class="c1">/// \param Quux kind of foo to do.</span>
+<span class="c1">/// \param [out] Result filled with bar sequence on foo success.</span>
+<span class="c1">///</span>
+<span class="c1">/// \returns true on success.</span>
+<span class="kt">bool</span> <span class="nf">fooBar</span><span class="p">(</span><span class="kt">bool</span> <span class="n">Baz</span><span class="p">,</span> <span class="n">StringRef</span> <span class="n">Quux</span><span class="p">,</span> <span class="n">std</span><span class="o">::</span><span class="n">vector</span><span class="o"><</span><span class="kt">int</span><span class="o">></span> <span class="o">&</span><span class="n">Result</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>Don’t duplicate the documentation comment in the header file and in the
+implementation file.  Put the documentation comments for public APIs into the
+header file.  Documentation comments for private APIs can go to the
+implementation file.  In any case, implementation files can include additional
+comments (not necessarily in Doxygen markup) to explain implementation details
+as needed.</p>
+<p>Don’t duplicate function or class name at the beginning of the comment.
+For humans it is obvious which function or class is being documented;
+automatic documentation processing tools are smart enough to bind the comment
+to the correct declaration.</p>
+<p>Wrong:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// In Something.h:</span>
+
+<span class="c1">/// Something - An abstraction for some complicated thing.</span>
+<span class="k">class</span> <span class="nc">Something</span> <span class="p">{</span>
+<span class="nl">public:</span>
+  <span class="c1">/// fooBar - Does foo and bar.</span>
+  <span class="kt">void</span> <span class="n">fooBar</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="c1">// In Something.cpp:</span>
+
+<span class="c1">/// fooBar - Does foo and bar.</span>
+<span class="kt">void</span> <span class="n">Something</span><span class="o">::</span><span class="n">fooBar</span><span class="p">()</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
+</pre></div>
+</div>
+<p>Correct:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// In Something.h:</span>
+
+<span class="c1">/// \brief An abstraction for some complicated thing.</span>
+<span class="k">class</span> <span class="nc">Something</span> <span class="p">{</span>
+<span class="nl">public:</span>
+  <span class="c1">/// \brief Does foo and bar.</span>
+  <span class="kt">void</span> <span class="n">fooBar</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="c1">// In Something.cpp:</span>
+
+<span class="c1">// Builds a B-tree in order to do foo.  See paper by...</span>
+<span class="kt">void</span> <span class="n">Something</span><span class="o">::</span><span class="n">fooBar</span><span class="p">()</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
+</pre></div>
+</div>
+<p>It is not required to use additional Doxygen features, but sometimes it might
+be a good idea to do so.</p>
+<p>Consider:</p>
+<ul class="simple">
+<li>adding comments to any narrow namespace containing a collection of
+related functions or types;</li>
+<li>using top-level groups to organize a collection of related functions at
+namespace scope where the grouping is smaller than the namespace;</li>
+<li>using member groups and additional comments attached to member
+groups to organize within a class.</li>
+</ul>
+<p>For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Something</span> <span class="p">{</span>
+  <span class="c1">/// \name Functions that do Foo.</span>
+  <span class="c1">/// @{</span>
+  <span class="kt">void</span> <span class="n">fooBar</span><span class="p">();</span>
+  <span class="kt">void</span> <span class="nf">fooBaz</span><span class="p">();</span>
+  <span class="c1">/// @}</span>
+  <span class="p">...</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="include-style">
+<h4><a class="toc-backref" href="#id10"><tt class="docutils literal"><span class="pre">#include</span></tt> Style</a><a class="headerlink" href="#include-style" title="Permalink to this headline">¶</a></h4>
+<p>Immediately after the <a class="reference internal" href="#header-file-comment">header file comment</a> (and include guards if working on a
+header file), the <a class="reference internal" href="#minimal-list-of-includes">minimal list of #includes</a> required by the file should be
+listed.  We prefer these <tt class="docutils literal"><span class="pre">#include</span></tt>s to be listed in this order:</p>
+<ol class="arabic simple" id="local-private-headers">
+<span id="main-module-header"></span><li>Main Module Header</li>
+<li>Local/Private Headers</li>
+<li><tt class="docutils literal"><span class="pre">llvm/...</span></tt></li>
+<li>System <tt class="docutils literal"><span class="pre">#include</span></tt>s</li>
+</ol>
+<p>and each category should be sorted lexicographically by the full path.</p>
+<p>The <a class="reference internal" href="#main-module-header">Main Module Header</a> file applies to <tt class="docutils literal"><span class="pre">.cpp</span></tt> files which implement an
+interface defined by a <tt class="docutils literal"><span class="pre">.h</span></tt> file.  This <tt class="docutils literal"><span class="pre">#include</span></tt> should always be included
+<strong>first</strong> regardless of where it lives on the file system.  By including a
+header file first in the <tt class="docutils literal"><span class="pre">.cpp</span></tt> files that implement the interfaces, we ensure
+that the header does not have any hidden dependencies which are not explicitly
+<tt class="docutils literal"><span class="pre">#include</span></tt>d in the header, but should be. It is also a form of documentation
+in the <tt class="docutils literal"><span class="pre">.cpp</span></tt> file to indicate where the interfaces it implements are defined.</p>
+</div>
+<div class="section" id="source-code-width">
+<span id="fit-into-80-columns"></span><h4><a class="toc-backref" href="#id11">Source Code Width</a><a class="headerlink" href="#source-code-width" title="Permalink to this headline">¶</a></h4>
+<p>Write your code to fit within 80 columns of text.  This helps those of us who
+like to print out code and look at your code in an <tt class="docutils literal"><span class="pre">xterm</span></tt> without resizing
+it.</p>
+<p>The longer answer is that there must be some limit to the width of the code in
+order to reasonably allow developers to have multiple files side-by-side in
+windows on a modest display.  If you are going to pick a width limit, it is
+somewhat arbitrary but you might as well pick something standard.  Going with 90
+columns (for example) instead of 80 columns wouldn’t add any significant value
+and would be detrimental to printing out code.  Also many other projects have
+standardized on 80 columns, so some people have already configured their editors
+for it (vs something else, like 90 columns).</p>
+<p>This is one of many contentious issues in coding standards, but it is not up for
+debate.</p>
+</div>
+<div class="section" id="use-spaces-instead-of-tabs">
+<h4><a class="toc-backref" href="#id12">Use Spaces Instead of Tabs</a><a class="headerlink" href="#use-spaces-instead-of-tabs" title="Permalink to this headline">¶</a></h4>
+<p>In all cases, prefer spaces to tabs in source files.  People have different
+preferred indentation levels, and different styles of indentation that they
+like; this is fine.  What isn’t fine is that different editors/viewers expand
+tabs out to different tab stops.  This can cause your code to look completely
+unreadable, and it is not worth dealing with.</p>
+<p>As always, follow the <a class="reference internal" href="#golden-rule">Golden Rule</a> above: follow the style of
+existing code if you are modifying and extending it.  If you like four spaces of
+indentation, <strong>DO NOT</strong> do that in the middle of a chunk of code with two spaces
+of indentation.  Also, do not reindent a whole source file: it makes for
+incredible diffs that are absolutely worthless.</p>
+</div>
+<div class="section" id="indent-code-consistently">
+<h4><a class="toc-backref" href="#id13">Indent Code Consistently</a><a class="headerlink" href="#indent-code-consistently" title="Permalink to this headline">¶</a></h4>
+<p>Okay, in your first year of programming you were told that indentation is
+important.  If you didn’t believe and internalize this then, now is the time.
+Just do it.</p>
+</div>
+</div>
+<div class="section" id="compiler-issues">
+<h3><a class="toc-backref" href="#id14">Compiler Issues</a><a class="headerlink" href="#compiler-issues" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="treat-compiler-warnings-like-errors">
+<h4><a class="toc-backref" href="#id15">Treat Compiler Warnings Like Errors</a><a class="headerlink" href="#treat-compiler-warnings-like-errors" title="Permalink to this headline">¶</a></h4>
+<p>If your code has compiler warnings in it, something is wrong — you aren’t
+casting values correctly, you have “questionable” constructs in your code, or
+you are doing something legitimately wrong.  Compiler warnings can cover up
+legitimate errors in output and make dealing with a translation unit difficult.</p>
+<p>It is not possible to prevent all warnings from all compilers, nor is it
+desirable.  Instead, pick a standard compiler (like <tt class="docutils literal"><span class="pre">gcc</span></tt>) that provides a
+good thorough set of warnings, and stick to it.  At least in the case of
+<tt class="docutils literal"><span class="pre">gcc</span></tt>, it is possible to work around any spurious errors by changing the
+syntax of the code slightly.  For example, a warning that annoys me occurs when
+I write code like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">(</span><span class="n">V</span> <span class="o">=</span> <span class="n">getValue</span><span class="p">())</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">gcc</span></tt> will warn me that I probably want to use the <tt class="docutils literal"><span class="pre">==</span></tt> operator, and that I
+probably mistyped it.  In most cases, I haven’t, and I really don’t want the
+spurious errors.  To fix this particular problem, I rewrite the code like
+this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">((</span><span class="n">V</span> <span class="o">=</span> <span class="n">getValue</span><span class="p">()))</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>which shuts <tt class="docutils literal"><span class="pre">gcc</span></tt> up.  Any <tt class="docutils literal"><span class="pre">gcc</span></tt> warning that annoys you can be fixed by
+massaging the code appropriately.</p>
+</div>
+<div class="section" id="write-portable-code">
+<h4><a class="toc-backref" href="#id16">Write Portable Code</a><a class="headerlink" href="#write-portable-code" title="Permalink to this headline">¶</a></h4>
+<p>In almost all cases, it is possible and within reason to write completely
+portable code.  If there are cases where it isn’t possible to write portable
+code, isolate it behind a well defined (and well documented) interface.</p>
+<p>In practice, this means that you shouldn’t assume much about the host compiler
+(and Visual Studio tends to be the lowest common denominator).  If advanced
+features are used, they should only be an implementation detail of a library
+which has a simple exposed API, and preferably be buried in <tt class="docutils literal"><span class="pre">libSystem</span></tt>.</p>
+</div>
+<div class="section" id="do-not-use-rtti-or-exceptions">
+<h4><a class="toc-backref" href="#id17">Do not use RTTI or Exceptions</a><a class="headerlink" href="#do-not-use-rtti-or-exceptions" title="Permalink to this headline">¶</a></h4>
+<p>In an effort to reduce code and executable size, LLVM does not use RTTI
+(e.g. <tt class="docutils literal"><span class="pre">dynamic_cast<>;</span></tt>) or exceptions.  These two language features violate
+the general C++ principle of <em>“you only pay for what you use”</em>, causing
+executable bloat even if exceptions are never used in the code base, or if RTTI
+is never used for a class.  Because of this, we turn them off globally in the
+code.</p>
+<p>That said, LLVM does make extensive use of a hand-rolled form of RTTI that use
+templates like <a class="reference external" href="ProgrammersManual.html#isa">isa<>, cast<>, and dyn_cast<></a>.
+This form of RTTI is opt-in and can be
+<a class="reference internal" href="HowToSetUpLLVMStyleRTTI.html"><em>added to any class</em></a>. It is also
+substantially more efficient than <tt class="docutils literal"><span class="pre">dynamic_cast<></span></tt>.</p>
+</div>
+<div class="section" id="do-not-use-static-constructors">
+<span id="static-constructor"></span><h4><a class="toc-backref" href="#id18">Do not use Static Constructors</a><a class="headerlink" href="#do-not-use-static-constructors" title="Permalink to this headline">¶</a></h4>
+<p>Static constructors and destructors (e.g. global variables whose types have a
+constructor or destructor) should not be added to the code base, and should be
+removed wherever possible.  Besides <a class="reference external" href="http://yosefk.com/c++fqa/ctors.html#fqa-10.12">well known problems</a> where the order of
+initialization is undefined between globals in different source files, the
+entire concept of static constructors is at odds with the common use case of
+LLVM as a library linked into a larger application.</p>
+<p>Consider the use of LLVM as a JIT linked into another application (perhaps for
+<a class="reference external" href="http://llvm.org/Users.html">OpenGL, custom languages</a>, <a class="reference external" href="http://llvm.org/devmtg/2010-11/Gritz-OpenShadingLang.pdf">shaders in movies</a>, etc). Due to the
+design of static constructors, they must be executed at startup time of the
+entire application, regardless of whether or how LLVM is used in that larger
+application.  There are two problems with this:</p>
+<ul class="simple">
+<li>The time to run the static constructors impacts startup time of applications
+— a critical time for GUI apps, among others.</li>
+<li>The static constructors cause the app to pull many extra pages of memory off
+the disk: both the code for the constructor in each <tt class="docutils literal"><span class="pre">.o</span></tt> file and the small
+amount of data that gets touched. In addition, touched/dirty pages put more
+pressure on the VM system on low-memory machines.</li>
+</ul>
+<p>We would really like for there to be zero cost for linking in an additional LLVM
+target or other library into an application, but static constructors violate
+this goal.</p>
+<p>That said, LLVM unfortunately does contain static constructors.  It would be a
+<a class="reference external" href="http://llvm.org/PR11944">great project</a> for someone to purge all static
+constructors from LLVM, and then enable the <tt class="docutils literal"><span class="pre">-Wglobal-constructors</span></tt> warning
+flag (when building with Clang) to ensure we do not regress in the future.</p>
+</div>
+<div class="section" id="use-of-class-and-struct-keywords">
+<h4><a class="toc-backref" href="#id19">Use of <tt class="docutils literal"><span class="pre">class</span></tt> and <tt class="docutils literal"><span class="pre">struct</span></tt> Keywords</a><a class="headerlink" href="#use-of-class-and-struct-keywords" title="Permalink to this headline">¶</a></h4>
+<p>In C++, the <tt class="docutils literal"><span class="pre">class</span></tt> and <tt class="docutils literal"><span class="pre">struct</span></tt> keywords can be used almost
+interchangeably. The only difference is when they are used to declare a class:
+<tt class="docutils literal"><span class="pre">class</span></tt> makes all members private by default while <tt class="docutils literal"><span class="pre">struct</span></tt> makes all
+members public by default.</p>
+<p>Unfortunately, not all compilers follow the rules and some will generate
+different symbols based on whether <tt class="docutils literal"><span class="pre">class</span></tt> or <tt class="docutils literal"><span class="pre">struct</span></tt> was used to declare
+the symbol.  This can lead to problems at link time.</p>
+<p>So, the rule for LLVM is to always use the <tt class="docutils literal"><span class="pre">class</span></tt> keyword, unless <strong>all</strong>
+members are public and the type is a C++ <a class="reference external" href="http://en.wikipedia.org/wiki/Plain_old_data_structure">POD</a> type, in which case
+<tt class="docutils literal"><span class="pre">struct</span></tt> is allowed.</p>
+</div>
+</div>
+</div>
+<div class="section" id="style-issues">
+<h2><a class="toc-backref" href="#id20">Style Issues</a><a class="headerlink" href="#style-issues" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="the-high-level-issues">
+<h3><a class="toc-backref" href="#id21">The High-Level Issues</a><a class="headerlink" href="#the-high-level-issues" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="a-public-header-file-is-a-module">
+<h4><a class="toc-backref" href="#id22">A Public Header File <strong>is</strong> a Module</a><a class="headerlink" href="#a-public-header-file-is-a-module" title="Permalink to this headline">¶</a></h4>
+<p>C++ doesn’t do too well in the modularity department.  There is no real
+encapsulation or data hiding (unless you use expensive protocol classes), but it
+is what we have to work with.  When you write a public header file (in the LLVM
+source tree, they live in the top level “<tt class="docutils literal"><span class="pre">include</span></tt>” directory), you are
+defining a module of functionality.</p>
+<p>Ideally, modules should be completely independent of each other, and their
+header files should only <tt class="docutils literal"><span class="pre">#include</span></tt> the absolute minimum number of headers
+possible. A module is not just a class, a function, or a namespace: it’s a
+collection of these that defines an interface.  This interface may be several
+functions, classes, or data structures, but the important issue is how they work
+together.</p>
+<p>In general, a module should be implemented by one or more <tt class="docutils literal"><span class="pre">.cpp</span></tt> files.  Each
+of these <tt class="docutils literal"><span class="pre">.cpp</span></tt> files should include the header that defines their interface
+first.  This ensures that all of the dependences of the module header have been
+properly added to the module header itself, and are not implicit.  System
+headers should be included after user headers for a translation unit.</p>
+</div>
+<div class="section" id="include-as-little-as-possible">
+<span id="minimal-list-of-includes"></span><h4><a class="toc-backref" href="#id23"><tt class="docutils literal"><span class="pre">#include</span></tt> as Little as Possible</a><a class="headerlink" href="#include-as-little-as-possible" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">#include</span></tt> hurts compile time performance.  Don’t do it unless you have to,
+especially in header files.</p>
+<p>But wait! Sometimes you need to have the definition of a class to use it, or to
+inherit from it.  In these cases go ahead and <tt class="docutils literal"><span class="pre">#include</span></tt> that header file.  Be
+aware however that there are many cases where you don’t need to have the full
+definition of a class.  If you are using a pointer or reference to a class, you
+don’t need the header file.  If you are simply returning a class instance from a
+prototyped function or method, you don’t need it.  In fact, for most cases, you
+simply don’t need the definition of a class. And not <tt class="docutils literal"><span class="pre">#include</span></tt>ing speeds up
+compilation.</p>
+<p>It is easy to try to go too overboard on this recommendation, however.  You
+<strong>must</strong> include all of the header files that you are using — you can include
+them either directly or indirectly through another header file.  To make sure
+that you don’t accidentally forget to include a header file in your module
+header, make sure to include your module header <strong>first</strong> in the implementation
+file (as mentioned above).  This way there won’t be any hidden dependencies that
+you’ll find out about later.</p>
+</div>
+<div class="section" id="keep-internal-headers-private">
+<h4><a class="toc-backref" href="#id24">Keep “Internal” Headers Private</a><a class="headerlink" href="#keep-internal-headers-private" title="Permalink to this headline">¶</a></h4>
+<p>Many modules have a complex implementation that causes them to use more than one
+implementation (<tt class="docutils literal"><span class="pre">.cpp</span></tt>) file.  It is often tempting to put the internal
+communication interface (helper classes, extra functions, etc) in the public
+module header file.  Don’t do this!</p>
+<p>If you really need to do something like this, put a private header file in the
+same directory as the source files, and include it locally.  This ensures that
+your private interface remains private and undisturbed by outsiders.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">It’s okay to put extra implementation methods in a public class itself. Just
+make them private (or protected) and all is well.</p>
+</div>
+</div>
+<div class="section" id="use-early-exits-and-continue-to-simplify-code">
+<span id="early-exits"></span><h4><a class="toc-backref" href="#id25">Use Early Exits and <tt class="docutils literal"><span class="pre">continue</span></tt> to Simplify Code</a><a class="headerlink" href="#use-early-exits-and-continue-to-simplify-code" title="Permalink to this headline">¶</a></h4>
+<p>When reading code, keep in mind how much state and how many previous decisions
+have to be remembered by the reader to understand a block of code.  Aim to
+reduce indentation where possible when it doesn’t make it more difficult to
+understand the code.  One great way to do this is by making use of early exits
+and the <tt class="docutils literal"><span class="pre">continue</span></tt> keyword in long loops.  As an example of using an early
+exit from a function, consider this “bad” code:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">Value</span> <span class="o">*</span><span class="nf">doSomething</span><span class="p">(</span><span class="n">Instruction</span> <span class="o">*</span><span class="n">I</span><span class="p">)</span> <span class="p">{</span>
+  <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">isa</span><span class="o"><</span><span class="n">TerminatorInst</span><span class="o">></span><span class="p">(</span><span class="n">I</span><span class="p">)</span> <span class="o">&&</span>
+      <span class="n">I</span><span class="o">-></span><span class="n">hasOneUse</span><span class="p">()</span> <span class="o">&&</span> <span class="n">doOtherThing</span><span class="p">(</span><span class="n">I</span><span class="p">))</span> <span class="p">{</span>
+    <span class="p">...</span> <span class="n">some</span> <span class="kt">long</span> <span class="n">code</span> <span class="p">....</span>
+  <span class="p">}</span>
+
+  <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This code has several problems if the body of the <tt class="docutils literal"><span class="pre">'if'</span></tt> is large.  When
+you’re looking at the top of the function, it isn’t immediately clear that this
+<em>only</em> does interesting things with non-terminator instructions, and only
+applies to things with the other predicates.  Second, it is relatively difficult
+to describe (in comments) why these predicates are important because the <tt class="docutils literal"><span class="pre">if</span></tt>
+statement makes it difficult to lay out the comments.  Third, when you’re deep
+within the body of the code, it is indented an extra level.  Finally, when
+reading the top of the function, it isn’t clear what the result is if the
+predicate isn’t true; you have to read to the end of the function to know that
+it returns null.</p>
+<p>It is much preferred to format the code like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">Value</span> <span class="o">*</span><span class="nf">doSomething</span><span class="p">(</span><span class="n">Instruction</span> <span class="o">*</span><span class="n">I</span><span class="p">)</span> <span class="p">{</span>
+  <span class="c1">// Terminators never need 'something' done to them because ...</span>
+  <span class="k">if</span> <span class="p">(</span><span class="n">isa</span><span class="o"><</span><span class="n">TerminatorInst</span><span class="o">></span><span class="p">(</span><span class="n">I</span><span class="p">))</span>
+    <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+
+  <span class="c1">// We conservatively avoid transforming instructions with multiple uses</span>
+  <span class="c1">// because goats like cheese.</span>
+  <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">I</span><span class="o">-></span><span class="n">hasOneUse</span><span class="p">())</span>
+    <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+
+  <span class="c1">// This is really just here for example.</span>
+  <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">doOtherThing</span><span class="p">(</span><span class="n">I</span><span class="p">))</span>
+    <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+
+  <span class="p">...</span> <span class="n">some</span> <span class="kt">long</span> <span class="n">code</span> <span class="p">....</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This fixes these problems.  A similar problem frequently happens in <tt class="docutils literal"><span class="pre">for</span></tt>
+loops.  A silly example is something like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">for</span> <span class="p">(</span><span class="n">BasicBlock</span><span class="o">::</span><span class="n">iterator</span> <span class="n">II</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">begin</span><span class="p">(),</span> <span class="n">E</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">end</span><span class="p">();</span> <span class="n">II</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">II</span><span class="p">)</span> <span class="p">{</span>
+  <span class="k">if</span> <span class="p">(</span><span class="n">BinaryOperator</span> <span class="o">*</span><span class="n">BO</span> <span class="o">=</span> <span class="n">dyn_cast</span><span class="o"><</span><span class="n">BinaryOperator</span><span class="o">></span><span class="p">(</span><span class="n">II</span><span class="p">))</span> <span class="p">{</span>
+    <span class="n">Value</span> <span class="o">*</span><span class="n">LHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
+    <span class="n">Value</span> <span class="o">*</span><span class="n">RHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
+    <span class="k">if</span> <span class="p">(</span><span class="n">LHS</span> <span class="o">!=</span> <span class="n">RHS</span><span class="p">)</span> <span class="p">{</span>
+      <span class="p">...</span>
+    <span class="p">}</span>
+  <span class="p">}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>When you have very, very small loops, this sort of structure is fine. But if it
+exceeds more than 10-15 lines, it becomes difficult for people to read and
+understand at a glance. The problem with this sort of code is that it gets very
+nested very quickly. Meaning that the reader of the code has to keep a lot of
+context in their brain to remember what is going immediately on in the loop,
+because they don’t know if/when the <tt class="docutils literal"><span class="pre">if</span></tt> conditions will have <tt class="docutils literal"><span class="pre">else</span></tt>s etc.
+It is strongly preferred to structure the loop like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">for</span> <span class="p">(</span><span class="n">BasicBlock</span><span class="o">::</span><span class="n">iterator</span> <span class="n">II</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">begin</span><span class="p">(),</span> <span class="n">E</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">end</span><span class="p">();</span> <span class="n">II</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">II</span><span class="p">)</span> <span class="p">{</span>
+  <span class="n">BinaryOperator</span> <span class="o">*</span><span class="n">BO</span> <span class="o">=</span> <span class="n">dyn_cast</span><span class="o"><</span><span class="n">BinaryOperator</span><span class="o">></span><span class="p">(</span><span class="n">II</span><span class="p">);</span>
+  <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">BO</span><span class="p">)</span> <span class="k">continue</span><span class="p">;</span>
+
+  <span class="n">Value</span> <span class="o">*</span><span class="n">LHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
+  <span class="n">Value</span> <span class="o">*</span><span class="n">RHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
+  <span class="k">if</span> <span class="p">(</span><span class="n">LHS</span> <span class="o">==</span> <span class="n">RHS</span><span class="p">)</span> <span class="k">continue</span><span class="p">;</span>
+
+  <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This has all the benefits of using early exits for functions: it reduces nesting
+of the loop, it makes it easier to describe why the conditions are true, and it
+makes it obvious to the reader that there is no <tt class="docutils literal"><span class="pre">else</span></tt> coming up that they
+have to push context into their brain for.  If a loop is large, this can be a
+big understandability win.</p>
+</div>
+<div class="section" id="don-t-use-else-after-a-return">
+<h4><a class="toc-backref" href="#id26">Don’t use <tt class="docutils literal"><span class="pre">else</span></tt> after a <tt class="docutils literal"><span class="pre">return</span></tt></a><a class="headerlink" href="#don-t-use-else-after-a-return" title="Permalink to this headline">¶</a></h4>
+<p>For similar reasons above (reduction of indentation and easier reading), please
+do not use <tt class="docutils literal"><span class="pre">'else'</span></tt> or <tt class="docutils literal"><span class="pre">'else</span> <span class="pre">if'</span></tt> after something that interrupts control
+flow — like <tt class="docutils literal"><span class="pre">return</span></tt>, <tt class="docutils literal"><span class="pre">break</span></tt>, <tt class="docutils literal"><span class="pre">continue</span></tt>, <tt class="docutils literal"><span class="pre">goto</span></tt>, etc. For
+example, this is <em>bad</em>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">case</span> <span class="sc">'J'</span>: <span class="p">{</span>
+  <span class="k">if</span> <span class="p">(</span><span class="n">Signed</span><span class="p">)</span> <span class="p">{</span>
+    <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getsigjmp_bufType</span><span class="p">();</span>
+    <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+      <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_sigjmp_buf</span><span class="p">;</span>
+      <span class="k">return</span> <span class="nf">QualType</span><span class="p">();</span>
+    <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+      <span class="k">break</span><span class="p">;</span>
+    <span class="p">}</span>
+  <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+    <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getjmp_bufType</span><span class="p">();</span>
+    <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+      <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_jmp_buf</span><span class="p">;</span>
+      <span class="k">return</span> <span class="nf">QualType</span><span class="p">();</span>
+    <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+      <span class="k">break</span><span class="p">;</span>
+    <span class="p">}</span>
+  <span class="p">}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>It is better to write it like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">case</span> <span class="sc">'J'</span>:
+  <span class="k">if</span> <span class="p">(</span><span class="n">Signed</span><span class="p">)</span> <span class="p">{</span>
+    <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getsigjmp_bufType</span><span class="p">();</span>
+    <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+      <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_sigjmp_buf</span><span class="p">;</span>
+      <span class="k">return</span> <span class="nf">QualType</span><span class="p">();</span>
+    <span class="p">}</span>
+  <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+    <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getjmp_bufType</span><span class="p">();</span>
+    <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+      <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_jmp_buf</span><span class="p">;</span>
+      <span class="k">return</span> <span class="nf">QualType</span><span class="p">();</span>
+    <span class="p">}</span>
+  <span class="p">}</span>
+  <span class="k">break</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>Or better yet (in this case) as:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">case</span> <span class="sc">'J'</span>:
+  <span class="k">if</span> <span class="p">(</span><span class="n">Signed</span><span class="p">)</span>
+    <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getsigjmp_bufType</span><span class="p">();</span>
+  <span class="k">else</span>
+    <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getjmp_bufType</span><span class="p">();</span>
+
+  <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+    <span class="n">Error</span> <span class="o">=</span> <span class="n">Signed</span> <span class="o">?</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_sigjmp_buf</span> <span class="o">:</span>
+                     <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_jmp_buf</span><span class="p">;</span>
+    <span class="k">return</span> <span class="nf">QualType</span><span class="p">();</span>
+  <span class="p">}</span>
+  <span class="k">break</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The idea is to reduce indentation and the amount of code you have to keep track
+of when reading the code.</p>
+</div>
+<div class="section" id="turn-predicate-loops-into-predicate-functions">
+<h4><a class="toc-backref" href="#id27">Turn Predicate Loops into Predicate Functions</a><a class="headerlink" href="#turn-predicate-loops-into-predicate-functions" title="Permalink to this headline">¶</a></h4>
+<p>It is very common to write small loops that just compute a boolean value.  There
+are a number of ways that people commonly write these, but an example of this
+sort of thing is:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">bool</span> <span class="n">FoundFoo</span> <span class="o">=</span> <span class="nb">false</span><span class="p">;</span>
+<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">E</span> <span class="o">=</span> <span class="n">BarList</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+  <span class="k">if</span> <span class="p">(</span><span class="n">BarList</span><span class="p">[</span><span class="n">I</span><span class="p">]</span><span class="o">-></span><span class="n">isFoo</span><span class="p">())</span> <span class="p">{</span>
+    <span class="n">FoundFoo</span> <span class="o">=</span> <span class="nb">true</span><span class="p">;</span>
+    <span class="k">break</span><span class="p">;</span>
+  <span class="p">}</span>
+
+<span class="k">if</span> <span class="p">(</span><span class="n">FoundFoo</span><span class="p">)</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This sort of code is awkward to write, and is almost always a bad sign.  Instead
+of this sort of loop, we strongly prefer to use a predicate function (which may
+be <a class="reference internal" href="#static">static</a>) that uses <a class="reference internal" href="#early-exits">early exits</a> to compute the predicate.  We prefer the
+code to be structured like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">/// \returns true if the specified list has an element that is a foo.</span>
+<span class="k">static</span> <span class="kt">bool</span> <span class="nf">containsFoo</span><span class="p">(</span><span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">vector</span><span class="o"><</span><span class="n">Bar</span><span class="o">*></span> <span class="o">&</span><span class="n">List</span><span class="p">)</span> <span class="p">{</span>
+  <span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">E</span> <span class="o">=</span> <span class="n">List</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+    <span class="k">if</span> <span class="p">(</span><span class="n">List</span><span class="p">[</span><span class="n">I</span><span class="p">]</span><span class="o">-></span><span class="n">isFoo</span><span class="p">())</span>
+      <span class="k">return</span> <span class="nb">true</span><span class="p">;</span>
+  <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+<span class="p">}</span>
+<span class="p">...</span>
+
+<span class="k">if</span> <span class="p">(</span><span class="n">containsFoo</span><span class="p">(</span><span class="n">BarList</span><span class="p">))</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>There are many reasons for doing this: it reduces indentation and factors out
+code which can often be shared by other code that checks for the same predicate.
+More importantly, it <em>forces you to pick a name</em> for the function, and forces
+you to write a comment for it.  In this silly example, this doesn’t add much
+value.  However, if the condition is complex, this can make it a lot easier for
+the reader to understand the code that queries for this predicate.  Instead of
+being faced with the in-line details of how we check to see if the BarList
+contains a foo, we can trust the function name and continue reading with better
+locality.</p>
+</div>
+</div>
+<div class="section" id="the-low-level-issues">
+<h3><a class="toc-backref" href="#id28">The Low-Level Issues</a><a class="headerlink" href="#the-low-level-issues" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="name-types-functions-variables-and-enumerators-properly">
+<h4><a class="toc-backref" href="#id29">Name Types, Functions, Variables, and Enumerators Properly</a><a class="headerlink" href="#name-types-functions-variables-and-enumerators-properly" title="Permalink to this headline">¶</a></h4>
+<p>Poorly-chosen names can mislead the reader and cause bugs. We cannot stress
+enough how important it is to use <em>descriptive</em> names.  Pick names that match
+the semantics and role of the underlying entities, within reason.  Avoid
+abbreviations unless they are well known.  After picking a good name, make sure
+to use consistent capitalization for the name, as inconsistency requires clients
+to either memorize the APIs or to look it up to find the exact spelling.</p>
+<p>In general, names should be in camel case (e.g. <tt class="docutils literal"><span class="pre">TextFileReader</span></tt> and
+<tt class="docutils literal"><span class="pre">isLValue()</span></tt>).  Different kinds of declarations have different rules:</p>
+<ul>
+<li><p class="first"><strong>Type names</strong> (including classes, structs, enums, typedefs, etc) should be
+nouns and start with an upper-case letter (e.g. <tt class="docutils literal"><span class="pre">TextFileReader</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Variable names</strong> should be nouns (as they represent state).  The name should
+be camel case, and start with an upper case letter (e.g. <tt class="docutils literal"><span class="pre">Leader</span></tt> or
+<tt class="docutils literal"><span class="pre">Boats</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Function names</strong> should be verb phrases (as they represent actions), and
+command-like function should be imperative.  The name should be camel case,
+and start with a lower case letter (e.g. <tt class="docutils literal"><span class="pre">openFile()</span></tt> or <tt class="docutils literal"><span class="pre">isFoo()</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Enum declarations</strong> (e.g. <tt class="docutils literal"><span class="pre">enum</span> <span class="pre">Foo</span> <span class="pre">{...}</span></tt>) are types, so they should
+follow the naming conventions for types.  A common use for enums is as a
+discriminator for a union, or an indicator of a subclass.  When an enum is
+used for something like this, it should have a <tt class="docutils literal"><span class="pre">Kind</span></tt> suffix
+(e.g. <tt class="docutils literal"><span class="pre">ValueKind</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Enumerators</strong> (e.g. <tt class="docutils literal"><span class="pre">enum</span> <span class="pre">{</span> <span class="pre">Foo,</span> <span class="pre">Bar</span> <span class="pre">}</span></tt>) and <strong>public member variables</strong>
+should start with an upper-case letter, just like types.  Unless the
+enumerators are defined in their own small namespace or inside a class,
+enumerators should have a prefix corresponding to the enum declaration name.
+For example, <tt class="docutils literal"><span class="pre">enum</span> <span class="pre">ValueKind</span> <span class="pre">{</span> <span class="pre">...</span> <span class="pre">};</span></tt> may contain enumerators like
+<tt class="docutils literal"><span class="pre">VK_Argument</span></tt>, <tt class="docutils literal"><span class="pre">VK_BasicBlock</span></tt>, etc.  Enumerators that are just
+convenience constants are exempt from the requirement for a prefix.  For
+instance:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">enum</span> <span class="p">{</span>
+  <span class="n">MaxSize</span> <span class="o">=</span> <span class="mi">42</span><span class="p">,</span>
+  <span class="n">Density</span> <span class="o">=</span> <span class="mi">12</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</li>
+</ul>
+<p>As an exception, classes that mimic STL classes can have member names in STL’s
+style of lower-case words separated by underscores (e.g. <tt class="docutils literal"><span class="pre">begin()</span></tt>,
+<tt class="docutils literal"><span class="pre">push_back()</span></tt>, and <tt class="docutils literal"><span class="pre">empty()</span></tt>). Classes that provide multiple
+iterators should add a singular prefix to <tt class="docutils literal"><span class="pre">begin()</span></tt> and <tt class="docutils literal"><span class="pre">end()</span></tt>
+(e.g. <tt class="docutils literal"><span class="pre">global_begin()</span></tt> and <tt class="docutils literal"><span class="pre">use_begin()</span></tt>).</p>
+<p>Here are some examples of good and bad names:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">VehicleMaker</span> <span class="p">{</span>
+  <span class="p">...</span>
+  <span class="n">Factory</span><span class="o"><</span><span class="n">Tire</span><span class="o">></span> <span class="n">F</span><span class="p">;</span>            <span class="c1">// Bad -- abbreviation and non-descriptive.</span>
+  <span class="n">Factory</span><span class="o"><</span><span class="n">Tire</span><span class="o">></span> <span class="n">Factory</span><span class="p">;</span>      <span class="c1">// Better.</span>
+  <span class="n">Factory</span><span class="o"><</span><span class="n">Tire</span><span class="o">></span> <span class="n">TireFactory</span><span class="p">;</span>  <span class="c1">// Even better -- if VehicleMaker has more than one</span>
+                              <span class="c1">// kind of factories.</span>
+<span class="p">};</span>
+
+<span class="n">Vehicle</span> <span class="nf">MakeVehicle</span><span class="p">(</span><span class="n">VehicleType</span> <span class="n">Type</span><span class="p">)</span> <span class="p">{</span>
+  <span class="n">VehicleMaker</span> <span class="n">M</span><span class="p">;</span>                         <span class="c1">// Might be OK if having a short life-span.</span>
+  <span class="n">Tire</span> <span class="n">Tmp1</span> <span class="o">=</span> <span class="n">M</span><span class="p">.</span><span class="n">makeTire</span><span class="p">();</span>               <span class="c1">// Bad -- 'Tmp1' provides no information.</span>
+  <span class="n">Light</span> <span class="n">Headlight</span> <span class="o">=</span> <span class="n">M</span><span class="p">.</span><span class="n">makeLight</span><span class="p">(</span><span class="s">"head"</span><span class="p">);</span>  <span class="c1">// Good -- descriptive.</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="assert-liberally">
+<h4><a class="toc-backref" href="#id30">Assert Liberally</a><a class="headerlink" href="#assert-liberally" title="Permalink to this headline">¶</a></h4>
+<p>Use the “<tt class="docutils literal"><span class="pre">assert</span></tt>” macro to its fullest.  Check all of your preconditions and
+assumptions, you never know when a bug (not necessarily even yours) might be
+caught early by an assertion, which reduces debugging time dramatically.  The
+“<tt class="docutils literal"><span class="pre"><cassert></span></tt>” header file is probably already included by the header files you
+are using, so it doesn’t cost anything to use it.</p>
+<p>To further assist with debugging, make sure to put some kind of error message in
+the assertion statement, which is printed if the assertion is tripped. This
+helps the poor debugger make sense of why an assertion is being made and
+enforced, and hopefully what to do about it.  Here is one complete example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kr">inline</span> <span class="n">Value</span> <span class="o">*</span><span class="nf">getOperand</span><span class="p">(</span><span class="kt">unsigned</span> <span class="n">I</span><span class="p">)</span> <span class="p">{</span>
+  <span class="n">assert</span><span class="p">(</span><span class="n">I</span> <span class="o"><</span> <span class="n">Operands</span><span class="p">.</span><span class="n">size</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"getOperand() out of range!"</span><span class="p">);</span>
+  <span class="k">return</span> <span class="n">Operands</span><span class="p">[</span><span class="n">I</span><span class="p">];</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Here are more examples:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">assert</span><span class="p">(</span><span class="n">Ty</span><span class="o">-></span><span class="n">isPointerType</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"Can't allocate a non pointer type!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">((</span><span class="n">Opcode</span> <span class="o">==</span> <span class="n">Shl</span> <span class="o">||</span> <span class="n">Opcode</span> <span class="o">==</span> <span class="n">Shr</span><span class="p">)</span> <span class="o">&&</span> <span class="s">"ShiftInst Opcode invalid!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">(</span><span class="n">idx</span> <span class="o"><</span> <span class="n">getNumSuccessors</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"Successor # out of range!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">(</span><span class="n">V1</span><span class="p">.</span><span class="n">getType</span><span class="p">()</span> <span class="o">==</span> <span class="n">V2</span><span class="p">.</span><span class="n">getType</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"Constant types must be identical!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">(</span><span class="n">isa</span><span class="o"><</span><span class="n">PHINode</span><span class="o">></span><span class="p">(</span><span class="n">Succ</span><span class="o">-></span><span class="n">front</span><span class="p">())</span> <span class="o">&&</span> <span class="s">"Only works on PHId BBs!"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>You get the idea.</p>
+<p>In the past, asserts were used to indicate a piece of code that should not be
+reached.  These were typically of the form:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">assert</span><span class="p">(</span><span class="mi">0</span> <span class="o">&&</span> <span class="s">"Invalid radix for integer literal"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>This has a few issues, the main one being that some compilers might not
+understand the assertion, or warn about a missing return in builds where
+assertions are compiled out.</p>
+<p>Today, we have something much better: <tt class="docutils literal"><span class="pre">llvm_unreachable</span></tt>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">llvm_unreachable</span><span class="p">(</span><span class="s">"Invalid radix for integer literal"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>When assertions are enabled, this will print the message if it’s ever reached
+and then exit the program. When assertions are disabled (i.e. in release
+builds), <tt class="docutils literal"><span class="pre">llvm_unreachable</span></tt> becomes a hint to compilers to skip generating
+code for this branch. If the compiler does not support this, it will fall back
+to the “abort” implementation.</p>
+<p>Another issue is that values used only by assertions will produce an “unused
+value” warning when assertions are disabled.  For example, this code will warn:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">unsigned</span> <span class="n">Size</span> <span class="o">=</span> <span class="n">V</span><span class="p">.</span><span class="n">size</span><span class="p">();</span>
+<span class="n">assert</span><span class="p">(</span><span class="n">Size</span> <span class="o">></span> <span class="mi">42</span> <span class="o">&&</span> <span class="s">"Vector smaller than it should be"</span><span class="p">);</span>
+
+<span class="kt">bool</span> <span class="n">NewToSet</span> <span class="o">=</span> <span class="n">Myset</span><span class="p">.</span><span class="n">insert</span><span class="p">(</span><span class="n">Value</span><span class="p">);</span>
+<span class="n">assert</span><span class="p">(</span><span class="n">NewToSet</span> <span class="o">&&</span> <span class="s">"The value shouldn't be in the set yet"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>These are two interesting different cases. In the first case, the call to
+<tt class="docutils literal"><span class="pre">V.size()</span></tt> is only useful for the assert, and we don’t want it executed when
+assertions are disabled.  Code like this should move the call into the assert
+itself.  In the second case, the side effects of the call must happen whether
+the assert is enabled or not.  In this case, the value should be cast to void to
+disable the warning.  To be specific, it is preferred to write the code like
+this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">assert</span><span class="p">(</span><span class="n">V</span><span class="p">.</span><span class="n">size</span><span class="p">()</span> <span class="o">></span> <span class="mi">42</span> <span class="o">&&</span> <span class="s">"Vector smaller than it should be"</span><span class="p">);</span>
+
+<span class="kt">bool</span> <span class="n">NewToSet</span> <span class="o">=</span> <span class="n">Myset</span><span class="p">.</span><span class="n">insert</span><span class="p">(</span><span class="n">Value</span><span class="p">);</span> <span class="p">(</span><span class="kt">void</span><span class="p">)</span><span class="n">NewToSet</span><span class="p">;</span>
+<span class="n">assert</span><span class="p">(</span><span class="n">NewToSet</span> <span class="o">&&</span> <span class="s">"The value shouldn't be in the set yet"</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="do-not-use-using-namespace-std">
+<h4><a class="toc-backref" href="#id31">Do Not Use <tt class="docutils literal"><span class="pre">using</span> <span class="pre">namespace</span> <span class="pre">std</span></tt></a><a class="headerlink" href="#do-not-use-using-namespace-std" title="Permalink to this headline">¶</a></h4>
+<p>In LLVM, we prefer to explicitly prefix all identifiers from the standard
+namespace with an “<tt class="docutils literal"><span class="pre">std::</span></tt>” prefix, rather than rely on “<tt class="docutils literal"><span class="pre">using</span> <span class="pre">namespace</span>
+<span class="pre">std;</span></tt>”.</p>
+<p>In header files, adding a <tt class="docutils literal"><span class="pre">'using</span> <span class="pre">namespace</span> <span class="pre">XXX'</span></tt> directive pollutes the
+namespace of any source file that <tt class="docutils literal"><span class="pre">#include</span></tt>s the header.  This is clearly a
+bad thing.</p>
+<p>In implementation files (e.g. <tt class="docutils literal"><span class="pre">.cpp</span></tt> files), the rule is more of a stylistic
+rule, but is still important.  Basically, using explicit namespace prefixes
+makes the code <strong>clearer</strong>, because it is immediately obvious what facilities
+are being used and where they are coming from. And <strong>more portable</strong>, because
+namespace clashes cannot occur between LLVM code and other namespaces.  The
+portability rule is important because different standard library implementations
+expose different symbols (potentially ones they shouldn’t), and future revisions
+to the C++ standard will add more symbols to the <tt class="docutils literal"><span class="pre">std</span></tt> namespace.  As such, we
+never use <tt class="docutils literal"><span class="pre">'using</span> <span class="pre">namespace</span> <span class="pre">std;'</span></tt> in LLVM.</p>
+<p>The exception to the general rule (i.e. it’s not an exception for the <tt class="docutils literal"><span class="pre">std</span></tt>
+namespace) is for implementation files.  For example, all of the code in the
+LLVM project implements code that lives in the ‘llvm’ namespace.  As such, it is
+ok, and actually clearer, for the <tt class="docutils literal"><span class="pre">.cpp</span></tt> files to have a <tt class="docutils literal"><span class="pre">'using</span> <span class="pre">namespace</span>
+<span class="pre">llvm;'</span></tt> directive at the top, after the <tt class="docutils literal"><span class="pre">#include</span></tt>s.  This reduces
+indentation in the body of the file for source editors that indent based on
+braces, and keeps the conceptual context cleaner.  The general form of this rule
+is that any <tt class="docutils literal"><span class="pre">.cpp</span></tt> file that implements code in any namespace may use that
+namespace (and its parents’), but should not use any others.</p>
+</div>
+<div class="section" id="provide-a-virtual-method-anchor-for-classes-in-headers">
+<h4><a class="toc-backref" href="#id32">Provide a Virtual Method Anchor for Classes in Headers</a><a class="headerlink" href="#provide-a-virtual-method-anchor-for-classes-in-headers" title="Permalink to this headline">¶</a></h4>
+<p>If a class is defined in a header file and has a vtable (either it has virtual
+methods or it derives from classes with virtual methods), it must always have at
+least one out-of-line virtual method in the class.  Without this, the compiler
+will copy the vtable and RTTI into every <tt class="docutils literal"><span class="pre">.o</span></tt> file that <tt class="docutils literal"><span class="pre">#include</span></tt>s the
+header, bloating <tt class="docutils literal"><span class="pre">.o</span></tt> file sizes and increasing link times.</p>
+</div>
+<div class="section" id="don-t-use-default-labels-in-fully-covered-switches-over-enumerations">
+<h4><a class="toc-backref" href="#id33">Don’t use default labels in fully covered switches over enumerations</a><a class="headerlink" href="#don-t-use-default-labels-in-fully-covered-switches-over-enumerations" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">-Wswitch</span></tt> warns if a switch, without a default label, over an enumeration
+does not cover every enumeration value. If you write a default label on a fully
+covered switch over an enumeration then the <tt class="docutils literal"><span class="pre">-Wswitch</span></tt> warning won’t fire
+when new elements are added to that enumeration. To help avoid adding these
+kinds of defaults, Clang has the warning <tt class="docutils literal"><span class="pre">-Wcovered-switch-default</span></tt> which is
+off by default but turned on when building LLVM with a version of Clang that
+supports the warning.</p>
+<p>A knock-on effect of this stylistic requirement is that when building LLVM with
+GCC you may get warnings related to “control may reach end of non-void function”
+if you return from each case of a covered switch-over-enum because GCC assumes
+that the enum expression may take any representable value, not just those of
+individual enumerators. To suppress this warning, use <tt class="docutils literal"><span class="pre">llvm_unreachable</span></tt> after
+the switch.</p>
+</div>
+<div class="section" id="use-llvm-deleted-function-to-mark-uncallable-methods">
+<h4><a class="toc-backref" href="#id34">Use <tt class="docutils literal"><span class="pre">LLVM_DELETED_FUNCTION</span></tt> to mark uncallable methods</a><a class="headerlink" href="#use-llvm-deleted-function-to-mark-uncallable-methods" title="Permalink to this headline">¶</a></h4>
+<p>Prior to C++11, a common pattern to make a class uncopyable was to declare an
+unimplemented copy constructor and copy assignment operator and make them
+private. This would give a compiler error for accessing a private method or a
+linker error because it wasn’t implemented.</p>
+<p>With C++11, we can mark methods that won’t be implemented with <tt class="docutils literal"><span class="pre">=</span> <span class="pre">delete</span></tt>.
+This will trigger a much better error message and tell the compiler that the
+method will never be implemented. This enables other checks like
+<tt class="docutils literal"><span class="pre">-Wunused-private-field</span></tt> to run correctly on classes that contain these
+methods.</p>
+<p>To maintain compatibility with C++03, <tt class="docutils literal"><span class="pre">LLVM_DELETED_FUNCTION</span></tt> should be used
+which will expand to <tt class="docutils literal"><span class="pre">=</span> <span class="pre">delete</span></tt> if the compiler supports it. These methods
+should still be declared private. Example of the uncopyable pattern:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">DontCopy</span> <span class="p">{</span>
+<span class="nl">private:</span>
+  <span class="n">DontCopy</span><span class="p">(</span><span class="k">const</span> <span class="n">DontCopy</span><span class="o">&</span><span class="p">)</span> <span class="n">LLVM_DELETED_FUNCTION</span><span class="p">;</span>
+  <span class="n">DontCopy</span> <span class="o">&</span><span class="k">operator</span> <span class="o">=</span><span class="p">(</span><span class="k">const</span> <span class="n">DontCopy</span><span class="o">&</span><span class="p">)</span> <span class="n">LLVM_DELETED_FUNCTION</span><span class="p">;</span>
+<span class="nl">public:</span>
+  <span class="p">...</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="don-t-evaluate-end-every-time-through-a-loop">
+<h4><a class="toc-backref" href="#id35">Don’t evaluate <tt class="docutils literal"><span class="pre">end()</span></tt> every time through a loop</a><a class="headerlink" href="#don-t-evaluate-end-every-time-through-a-loop" title="Permalink to this headline">¶</a></h4>
+<p>Because C++ doesn’t have a standard “<tt class="docutils literal"><span class="pre">foreach</span></tt>” loop (though it can be
+emulated with macros and may be coming in C++‘0x) we end up writing a lot of
+loops that manually iterate from begin to end on a variety of containers or
+through other data structures.  One common mistake is to write a loop in this
+style:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">BasicBlock</span> <span class="o">*</span><span class="n">BB</span> <span class="o">=</span> <span class="p">...</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">BasicBlock</span><span class="o">::</span><span class="n">iterator</span> <span class="n">I</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">begin</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">BB</span><span class="o">-></span><span class="n">end</span><span class="p">();</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+  <span class="p">...</span> <span class="n">use</span> <span class="n">I</span> <span class="p">...</span>
+</pre></div>
+</div>
+<p>The problem with this construct is that it evaluates “<tt class="docutils literal"><span class="pre">BB->end()</span></tt>” every time
+through the loop.  Instead of writing the loop like this, we strongly prefer
+loops to be written so that they evaluate it once before the loop starts.  A
+convenient way to do this is like so:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">BasicBlock</span> <span class="o">*</span><span class="n">BB</span> <span class="o">=</span> <span class="p">...</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">BasicBlock</span><span class="o">::</span><span class="n">iterator</span> <span class="n">I</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">begin</span><span class="p">(),</span> <span class="n">E</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">end</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+  <span class="p">...</span> <span class="n">use</span> <span class="n">I</span> <span class="p">...</span>
+</pre></div>
+</div>
+<p>The observant may quickly point out that these two loops may have different
+semantics: if the container (a basic block in this case) is being mutated, then
+“<tt class="docutils literal"><span class="pre">BB->end()</span></tt>” may change its value every time through the loop and the second
+loop may not in fact be correct.  If you actually do depend on this behavior,
+please write the loop in the first form and add a comment indicating that you
+did it intentionally.</p>
+<p>Why do we prefer the second form (when correct)?  Writing the loop in the first
+form has two problems. First it may be less efficient than evaluating it at the
+start of the loop.  In this case, the cost is probably minor — a few extra
+loads every time through the loop.  However, if the base expression is more
+complex, then the cost can rise quickly.  I’ve seen loops where the end
+expression was actually something like: “<tt class="docutils literal"><span class="pre">SomeMap[X]->end()</span></tt>” and map lookups
+really aren’t cheap.  By writing it in the second form consistently, you
+eliminate the issue entirely and don’t even have to think about it.</p>
+<p>The second (even bigger) issue is that writing the loop in the first form hints
+to the reader that the loop is mutating the container (a fact that a comment
+would handily confirm!).  If you write the loop in the second form, it is
+immediately obvious without even looking at the body of the loop that the
+container isn’t being modified, which makes it easier to read the code and
+understand what it does.</p>
+<p>While the second form of the loop is a few extra keystrokes, we do strongly
+prefer it.</p>
+</div>
+<div class="section" id="include-iostream-is-forbidden">
+<h4><a class="toc-backref" href="#id36"><tt class="docutils literal"><span class="pre">#include</span> <span class="pre"><iostream></span></tt> is Forbidden</a><a class="headerlink" href="#include-iostream-is-forbidden" title="Permalink to this headline">¶</a></h4>
+<p>The use of <tt class="docutils literal"><span class="pre">#include</span> <span class="pre"><iostream></span></tt> in library files is hereby <strong>forbidden</strong>,
+because many common implementations transparently inject a <a class="reference internal" href="#static-constructor">static constructor</a>
+into every translation unit that includes it.</p>
+<p>Note that using the other stream headers (<tt class="docutils literal"><span class="pre"><sstream></span></tt> for example) is not
+problematic in this regard — just <tt class="docutils literal"><span class="pre"><iostream></span></tt>. However, <tt class="docutils literal"><span class="pre">raw_ostream</span></tt>
+provides various APIs that are better performing for almost every use than
+<tt class="docutils literal"><span class="pre">std::ostream</span></tt> style APIs.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">New code should always use <a class="reference internal" href="#raw-ostream">raw_ostream</a> for writing, or the
+<tt class="docutils literal"><span class="pre">llvm::MemoryBuffer</span></tt> API for reading files.</p>
+</div>
+</div>
+<div class="section" id="use-raw-ostream">
+<span id="raw-ostream"></span><h4><a class="toc-backref" href="#id37">Use <tt class="docutils literal"><span class="pre">raw_ostream</span></tt></a><a class="headerlink" href="#use-raw-ostream" title="Permalink to this headline">¶</a></h4>
+<p>LLVM includes a lightweight, simple, and efficient stream implementation in
+<tt class="docutils literal"><span class="pre">llvm/Support/raw_ostream.h</span></tt>, which provides all of the common features of
+<tt class="docutils literal"><span class="pre">std::ostream</span></tt>.  All new code should use <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> instead of
+<tt class="docutils literal"><span class="pre">ostream</span></tt>.</p>
+<p>Unlike <tt class="docutils literal"><span class="pre">std::ostream</span></tt>, <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> is not a template and can be forward
+declared as <tt class="docutils literal"><span class="pre">class</span> <span class="pre">raw_ostream</span></tt>.  Public headers should generally not include
+the <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> header, but use forward declarations and constant references
+to <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> instances.</p>
+</div>
+<div class="section" id="avoid-std-endl">
+<h4><a class="toc-backref" href="#id38">Avoid <tt class="docutils literal"><span class="pre">std::endl</span></tt></a><a class="headerlink" href="#avoid-std-endl" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">std::endl</span></tt> modifier, when used with <tt class="docutils literal"><span class="pre">iostreams</span></tt> outputs a newline to
+the output stream specified.  In addition to doing this, however, it also
+flushes the output stream.  In other words, these are equivalent:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">std</span><span class="o">::</span><span class="n">cout</span> <span class="o"><<</span> <span class="n">std</span><span class="o">::</span><span class="n">endl</span><span class="p">;</span>
+<span class="n">std</span><span class="o">::</span><span class="n">cout</span> <span class="o"><<</span> <span class="sc">'\n'</span> <span class="o"><<</span> <span class="n">std</span><span class="o">::</span><span class="n">flush</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>Most of the time, you probably have no reason to flush the output stream, so
+it’s better to use a literal <tt class="docutils literal"><span class="pre">'\n'</span></tt>.</p>
+</div>
+<div class="section" id="don-t-use-inline-when-defining-a-function-in-a-class-definition">
+<h4><a class="toc-backref" href="#id39">Don’t use <tt class="docutils literal"><span class="pre">inline</span></tt> when defining a function in a class definition</a><a class="headerlink" href="#don-t-use-inline-when-defining-a-function-in-a-class-definition" title="Permalink to this headline">¶</a></h4>
+<p>A member function defined in a class definition is implicitly inline, so don’t
+put the <tt class="docutils literal"><span class="pre">inline</span></tt> keyword in this case.</p>
+<p>Don’t:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span> <span class="p">{</span>
+<span class="nl">public:</span>
+  <span class="kr">inline</span> <span class="kt">void</span> <span class="n">bar</span><span class="p">()</span> <span class="p">{</span>
+    <span class="c1">// ...</span>
+  <span class="p">}</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>Do:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span> <span class="p">{</span>
+<span class="nl">public:</span>
+  <span class="kt">void</span> <span class="n">bar</span><span class="p">()</span> <span class="p">{</span>
+    <span class="c1">// ...</span>
+  <span class="p">}</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="microscopic-details">
+<h3><a class="toc-backref" href="#id40">Microscopic Details</a><a class="headerlink" href="#microscopic-details" title="Permalink to this headline">¶</a></h3>
+<p>This section describes preferred low-level formatting guidelines along with
+reasoning on why we prefer them.</p>
+<div class="section" id="spaces-before-parentheses">
+<h4><a class="toc-backref" href="#id41">Spaces Before Parentheses</a><a class="headerlink" href="#spaces-before-parentheses" title="Permalink to this headline">¶</a></h4>
+<p>We prefer to put a space before an open parenthesis only in control flow
+statements, but not in normal function call expressions and function-like
+macros.  For example, this is good:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">(</span><span class="n">X</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">I</span> <span class="o">!=</span> <span class="mi">100</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">while</span> <span class="p">(</span><span class="n">LLVMRocks</span><span class="p">)</span> <span class="p">...</span>
+
+<span class="n">somefunc</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+<span class="n">assert</span><span class="p">(</span><span class="mi">3</span> <span class="o">!=</span> <span class="mi">4</span> <span class="o">&&</span> <span class="s">"laws of math are failing me"</span><span class="p">);</span>
+
+<span class="n">A</span> <span class="o">=</span> <span class="n">foo</span><span class="p">(</span><span class="mi">42</span><span class="p">,</span> <span class="mi">92</span><span class="p">)</span> <span class="o">+</span> <span class="n">bar</span><span class="p">(</span><span class="n">X</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>and this is bad:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span><span class="p">(</span><span class="n">X</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">for</span><span class="p">(</span><span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">I</span> <span class="o">!=</span> <span class="mi">100</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">while</span><span class="p">(</span><span class="n">LLVMRocks</span><span class="p">)</span> <span class="p">...</span>
+
+<span class="n">somefunc</span> <span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+<span class="n">assert</span> <span class="p">(</span><span class="mi">3</span> <span class="o">!=</span> <span class="mi">4</span> <span class="o">&&</span> <span class="s">"laws of math are failing me"</span><span class="p">);</span>
+
+<span class="n">A</span> <span class="o">=</span> <span class="n">foo</span> <span class="p">(</span><span class="mi">42</span><span class="p">,</span> <span class="mi">92</span><span class="p">)</span> <span class="o">+</span> <span class="n">bar</span> <span class="p">(</span><span class="n">X</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The reason for doing this is not completely arbitrary.  This style makes control
+flow operators stand out more, and makes expressions flow better. The function
+call operator binds very tightly as a postfix operator.  Putting a space after a
+function name (as in the last example) makes it appear that the code might bind
+the arguments of the left-hand-side of a binary operator with the argument list
+of a function and the name of the right side.  More specifically, it is easy to
+misread the “<tt class="docutils literal"><span class="pre">A</span></tt>” example as:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">A</span> <span class="o">=</span> <span class="n">foo</span> <span class="p">((</span><span class="mi">42</span><span class="p">,</span> <span class="mi">92</span><span class="p">)</span> <span class="o">+</span> <span class="n">bar</span><span class="p">)</span> <span class="p">(</span><span class="n">X</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>when skimming through the code.  By avoiding a space in a function, we avoid
+this misinterpretation.</p>
+</div>
+<div class="section" id="prefer-preincrement">
+<h4><a class="toc-backref" href="#id42">Prefer Preincrement</a><a class="headerlink" href="#prefer-preincrement" title="Permalink to this headline">¶</a></h4>
+<p>Hard fast rule: Preincrement (<tt class="docutils literal"><span class="pre">++X</span></tt>) may be no slower than postincrement
+(<tt class="docutils literal"><span class="pre">X++</span></tt>) and could very well be a lot faster than it.  Use preincrementation
+whenever possible.</p>
+<p>The semantics of postincrement include making a copy of the value being
+incremented, returning it, and then preincrementing the “work value”.  For
+primitive types, this isn’t a big deal. But for iterators, it can be a huge
+issue (for example, some iterators contains stack and set objects in them...
+copying an iterator could invoke the copy ctor’s of these as well).  In general,
+get in the habit of always using preincrement, and you won’t have a problem.</p>
+</div>
+<div class="section" id="namespace-indentation">
+<h4><a class="toc-backref" href="#id43">Namespace Indentation</a><a class="headerlink" href="#namespace-indentation" title="Permalink to this headline">¶</a></h4>
+<p>In general, we strive to reduce indentation wherever possible.  This is useful
+because we want code to <a class="reference internal" href="#fit-into-80-columns">fit into 80 columns</a> without wrapping horribly, but
+also because it makes it easier to understand the code.  Namespaces are a funny
+thing: they are often large, and we often desire to put lots of stuff into them
+(so they can be large).  Other times they are tiny, because they just hold an
+enum or something similar.  In order to balance this, we use different
+approaches for small versus large namespaces.</p>
+<p>If a namespace definition is small and <em>easily</em> fits on a screen (say, less than
+35 lines of code), then you should indent its body.  Here’s an example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="n">llvm</span> <span class="p">{</span>
+  <span class="k">namespace</span> <span class="n">X86</span> <span class="p">{</span>
+    <span class="c1">/// \brief An enum for the x86 relocation codes.  Note that</span>
+    <span class="c1">/// the terminology here doesn't follow x86 convention - word means</span>
+    <span class="c1">/// 32-bit and dword means 64-bit.</span>
+    <span class="k">enum</span> <span class="n">RelocationType</span> <span class="p">{</span>
+      <span class="c1">/// \brief PC relative relocation, add the relocated value to</span>
+      <span class="c1">/// the value already in memory, after we adjust it for where the PC is.</span>
+      <span class="n">reloc_pcrel_word</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span>
+
+      <span class="c1">/// \brief PIC base relative relocation, add the relocated value to</span>
+      <span class="c1">/// the value already in memory, after we adjust it for where the</span>
+      <span class="c1">/// PIC base is.</span>
+      <span class="n">reloc_picrel_word</span> <span class="o">=</span> <span class="mi">1</span><span class="p">,</span>
+
+      <span class="c1">/// \brief Absolute relocation, just add the relocated value to the</span>
+      <span class="c1">/// value already in memory.</span>
+      <span class="n">reloc_absolute_word</span> <span class="o">=</span> <span class="mi">2</span><span class="p">,</span>
+      <span class="n">reloc_absolute_dword</span> <span class="o">=</span> <span class="mi">3</span>
+    <span class="p">};</span>
+  <span class="p">}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Since the body is small, indenting adds value because it makes it very clear
+where the namespace starts and ends, and it is easy to take the whole thing in
+in one “gulp” when reading the code.  If the blob of code in the namespace is
+larger (as it typically is in a header in the <tt class="docutils literal"><span class="pre">llvm</span></tt> or <tt class="docutils literal"><span class="pre">clang</span></tt> namespaces),
+do not indent the code, and add a comment indicating what namespace is being
+closed.  For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="n">llvm</span> <span class="p">{</span>
+<span class="k">namespace</span> <span class="n">knowledge</span> <span class="p">{</span>
+
+<span class="c1">/// This class represents things that Smith can have an intimate</span>
+<span class="c1">/// understanding of and contains the data associated with it.</span>
+<span class="k">class</span> <span class="nc">Grokable</span> <span class="p">{</span>
+<span class="p">...</span>
+<span class="nl">public:</span>
+  <span class="k">explicit</span> <span class="n">Grokable</span><span class="p">()</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
+  <span class="k">virtual</span> <span class="o">~</span><span class="n">Grokable</span><span class="p">()</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+
+  <span class="p">...</span>
+
+<span class="p">};</span>
+
+<span class="p">}</span> <span class="c1">// end namespace knowledge</span>
+<span class="p">}</span> <span class="c1">// end namespace llvm</span>
+</pre></div>
+</div>
+<p>Because the class is large, we don’t expect that the reader can easily
+understand the entire concept in a glance, and the end of the file (where the
+namespaces end) may be a long ways away from the place they open.  As such,
+indenting the contents of the namespace doesn’t add any value, and detracts from
+the readability of the class.  In these cases it is best to <em>not</em> indent the
+contents of the namespace.</p>
+</div>
+<div class="section" id="anonymous-namespaces">
+<span id="static"></span><h4><a class="toc-backref" href="#id44">Anonymous Namespaces</a><a class="headerlink" href="#anonymous-namespaces" title="Permalink to this headline">¶</a></h4>
+<p>After talking about namespaces in general, you may be wondering about anonymous
+namespaces in particular.  Anonymous namespaces are a great language feature
+that tells the C++ compiler that the contents of the namespace are only visible
+within the current translation unit, allowing more aggressive optimization and
+eliminating the possibility of symbol name collisions.  Anonymous namespaces are
+to C++ as “static” is to C functions and global variables.  While “<tt class="docutils literal"><span class="pre">static</span></tt>”
+is available in C++, anonymous namespaces are more general: they can make entire
+classes private to a file.</p>
+<p>The problem with anonymous namespaces is that they naturally want to encourage
+indentation of their body, and they reduce locality of reference: if you see a
+random function definition in a C++ file, it is easy to see if it is marked
+static, but seeing if it is in an anonymous namespace requires scanning a big
+chunk of the file.</p>
+<p>Because of this, we have a simple guideline: make anonymous namespaces as small
+as possible, and only use them for class declarations.  For example, this is
+good:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="p">{</span>
+  <span class="k">class</span> <span class="nc">StringSort</span> <span class="p">{</span>
+  <span class="p">...</span>
+  <span class="nl">public:</span>
+    <span class="n">StringSort</span><span class="p">(...)</span>
+    <span class="kt">bool</span> <span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span><span class="p">;</span>
+  <span class="p">};</span>
+<span class="p">}</span> <span class="c1">// end anonymous namespace</span>
+
+<span class="k">static</span> <span class="kt">void</span> <span class="n">runHelper</span><span class="p">()</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+
+<span class="kt">bool</span> <span class="n">StringSort</span><span class="o">::</span><span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This is bad:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="p">{</span>
+<span class="k">class</span> <span class="nc">StringSort</span> <span class="p">{</span>
+<span class="p">...</span>
+<span class="nl">public:</span>
+  <span class="n">StringSort</span><span class="p">(...)</span>
+  <span class="kt">bool</span> <span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span><span class="p">;</span>
+<span class="p">};</span>
+
+<span class="kt">void</span> <span class="nf">runHelper</span><span class="p">()</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+
+<span class="kt">bool</span> <span class="n">StringSort</span><span class="o">::</span><span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
+  <span class="p">...</span>
+<span class="p">}</span>
+
+<span class="p">}</span> <span class="c1">// end anonymous namespace</span>
+</pre></div>
+</div>
+<p>This is bad specifically because if you’re looking at “<tt class="docutils literal"><span class="pre">runHelper</span></tt>” in the middle
+of a large C++ file, that you have no immediate way to tell if it is local to
+the file.  When it is marked static explicitly, this is immediately obvious.
+Also, there is no reason to enclose the definition of “<tt class="docutils literal"><span class="pre">operator<</span></tt>” in the
+namespace just because it was declared there.</p>
+</div>
+</div>
+</div>
+<div class="section" id="see-also">
+<h2><a class="toc-backref" href="#id45">See Also</a><a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>A lot of these comments and recommendations have been culled from other sources.
+Two particularly important books for our work are:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876">Effective C++</a>
+by Scott Meyers.  Also interesting and useful are “More Effective C++” and
+“Effective STL” by the same author.</li>
+<li><a class="reference external" href="http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620/ref=sr_1_1">Large-Scale C++ Software Design</a>
+by John Lakos</li>
+</ol>
+<p>If you get some free time, and you haven’t read them: do so, you might learn
+something.</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="CommandLine.html" title="CommandLine 2.0 Library Manual"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="Atomics.html" title="LLVM Atomic Instructions and Concurrency Guide"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/FileCheck.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/FileCheck.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/FileCheck.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/FileCheck.html Wed May  7 15:09:32 2014
@@ -0,0 +1,463 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>FileCheck - Flexible pattern matching file verifier — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="tblgen - Target Description To C++ Code Generator" href="tblgen.html" />
+    <link rel="prev" title="llvm-bcanalyzer - LLVM bitcode analyzer" href="llvm-bcanalyzer.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="llvm-bcanalyzer.html" title="llvm-bcanalyzer - LLVM bitcode analyzer"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="filecheck-flexible-pattern-matching-file-verifier">
+<h1>FileCheck - Flexible pattern matching file verifier<a class="headerlink" href="#filecheck-flexible-pattern-matching-file-verifier" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">FileCheck</strong> <em>match-filename</em> [<em>–check-prefix=XXX</em>] [<em>–strict-whitespace</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">FileCheck</strong> reads two files (one from standard input, and one
+specified on the command line) and uses one to verify the other.  This
+behavior is particularly useful for the testsuite, which wants to verify that
+the output of some tool (e.g. <strong class="program">llc</strong>) contains the expected information
+(for example, a movsd from esp or whatever is interesting).  This is similar to
+using <strong class="program">grep</strong>, but it is optimized for matching multiple different
+inputs in one file in a specific order.</p>
+<p>The <tt class="docutils literal"><span class="pre">match-filename</span></tt> file specifies the file that contains the patterns to
+match.  The file to verify is read from standard input unless the
+<a class="reference internal" href="#cmdoption--input-file"><em class="xref std std-option">--input-file</em></a> option is used.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--check-prefix">
+<tt class="descname">--check-prefix</tt><tt class="descclassname"> prefix</tt><a class="headerlink" href="#cmdoption--check-prefix" title="Permalink to this definition">¶</a></dt>
+<dd><p>FileCheck searches the contents of <tt class="docutils literal"><span class="pre">match-filename</span></tt> for patterns to
+match.  By default, these patterns are prefixed with “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>”.
+If you’d like to use a different prefix (e.g. because the same input
+file is checking multiple different tool or options), the
+<a class="reference internal" href="#cmdoption--check-prefix"><em class="xref std std-option">--check-prefix</em></a> argument allows you to specify one or more
+prefixes to match. Multiple prefixes are useful for tests which might
+change for different run options, but most lines remain the same.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--input-file">
+<tt class="descname">--input-file</tt><tt class="descclassname"> filename</tt><a class="headerlink" href="#cmdoption--input-file" title="Permalink to this definition">¶</a></dt>
+<dd><p>File to check (defaults to stdin).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--strict-whitespace">
+<tt class="descname">--strict-whitespace</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--strict-whitespace" title="Permalink to this definition">¶</a></dt>
+<dd><p>By default, FileCheck canonicalizes input horizontal whitespace (spaces and
+tabs) which causes it to ignore these differences (a space will match a tab).
+The <a class="reference internal" href="#cmdoption--strict-whitespace"><em class="xref std std-option">--strict-whitespace</em></a> argument disables this behavior. End-of-line
+sequences are canonicalized to UNIX-style <tt class="docutils literal"><span class="pre">\n</span></tt> in all modes.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-version">
+<tt class="descname">-version</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-version" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the version number of this program.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">FileCheck</strong> verifies that the file matches the expected contents,
+it exits with 0.  Otherwise, if not, or if an error occurs, it will exit with a
+non-zero value.</p>
+</div>
+<div class="section" id="tutorial">
+<h2>TUTORIAL<a class="headerlink" href="#tutorial" title="Permalink to this headline">¶</a></h2>
+<p>FileCheck is typically used from LLVM regression tests, being invoked on the RUN
+line of the test.  A simple example of using FileCheck from a RUN line looks
+like this:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s</span>
+</pre></div>
+</div>
+<p>This syntax says to pipe the current file (“<tt class="docutils literal"><span class="pre">%s</span></tt>”) into <tt class="docutils literal"><span class="pre">llvm-as</span></tt>, pipe
+that into <tt class="docutils literal"><span class="pre">llc</span></tt>, then pipe the output of <tt class="docutils literal"><span class="pre">llc</span></tt> into <tt class="docutils literal"><span class="pre">FileCheck</span></tt>.  This
+means that FileCheck will be verifying its standard input (the llc output)
+against the filename argument specified (the original <tt class="docutils literal"><span class="pre">.ll</span></tt> file specified by
+“<tt class="docutils literal"><span class="pre">%s</span></tt>”).  To see how this works, let’s look at the rest of the <tt class="docutils literal"><span class="pre">.ll</span></tt> file
+(after the RUN line):</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="kt">void</span> <span class="vg">@sub1</span><span class="p">(</span><span class="k">i32</span><span class="p">*</span> <span class="nv">%p</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%v</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK: sub1:</span>
+<span class="c">; CHECK: subl</span>
+        <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">i32</span> <span class="vg">@llvm.atomic.load.sub.i32.p0i32</span><span class="p">(</span><span class="k">i32</span><span class="p">*</span> <span class="nv">%p</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%v</span><span class="p">)</span>
+        <span class="k">ret</span> <span class="kt">void</span>
+<span class="p">}</span>
+
+<span class="k">define</span> <span class="kt">void</span> <span class="vg">@inc4</span><span class="p">(</span><span class="k">i64</span><span class="p">*</span> <span class="nv">%p</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK: inc4:</span>
+<span class="c">; CHECK: incq</span>
+        <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">i64</span> <span class="vg">@llvm.atomic.load.add.i64.p0i64</span><span class="p">(</span><span class="k">i64</span><span class="p">*</span> <span class="nv">%p</span><span class="p">,</span> <span class="k">i64</span> <span class="m">1</span><span class="p">)</span>
+        <span class="k">ret</span> <span class="kt">void</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Here you can see some “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines specified in comments.  Now you can
+see how the file is piped into <tt class="docutils literal"><span class="pre">llvm-as</span></tt>, then <tt class="docutils literal"><span class="pre">llc</span></tt>, and the machine code
+output is what we are verifying.  FileCheck checks the machine code output to
+verify that it matches what the “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines specify.</p>
+<p>The syntax of the “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines is very simple: they are fixed strings that
+must occur in order.  FileCheck defaults to ignoring horizontal whitespace
+differences (e.g. a space is allowed to match a tab) but otherwise, the contents
+of the “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” line is required to match some thing in the test file exactly.</p>
+<p>One nice thing about FileCheck (compared to grep) is that it allows merging
+test cases together into logical groups.  For example, because the test above
+is checking for the “<tt class="docutils literal"><span class="pre">sub1:</span></tt>” and “<tt class="docutils literal"><span class="pre">inc4:</span></tt>” labels, it will not match
+unless there is a “<tt class="docutils literal"><span class="pre">subl</span></tt>” in between those labels.  If it existed somewhere
+else in the file, that would not count: “<tt class="docutils literal"><span class="pre">grep</span> <span class="pre">subl</span></tt>” matches if “<tt class="docutils literal"><span class="pre">subl</span></tt>”
+exists anywhere in the file.</p>
+<div class="section" id="the-filecheck-check-prefix-option">
+<h3>The FileCheck -check-prefix option<a class="headerlink" href="#the-filecheck-check-prefix-option" title="Permalink to this headline">¶</a></h3>
+<p>The FileCheck <em class="xref std std-option">-check-prefix</em> option allows multiple test
+configurations to be driven from one <cite>.ll</cite> file.  This is useful in many
+circumstances, for example, testing different architectural variants with
+<strong class="program">llc</strong>.  Here’s a simple example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \</span>
+<span class="c">; RUN:              | FileCheck %s -check-prefix=X32</span>
+<span class="c">; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \</span>
+<span class="c">; RUN:              | FileCheck %s -check-prefix=X64</span>
+
+<span class="k">define</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="vg">@pinsrd_1</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%s</span><span class="p">,</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="nv">%tmp</span><span class="p">)</span> <span class="k">nounwind</span> <span class="p">{</span>
+        <span class="nv">%tmp1</span> <span class="p">=</span> <span class="k">insertelement</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span><span class="c">; %tmp, i32 %s, i32 1</span>
+        <span class="k">ret</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="nv">%tmp1</span>
+<span class="c">; X32: pinsrd_1:</span>
+<span class="c">; X32:    pinsrd $1, 4(%esp), %xmm0</span>
+
+<span class="c">; X64: pinsrd_1:</span>
+<span class="c">; X64:    pinsrd $1, %edi, %xmm0</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In this case, we’re testing that we get the expected code generation with
+both 32-bit and 64-bit code generation.</p>
+</div>
+<div class="section" id="the-check-next-directive">
+<h3>The “CHECK-NEXT:” directive<a class="headerlink" href="#the-check-next-directive" title="Permalink to this headline">¶</a></h3>
+<p>Sometimes you want to match lines and would like to verify that matches
+happen on exactly consecutive lines with no other lines in between them.  In
+this case, you can use “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” and “<tt class="docutils literal"><span class="pre">CHECK-NEXT:</span></tt>” directives to specify
+this.  If you specified a custom check prefix, just use “<tt class="docutils literal"><span class="pre"><PREFIX>-NEXT:</span></tt>”.
+For example, something like this works as you’d expect:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="kt">void</span> <span class="vg">@t2</span><span class="p">(<</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%r</span><span class="p">,</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%A</span><span class="p">,</span> <span class="kt">double</span> <span class="nv">%B</span><span class="p">)</span> <span class="p">{</span>
+     <span class="nv">%tmp3</span> <span class="p">=</span> <span class="k">load</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%A</span><span class="p">,</span> <span class="k">align</span> <span class="m">16</span>
+     <span class="nv">%tmp7</span> <span class="p">=</span> <span class="k">insertelement</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="k">undef</span><span class="p">,</span> <span class="kt">double</span> <span class="nv">%B</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span>
+     <span class="nv">%tmp9</span> <span class="p">=</span> <span class="k">shufflevector</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="nv">%tmp3</span><span class="p">,</span>
+                            <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="nv">%tmp7</span><span class="p">,</span>
+                            <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="p"><</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">2</span> <span class="p">></span>
+     <span class="k">store</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="nv">%tmp9</span><span class="p">,</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%r</span><span class="p">,</span> <span class="k">align</span> <span class="m">16</span>
+     <span class="k">ret</span> <span class="kt">void</span>
+
+<span class="c">; CHECK:          t2:</span>
+<span class="c">; CHECK:             movl    8(%esp), %eax</span>
+<span class="c">; CHECK-NEXT:        movapd  (%eax), %xmm0</span>
+<span class="c">; CHECK-NEXT:        movhpd  12(%esp), %xmm0</span>
+<span class="c">; CHECK-NEXT:        movl    4(%esp), %eax</span>
+<span class="c">; CHECK-NEXT:        movapd  %xmm0, (%eax)</span>
+<span class="c">; CHECK-NEXT:        ret</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>“<tt class="docutils literal"><span class="pre">CHECK-NEXT:</span></tt>” directives reject the input unless there is exactly one
+newline between it and the previous directive.  A “<tt class="docutils literal"><span class="pre">CHECK-NEXT:</span></tt>” cannot be
+the first directive in a file.</p>
+</div>
+<div class="section" id="the-check-not-directive">
+<h3>The “CHECK-NOT:” directive<a class="headerlink" href="#the-check-not-directive" title="Permalink to this headline">¶</a></h3>
+<p>The “<tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt>” directive is used to verify that a string doesn’t occur
+between two matches (or before the first match, or after the last match).  For
+example, to verify that a load is removed by a transformation, a test like this
+can be used:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="k">i8</span> <span class="vg">@coerce_offset0</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%V</span><span class="p">,</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%P</span><span class="p">)</span> <span class="p">{</span>
+  <span class="k">store</span> <span class="k">i32</span> <span class="nv">%V</span><span class="p">,</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%P</span>
+
+  <span class="nv">%P2</span> <span class="p">=</span> <span class="k">bitcast</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%P</span> <span class="k">to</span> <span class="k">i8</span><span class="p">*</span>
+  <span class="nv">%P3</span> <span class="p">=</span> <span class="k">getelementptr</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%P2</span><span class="p">,</span> <span class="k">i32</span> <span class="m">2</span>
+
+  <span class="nv">%A</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%P3</span>
+  <span class="k">ret</span> <span class="k">i8</span> <span class="nv">%A</span>
+<span class="c">; CHECK: @coerce_offset0</span>
+<span class="c">; CHECK-NOT: load</span>
+<span class="c">; CHECK: ret i8</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="the-check-dag-directive">
+<h3>The “CHECK-DAG:” directive<a class="headerlink" href="#the-check-dag-directive" title="Permalink to this headline">¶</a></h3>
+<p>If it’s necessary to match strings that don’t occur in a strictly sequential
+order, “<tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt>” could be used to verify them between two matches (or
+before the first match, or after the last match). For example, clang emits
+vtable globals in reverse order. Using <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt>, we can keep the checks
+in the natural order:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s</span>
+
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span> <span class="k">virtual</span> <span class="kt">void</span> <span class="n">method</span><span class="p">();</span> <span class="p">};</span>
+<span class="n">Foo</span> <span class="n">f</span><span class="p">;</span>  <span class="c1">// emit vtable</span>
+<span class="c1">// CHECK-DAG: @_ZTV3Foo =</span>
+
+<span class="k">struct</span> <span class="n">Bar</span> <span class="p">{</span> <span class="k">virtual</span> <span class="kt">void</span> <span class="n">method</span><span class="p">();</span> <span class="p">};</span>
+<span class="n">Bar</span> <span class="n">b</span><span class="p">;</span>
+<span class="c1">// CHECK-DAG: @_ZTV3Bar =</span>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt> directives could be mixed with <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directives to
+exclude strings between the surrounding <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directives. As a result,
+the surrounding <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directives cannot be reordered, i.e. all
+occurrences matching <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> before <tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt> must not fall behind
+occurrences matching <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> after <tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt>. For example,</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK-DAG: BEFORE</span>
+<span class="c">; CHECK-NOT: NOT</span>
+<span class="c">; CHECK-DAG: AFTER</span>
+</pre></div>
+</div>
+<p>This case will reject input strings where <tt class="docutils literal"><span class="pre">BEFORE</span></tt> occurs after <tt class="docutils literal"><span class="pre">AFTER</span></tt>.</p>
+<p>With captured variables, <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> is able to match valid topological
+orderings of a DAG with edges from the definition of a variable to its use.
+It’s useful, e.g., when your test cases need to match different output
+sequences from the instruction scheduler. For example,</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2</span>
+<span class="c">; CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4</span>
+<span class="c">; CHECK:     mul r5, [[REG1]], [[REG2]]</span>
+</pre></div>
+</div>
+<p>In this case, any order of that two <tt class="docutils literal"><span class="pre">add</span></tt> instructions will be allowed.</p>
+<p>If you are defining <cite>and</cite> using variables in the same <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> block,
+be aware that the definition rule can match <cite>after</cite> its use.</p>
+<p>So, for instance, the code below will pass:</p>
+<div class="highlight-llvm"><pre>; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
+; CHECK-DAG: vmov.32 [[REG2]][1]
+vmov.32 d0[1]
+vmov.32 d0[0]</pre>
+</div>
+<p>While this other code, will not:</p>
+<div class="highlight-llvm"><pre>; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
+; CHECK-DAG: vmov.32 [[REG2]][1]
+vmov.32 d1[1]
+vmov.32 d0[0]</pre>
+</div>
+<p>While this can be very useful, it’s also dangerous, because in the case of
+register sequence, you must have a strong order (read before write, copy before
+use, etc). If the definition your test is looking for doesn’t match (because
+of a bug in the compiler), it may match further away from the use, and mask
+real bugs away.</p>
+<p>In those cases, to enforce the order, use a non-DAG directive between DAG-blocks.</p>
+</div>
+<div class="section" id="the-check-label-directive">
+<h3>The “CHECK-LABEL:” directive<a class="headerlink" href="#the-check-label-directive" title="Permalink to this headline">¶</a></h3>
+<p>Sometimes in a file containing multiple tests divided into logical blocks, one
+or more <tt class="docutils literal"><span class="pre">CHECK:</span></tt> directives may inadvertently succeed by matching lines in a
+later block. While an error will usually eventually be generated, the check
+flagged as causing the error may not actually bear any relationship to the
+actual source of the problem.</p>
+<p>In order to produce better error messages in these cases, the “<tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt>”
+directive can be used. It is treated identically to a normal <tt class="docutils literal"><span class="pre">CHECK</span></tt>
+directive except that FileCheck makes an additional assumption that a line
+matched by the directive cannot also be matched by any other check present in
+<tt class="docutils literal"><span class="pre">match-filename</span></tt>; this is intended to be used for lines containing labels or
+other unique identifiers. Conceptually, the presence of <tt class="docutils literal"><span class="pre">CHECK-LABEL</span></tt> divides
+the input stream into separate blocks, each of which is processed independently,
+preventing a <tt class="docutils literal"><span class="pre">CHECK:</span></tt> directive in one block matching a line in another block.
+For example,</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="vg">@C_ctor_base</span><span class="p">(</span><span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%x</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK-LABEL: C_ctor_base:</span>
+<span class="c">; CHECK: mov [[SAVETHIS:r[0-9]+]], r0</span>
+<span class="c">; CHECK: bl A_ctor_base</span>
+<span class="c">; CHECK: mov r0, [[SAVETHIS]]</span>
+  <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">bitcast</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span> <span class="k">to</span> <span class="nv">%struct.A</span><span class="p">*</span>
+  <span class="nv">%call</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="nv">%struct.A</span><span class="p">*</span> <span class="vg">@A_ctor_base</span><span class="p">(</span><span class="nv">%struct.A</span><span class="p">*</span> <span class="nv-Anonymous">%0</span><span class="p">)</span>
+  <span class="nv-Anonymous">%1</span> <span class="p">=</span> <span class="k">bitcast</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span> <span class="k">to</span> <span class="nv">%struct.B</span><span class="p">*</span>
+  <span class="nv">%call2</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="nv">%struct.B</span><span class="p">*</span> <span class="vg">@B_ctor_base</span><span class="p">(</span><span class="nv">%struct.B</span><span class="p">*</span> <span class="nv-Anonymous">%1</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%x</span><span class="p">)</span>
+  <span class="k">ret</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span>
+<span class="p">}</span>
+
+<span class="k">define</span> <span class="nv">%struct.D</span><span class="p">*</span> <span class="vg">@D_ctor_base</span><span class="p">(</span><span class="nv">%struct.D</span><span class="p">*</span> <span class="nv">%this</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%x</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK-LABEL: D_ctor_base:</span>
+</pre></div>
+</div>
+<p>The use of <tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt> directives in this case ensures that the three
+<tt class="docutils literal"><span class="pre">CHECK:</span></tt> directives only accept lines corresponding to the body of the
+<tt class="docutils literal"><span class="pre">@C_ctor_base</span></tt> function, even if the patterns match lines found later in
+the file. Furthermore, if one of these three <tt class="docutils literal"><span class="pre">CHECK:</span></tt> directives fail,
+FileCheck will recover by continuing to the next block, allowing multiple test
+failures to be detected in a single invocation.</p>
+<p>There is no requirement that <tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt> directives contain strings that
+correspond to actual syntactic labels in a source or output language: they must
+simply uniquely match a single line in the file being verified.</p>
+<p><tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt> directives cannot contain variable definitions or uses.</p>
+</div>
+<div class="section" id="filecheck-pattern-matching-syntax">
+<h3>FileCheck Pattern Matching Syntax<a class="headerlink" href="#filecheck-pattern-matching-syntax" title="Permalink to this headline">¶</a></h3>
+<p>The “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” and “<tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt>” directives both take a pattern to match.
+For most uses of FileCheck, fixed string matching is perfectly sufficient.  For
+some things, a more flexible form of matching is desired.  To support this,
+FileCheck allows you to specify regular expressions in matching strings,
+surrounded by double braces: <tt class="docutils literal"><span class="pre">{{yourregex}}</span></tt>.  Because we want to use fixed
+string matching for a majority of what we do, FileCheck has been designed to
+support mixing and matching fixed string matching with regular expressions.
+This allows you to write things like this:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK: movhpd      {{[0-9]+}}(%esp), {{%xmm[0-7]}}</span>
+</pre></div>
+</div>
+<p>In this case, any offset from the ESP register will be allowed, and any xmm
+register will be allowed.</p>
+<p>Because regular expressions are enclosed with double braces, they are
+visually distinct, and you don’t need to use escape characters within the double
+braces like you would in C.  In the rare case that you want to match double
+braces explicitly from the input, you can use something ugly like
+<tt class="docutils literal"><span class="pre">{{[{][{]}}</span></tt> as your pattern.</p>
+</div>
+<div class="section" id="filecheck-variables">
+<h3>FileCheck Variables<a class="headerlink" href="#filecheck-variables" title="Permalink to this headline">¶</a></h3>
+<p>It is often useful to match a pattern and then verify that it occurs again
+later in the file.  For codegen tests, this can be useful to allow any register,
+but verify that that register is used consistently later.  To do this,
+<strong class="program">FileCheck</strong> allows named variables to be defined and substituted into
+patterns.  Here is a simple example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK: test5:</span>
+<span class="c">; CHECK:    notw     [[REGISTER:%[a-z]+]]</span>
+<span class="c">; CHECK:    andw     {{.*}}[[REGISTER]]</span>
+</pre></div>
+</div>
+<p>The first check line matches a regex <tt class="docutils literal"><span class="pre">%[a-z]+</span></tt> and captures it into the
+variable <tt class="docutils literal"><span class="pre">REGISTER</span></tt>.  The second line verifies that whatever is in
+<tt class="docutils literal"><span class="pre">REGISTER</span></tt> occurs later in the file after an “<tt class="docutils literal"><span class="pre">andw</span></tt>”.  <strong class="program">FileCheck</strong>
+variable references are always contained in <tt class="docutils literal"><span class="pre">[[</span> <span class="pre">]]</span></tt> pairs, and their names can
+be formed with the regex <tt class="docutils literal"><span class="pre">[a-zA-Z][a-zA-Z0-9]*</span></tt>.  If a colon follows the name,
+then it is a definition of the variable; otherwise, it is a use.</p>
+<p><strong class="program">FileCheck</strong> variables can be defined multiple times, and uses always
+get the latest value.  Variables can also be used later on the same line they
+were defined on. For example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK: op [[REG:r[0-9]+]], [[REG]]</span>
+</pre></div>
+</div>
+<p>Can be useful if you want the operands of <tt class="docutils literal"><span class="pre">op</span></tt> to be the same register,
+and don’t care exactly which register it is.</p>
+</div>
+<div class="section" id="filecheck-expressions">
+<h3>FileCheck Expressions<a class="headerlink" href="#filecheck-expressions" title="Permalink to this headline">¶</a></h3>
+<p>Sometimes there’s a need to verify output which refers line numbers of the
+match file, e.g. when testing compiler diagnostics.  This introduces a certain
+fragility of the match file structure, as “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines contain absolute
+line numbers in the same file, which have to be updated whenever line numbers
+change due to text addition or deletion.</p>
+<p>To support this case, FileCheck allows using <tt class="docutils literal"><span class="pre">[[@LINE]]</span></tt>,
+<tt class="docutils literal"><span class="pre">[[@LINE+<offset>]]</span></tt>, <tt class="docutils literal"><span class="pre">[[@LINE-<offset>]]</span></tt> expressions in patterns. These
+expressions expand to a number of the line where a pattern is located (with an
+optional integer offset).</p>
+<p>This way match patterns can be put near the relevant test lines and include
+relative line number references, for example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// CHECK: test.cpp:[[@LINE+4]]:6: error: expected ';' after top level declarator</span>
+<span class="c1">// CHECK-NEXT: {{^int a}}</span>
+<span class="c1">// CHECK-NEXT: {{^     \^}}</span>
+<span class="c1">// CHECK-NEXT: {{^     ;}}</span>
+<span class="kt">int</span> <span class="n">a</span>
+</pre></div>
+</div>
+</div>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="llvm-bcanalyzer.html" title="llvm-bcanalyzer - LLVM bitcode analyzer"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/bugpoint.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/bugpoint.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/bugpoint.html Wed May  7 15:09:32 2014
@@ -0,0 +1,258 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>bugpoint - automatic test case reduction tool — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="llvm-extract - extract a function from an LLVM module" href="llvm-extract.html" />
+    <link rel="prev" title="llvm-symbolizer - convert addresses into source code locations" href="llvm-symbolizer.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="llvm-symbolizer.html" title="llvm-symbolizer - convert addresses into source code locations"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="bugpoint-automatic-test-case-reduction-tool">
+<h1>bugpoint - automatic test case reduction tool<a class="headerlink" href="#bugpoint-automatic-test-case-reduction-tool" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>bugpoint</strong> [<em>options</em>] [<em>input LLVM ll/bc files</em>] [<em>LLVM passes</em>] <strong>–args</strong>
+<em>program arguments</em></p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>bugpoint</strong> narrows down the source of problems in LLVM tools and passes.  It
+can be used to debug three types of failures: optimizer crashes, miscompilations
+by optimizers, or bad native code generation (including problems in the static
+and JIT compilers).  It aims to reduce large test cases to small, useful ones.
+For more information on the design and inner workings of <strong>bugpoint</strong>, as well as
+advice for using bugpoint, see <em>llvm/docs/Bugpoint.html</em> in the LLVM
+distribution.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p><strong>–additional-so</strong> <em>library</em></p>
+<blockquote>
+<div>Load the dynamic shared object <em>library</em> into the test program whenever it is
+run.  This is useful if you are debugging programs which depend on non-LLVM
+libraries (such as the X or curses libraries) to run.</div></blockquote>
+<p><strong>–append-exit-code</strong>=<em>{true,false}</em></p>
+<blockquote>
+<div>Append the test programs exit code to the output file so that a change in exit
+code is considered a test failure. Defaults to false.</div></blockquote>
+<p><strong>–args</strong> <em>program args</em></p>
+<blockquote>
+<div><p>Pass all arguments specified after <strong>–args</strong> to the test program whenever it runs.
+Note that if any of the <em>program args</em> start with a “<tt class="docutils literal"><span class="pre">-</span></tt>”, you should use:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint <span class="o">[</span>bugpoint args<span class="o">]</span> --args -- <span class="o">[</span>program args<span class="o">]</span>
+</pre></div>
+</div>
+<p>The “<tt class="docutils literal"><span class="pre">--</span></tt>” right after the <strong>–args</strong> option tells <strong>bugpoint</strong> to consider
+any options starting with “<tt class="docutils literal"><span class="pre">-</span></tt>” to be part of the <strong>–args</strong> option, not as
+options to <strong>bugpoint</strong> itself.</p>
+</div></blockquote>
+<p><strong>–tool-args</strong> <em>tool args</em></p>
+<blockquote>
+<div><p>Pass all arguments specified after <strong>–tool-args</strong> to the LLVM tool under test
+(<strong>llc</strong>, <strong>lli</strong>, etc.) whenever it runs.  You should use this option in the
+following way:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint <span class="o">[</span>bugpoint args<span class="o">]</span> --tool-args -- <span class="o">[</span>tool args<span class="o">]</span>
+</pre></div>
+</div>
+<p>The “<tt class="docutils literal"><span class="pre">--</span></tt>” right after the <strong>–tool-args</strong> option tells <strong>bugpoint</strong> to
+consider any options starting with “<tt class="docutils literal"><span class="pre">-</span></tt>” to be part of the <strong>–tool-args</strong>
+option, not as options to <strong>bugpoint</strong> itself. (See <strong>–args</strong>, above.)</p>
+</div></blockquote>
+<p><strong>–safe-tool-args</strong> <em>tool args</em></p>
+<blockquote>
+<div>Pass all arguments specified after <strong>–safe-tool-args</strong> to the “safe” execution
+tool.</div></blockquote>
+<p><strong>–gcc-tool-args</strong> <em>gcc tool args</em></p>
+<blockquote>
+<div>Pass all arguments specified after <strong>–gcc-tool-args</strong> to the invocation of
+<strong>gcc</strong>.</div></blockquote>
+<p><strong>–opt-args</strong> <em>opt args</em></p>
+<blockquote>
+<div>Pass all arguments specified after <strong>–opt-args</strong> to the invocation of <strong>opt</strong>.</div></blockquote>
+<p><strong>–disable-{dce,simplifycfg}</strong></p>
+<blockquote>
+<div>Do not run the specified passes to clean up and reduce the size of the test
+program. By default, <strong>bugpoint</strong> uses these passes internally when attempting to
+reduce test programs.  If you’re trying to find a bug in one of these passes,
+<strong>bugpoint</strong> may crash.</div></blockquote>
+<p><strong>–enable-valgrind</strong></p>
+<blockquote>
+<div>Use valgrind to find faults in the optimization phase. This will allow
+bugpoint to find otherwise asymptomatic problems caused by memory
+mis-management.</div></blockquote>
+<p><strong>-find-bugs</strong></p>
+<blockquote>
+<div>Continually randomize the specified passes and run them on the test program
+until a bug is found or the user kills <strong>bugpoint</strong>.</div></blockquote>
+<p><strong>-help</strong></p>
+<blockquote>
+<div>Print a summary of command line options.</div></blockquote>
+<p><strong>–input</strong> <em>filename</em></p>
+<blockquote>
+<div>Open <em>filename</em> and redirect the standard input of the test program, whenever
+it runs, to come from that file.</div></blockquote>
+<p><strong>–load</strong> <em>plugin</em></p>
+<blockquote>
+<div><p>Load the dynamic object <em>plugin</em> into <strong>bugpoint</strong> itself.  This object should
+register new optimization passes.  Once loaded, the object will add new command
+line options to enable various optimizations.  To see the new complete list of
+optimizations, use the <strong>-help</strong> and <strong>–load</strong> options together; for example:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint --load myNewPass.so -help
+</pre></div>
+</div>
+</div></blockquote>
+<p><strong>–mlimit</strong> <em>megabytes</em></p>
+<blockquote>
+<div>Specifies an upper limit on memory usage of the optimization and codegen. Set
+to zero to disable the limit.</div></blockquote>
+<p><strong>–output</strong> <em>filename</em></p>
+<blockquote>
+<div>Whenever the test program produces output on its standard output stream, it
+should match the contents of <em>filename</em> (the “reference output”). If you
+do not use this option, <strong>bugpoint</strong> will attempt to generate a reference output
+by compiling the program with the “safe” backend and running it.</div></blockquote>
+<p><strong>–profile-info-file</strong> <em>filename</em></p>
+<blockquote>
+<div>Profile file loaded by <strong>–profile-loader</strong>.</div></blockquote>
+<p><strong>–run-{int,jit,llc,custom}</strong></p>
+<blockquote>
+<div>Whenever the test program is compiled, <strong>bugpoint</strong> should generate code for it
+using the specified code generator.  These options allow you to choose the
+interpreter, the JIT compiler, the static native code compiler, or a
+custom command (see <strong>–exec-command</strong>) respectively.</div></blockquote>
+<p><strong>–safe-{llc,custom}</strong></p>
+<blockquote>
+<div>When debugging a code generator, <strong>bugpoint</strong> should use the specified code
+generator as the “safe” code generator. This is a known-good code generator
+used to generate the “reference output” if it has not been provided, and to
+compile portions of the program that as they are excluded from the testcase.
+These options allow you to choose the
+static native code compiler, or a custom command, (see <strong>–exec-command</strong>)
+respectively. The interpreter and the JIT backends cannot currently
+be used as the “safe” backends.</div></blockquote>
+<p><strong>–exec-command</strong> <em>command</em></p>
+<blockquote>
+<div>This option defines the command to use with the <strong>–run-custom</strong> and
+<strong>–safe-custom</strong> options to execute the bitcode testcase. This can
+be useful for cross-compilation.</div></blockquote>
+<p><strong>–compile-command</strong> <em>command</em></p>
+<blockquote>
+<div><p>This option defines the command to use with the <strong>–compile-custom</strong>
+option to compile the bitcode testcase. This can be useful for
+testing compiler output without running any link or execute stages. To
+generate a reduced unit test, you may add CHECK directives to the
+testcase and pass the name of an executable compile-command script in this form:</p>
+<div class="highlight-sh"><div class="highlight"><pre><span class="c">#!/bin/sh</span>
+llc <span class="s2">"$@"</span>
+not FileCheck <span class="o">[</span>bugpoint input file<span class="o">]</span>.ll < bugpoint-test-program.s
+</pre></div>
+</div>
+<p>This script will “fail” as long as FileCheck passes. So the result
+will be the minimum bitcode that passes FileCheck.</p>
+</div></blockquote>
+<p><strong>–safe-path</strong> <em>path</em></p>
+<blockquote>
+<div>This option defines the path to the command to execute with the
+<strong>–safe-{int,jit,llc,custom}</strong>
+option.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>bugpoint</strong> succeeds in finding a problem, it will exit with 0.  Otherwise,
+if an error occurs, it will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>opt|opt</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="llvm-symbolizer.html" title="llvm-symbolizer - convert addresses into source code locations"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/index.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/index.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/index.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/index.html Wed May  7 15:09:32 2014
@@ -0,0 +1,148 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>LLVM Command Guide — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="next" title="llvm-as - LLVM assembler" href="llvm-as.html" />
+    <link rel="prev" title="How To Cross-Compile Clang/LLVM using Clang/LLVM" href="../HowToCrossCompileLLVM.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-as.html" title="llvm-as - LLVM assembler"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="../HowToCrossCompileLLVM.html" title="How To Cross-Compile Clang/LLVM using Clang/LLVM"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-command-guide">
+<h1>LLVM Command Guide<a class="headerlink" href="#llvm-command-guide" title="Permalink to this headline">¶</a></h1>
+<p>The following documents are command descriptions for all of the LLVM tools.
+These pages describe how to use the LLVM commands and what their options are.
+Note that these pages do not describe all of the options available for all
+tools. To get a complete listing, pass the <tt class="docutils literal"><span class="pre">--help</span></tt> (general options) or
+<tt class="docutils literal"><span class="pre">--help-hidden</span></tt> (general and debugging options) arguments to the tool you are
+interested in.</p>
+<div class="section" id="basic-commands">
+<h2>Basic Commands<a class="headerlink" href="#basic-commands" title="Permalink to this headline">¶</a></h2>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="llvm-as.html">llvm-as - LLVM assembler</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-dis.html">llvm-dis - LLVM disassembler</a></li>
+<li class="toctree-l1"><a class="reference internal" href="opt.html">opt - LLVM optimizer</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llc.html">llc - LLVM static compiler</a></li>
+<li class="toctree-l1"><a class="reference internal" href="lli.html">lli - directly execute programs from LLVM bitcode</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-link.html">llvm-link - LLVM bitcode linker</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-ar.html">llvm-ar - LLVM archiver</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-nm.html">llvm-nm - list LLVM bitcode and object file’s symbol table</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-prof.html">llvm-prof - print execution profile of LLVM program</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-config.html">llvm-config - Print LLVM compilation options</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-diff.html">llvm-diff - LLVM structural ‘diff’</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-cov.html">llvm-cov - emit coverage information</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-stress.html">llvm-stress - generate random .ll files</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-symbolizer.html">llvm-symbolizer - convert addresses into source code locations</a></li>
+</ul>
+</div>
+</div>
+<div class="section" id="debugging-tools">
+<h2>Debugging Tools<a class="headerlink" href="#debugging-tools" title="Permalink to this headline">¶</a></h2>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="bugpoint.html">bugpoint - automatic test case reduction tool</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-extract.html">llvm-extract - extract a function from an LLVM module</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-bcanalyzer.html">llvm-bcanalyzer - LLVM bitcode analyzer</a></li>
+</ul>
+</div>
+</div>
+<div class="section" id="developer-tools">
+<h2>Developer Tools<a class="headerlink" href="#developer-tools" title="Permalink to this headline">¶</a></h2>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="FileCheck.html">FileCheck - Flexible pattern matching file verifier</a></li>
+<li class="toctree-l1"><a class="reference internal" href="tblgen.html">tblgen - Target Description To C++ Code Generator</a></li>
+<li class="toctree-l1"><a class="reference internal" href="lit.html">lit - LLVM Integrated Tester</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-build.html">llvm-build - LLVM Project Build Utility</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-readobj.html">llvm-readobj - LLVM Object Reader</a></li>
+</ul>
+</div>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="llvm-as.html" title="llvm-as - LLVM assembler"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="../HowToCrossCompileLLVM.html" title="How To Cross-Compile Clang/LLVM using Clang/LLVM"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/lit.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/lit.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/lit.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/lit.html Wed May  7 15:09:32 2014
@@ -0,0 +1,482 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>lit - LLVM Integrated Tester — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="llvm-build - LLVM Project Build Utility" href="llvm-build.html" />
+    <link rel="prev" title="tblgen - Target Description To C++ Code Generator" href="tblgen.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-build.html" title="llvm-build - LLVM Project Build Utility"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="lit-llvm-integrated-tester">
+<h1>lit - LLVM Integrated Tester<a class="headerlink" href="#lit-llvm-integrated-tester" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lit</strong> [<em>options</em>] [<em>tests</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lit</strong> is a portable tool for executing LLVM and Clang style test
+suites, summarizing their results, and providing indication of failures.
+<strong class="program">lit</strong> is designed to be a lightweight testing tool with as simple a
+user interface as possible.</p>
+<p><strong class="program">lit</strong> should be run with one or more <em>tests</em> to run specified on the
+command line.  Tests can be either individual test files or directories to
+search for tests (see <a class="reference internal" href="#test-discovery"><em>TEST DISCOVERY</em></a>).</p>
+<p>Each specified test will be executed (potentially in parallel) and once all
+tests have been run <strong class="program">lit</strong> will print summary information on the number
+of tests which passed or failed (see <a class="reference internal" href="#test-status-results"><em>TEST STATUS RESULTS</em></a>).  The
+<strong class="program">lit</strong> program will execute with a non-zero exit code if any tests
+fail.</p>
+<p>By default <strong class="program">lit</strong> will use a succinct progress display and will only
+print summary information for test failures.  See <a class="reference internal" href="#output-options"><em>OUTPUT OPTIONS</em></a> for
+options controlling the <strong class="program">lit</strong> progress display and output.</p>
+<p><strong class="program">lit</strong> also includes a number of options for controlling how tests are
+executed (specific features may depend on the particular test format).  See
+<a class="reference internal" href="#execution-options"><em>EXECUTION OPTIONS</em></a> for more information.</p>
+<p>Finally, <strong class="program">lit</strong> also supports additional options for only running a
+subset of the options specified on the command line, see
+<a class="reference internal" href="#selection-options"><em>SELECTION OPTIONS</em></a> for more information.</p>
+<p>Users interested in the <strong class="program">lit</strong> architecture or designing a
+<strong class="program">lit</strong> testing implementation should see <a class="reference internal" href="#lit-infrastructure"><em>LIT INFRASTRUCTURE</em></a>.</p>
+</div>
+<div class="section" id="general-options">
+<h2>GENERAL OPTIONS<a class="headerlink" href="#general-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-h">
+<tt class="descname">-h</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-h" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the <strong class="program">lit</strong> help message.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-j">
+<tt class="descname">-j</tt><tt class="descclassname"> N</tt><tt class="descclassname">, </tt><tt class="descname">--threads</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption-j" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run <tt class="docutils literal"><span class="pre">N</span></tt> tests in parallel.  By default, this is automatically chosen to
+match the number of detected available CPUs.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--config-prefix">
+<tt class="descname">--config-prefix</tt><tt class="descclassname">=NAME</tt><a class="headerlink" href="#cmdoption--config-prefix" title="Permalink to this definition">¶</a></dt>
+<dd><p>Search for <tt class="file docutils literal"><em><span class="pre">NAME</span></em><span class="pre">.cfg</span></tt> and <tt class="file docutils literal"><em><span class="pre">NAME</span></em><span class="pre">.site.cfg</span></tt> when searching for
+test suites, instead of <tt class="file docutils literal"><span class="pre">lit.cfg</span></tt> and <tt class="file docutils literal"><span class="pre">lit.site.cfg</span></tt>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--param">
+<tt class="descname">--param</tt><tt class="descclassname"> NAME</tt><tt class="descclassname">, </tt><tt class="descname">--param</tt><tt class="descclassname"> NAME=VALUE</tt><a class="headerlink" href="#cmdoption--param" title="Permalink to this definition">¶</a></dt>
+<dd><p>Add a user defined parameter <tt class="docutils literal"><span class="pre">NAME</span></tt> with the given <tt class="docutils literal"><span class="pre">VALUE</span></tt> (or the empty
+string if not given).  The meaning and use of these parameters is test suite
+dependent.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="output-options">
+<span id="id1"></span><h2>OUTPUT OPTIONS<a class="headerlink" href="#output-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-q">
+<tt class="descname">-q</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--quiet</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-q" title="Permalink to this definition">¶</a></dt>
+<dd><p>Suppress any output except for test failures.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-s">
+<tt class="descname">-s</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--succinct</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-s" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show less output, for example don’t show information on tests that pass.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-v">
+<tt class="descname">-v</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--verbose</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-v" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show more information on test failures, for example the entire test output
+instead of just the test result.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--no-progress-bar">
+<tt class="descname">--no-progress-bar</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--no-progress-bar" title="Permalink to this definition">¶</a></dt>
+<dd><p>Do not use curses based progress bar.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="execution-options">
+<span id="id2"></span><h2>EXECUTION OPTIONS<a class="headerlink" href="#execution-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption--path">
+<tt class="descname">--path</tt><tt class="descclassname">=PATH</tt><a class="headerlink" href="#cmdoption--path" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify an additional <tt class="docutils literal"><span class="pre">PATH</span></tt> to use when searching for executables in tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--vg">
+<tt class="descname">--vg</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--vg" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run individual tests under valgrind (using the memcheck tool).  The
+<tt class="docutils literal"><span class="pre">--error-exitcode</span></tt> argument for valgrind is used so that valgrind failures
+will cause the program to exit with a non-zero status.</p>
+<p>When this option is enabled, <strong class="program">lit</strong> will also automatically provide a
+“<tt class="docutils literal"><span class="pre">valgrind</span></tt>” feature that can be used to conditionally disable (or expect
+failure in) certain tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--vg-arg">
+<tt class="descname">--vg-arg</tt><tt class="descclassname">=ARG</tt><a class="headerlink" href="#cmdoption--vg-arg" title="Permalink to this definition">¶</a></dt>
+<dd><p>When <a class="reference internal" href="#cmdoption--vg"><em class="xref std std-option">--vg</em></a> is used, specify an additional argument to pass to
+<strong class="program">valgrind</strong> itself.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--vg-leak">
+<tt class="descname">--vg-leak</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--vg-leak" title="Permalink to this definition">¶</a></dt>
+<dd><p>When <a class="reference internal" href="#cmdoption--vg"><em class="xref std std-option">--vg</em></a> is used, enable memory leak checks.  When this option is
+enabled, <strong class="program">lit</strong> will also automatically provide a “<tt class="docutils literal"><span class="pre">vg_leak</span></tt>”
+feature that can be used to conditionally disable (or expect failure in)
+certain tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--time-tests">
+<tt class="descname">--time-tests</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--time-tests" title="Permalink to this definition">¶</a></dt>
+<dd><p>Track the wall time individual tests take to execute and includes the results
+in the summary output.  This is useful for determining which tests in a test
+suite take the most time to execute.  Note that this option is most useful
+with <tt class="docutils literal"><span class="pre">-j</span> <span class="pre">1</span></tt>.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="selection-options">
+<span id="id3"></span><h2>SELECTION OPTIONS<a class="headerlink" href="#selection-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption--max-tests">
+<tt class="descname">--max-tests</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption--max-tests" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run at most <tt class="docutils literal"><span class="pre">N</span></tt> tests and then terminate.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--max-time">
+<tt class="descname">--max-time</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption--max-time" title="Permalink to this definition">¶</a></dt>
+<dd><p>Spend at most <tt class="docutils literal"><span class="pre">N</span></tt> seconds (approximately) running tests and then terminate.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--shuffle">
+<tt class="descname">--shuffle</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--shuffle" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run the tests in a random order.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="additional-options">
+<h2>ADDITIONAL OPTIONS<a class="headerlink" href="#additional-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption--debug">
+<tt class="descname">--debug</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--debug" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run <strong class="program">lit</strong> in debug mode, for debugging configuration issues and
+<strong class="program">lit</strong> itself.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--show-suites">
+<tt class="descname">--show-suites</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-suites" title="Permalink to this definition">¶</a></dt>
+<dd><p>List the discovered test suites and exit.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--show-tests">
+<tt class="descname">--show-tests</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-tests" title="Permalink to this definition">¶</a></dt>
+<dd><p>List all of the the discovered tests and exit.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lit</strong> will exit with an exit code of 1 if there are any FAIL or XPASS
+results.  Otherwise, it will exit with the status 0.  Other exit codes are used
+for non-test related failures (for example a user error or an internal program
+error).</p>
+</div>
+<div class="section" id="test-discovery">
+<span id="id4"></span><h2>TEST DISCOVERY<a class="headerlink" href="#test-discovery" title="Permalink to this headline">¶</a></h2>
+<p>The inputs passed to <strong class="program">lit</strong> can be either individual tests, or entire
+directories or hierarchies of tests to run.  When <strong class="program">lit</strong> starts up, the
+first thing it does is convert the inputs into a complete list of tests to run
+as part of <em>test discovery</em>.</p>
+<p>In the <strong class="program">lit</strong> model, every test must exist inside some <em>test suite</em>.
+<strong class="program">lit</strong> resolves the inputs specified on the command line to test suites
+by searching upwards from the input path until it finds a <tt class="file docutils literal"><span class="pre">lit.cfg</span></tt> or
+<tt class="file docutils literal"><span class="pre">lit.site.cfg</span></tt> file.  These files serve as both a marker of test suites
+and as configuration files which <strong class="program">lit</strong> loads in order to understand
+how to find and run the tests inside the test suite.</p>
+<p>Once <strong class="program">lit</strong> has mapped the inputs into test suites it traverses the
+list of inputs adding tests for individual files and recursively searching for
+tests in directories.</p>
+<p>This behavior makes it easy to specify a subset of tests to run, while still
+allowing the test suite configuration to control exactly how tests are
+interpreted.  In addition, <strong class="program">lit</strong> always identifies tests by the test
+suite they are in, and their relative path inside the test suite.  For
+appropriately configured projects, this allows <strong class="program">lit</strong> to provide
+convenient and flexible support for out-of-tree builds.</p>
+</div>
+<div class="section" id="test-status-results">
+<span id="id5"></span><h2>TEST STATUS RESULTS<a class="headerlink" href="#test-status-results" title="Permalink to this headline">¶</a></h2>
+<p>Each test ultimately produces one of the following six results:</p>
+<p><strong>PASS</strong></p>
+<blockquote>
+<div>The test succeeded.</div></blockquote>
+<p><strong>XFAIL</strong></p>
+<blockquote>
+<div>The test failed, but that is expected.  This is used for test formats which allow
+specifying that a test does not currently work, but wish to leave it in the test
+suite.</div></blockquote>
+<p><strong>XPASS</strong></p>
+<blockquote>
+<div>The test succeeded, but it was expected to fail.  This is used for tests which
+were specified as expected to fail, but are now succeeding (generally because
+the feature they test was broken and has been fixed).</div></blockquote>
+<p><strong>FAIL</strong></p>
+<blockquote>
+<div>The test failed.</div></blockquote>
+<p><strong>UNRESOLVED</strong></p>
+<blockquote>
+<div>The test result could not be determined.  For example, this occurs when the test
+could not be run, the test itself is invalid, or the test was interrupted.</div></blockquote>
+<p><strong>UNSUPPORTED</strong></p>
+<blockquote>
+<div>The test is not supported in this environment.  This is used by test formats
+which can report unsupported tests.</div></blockquote>
+<p>Depending on the test format tests may produce additional information about
+their status (generally only for failures).  See the <a class="reference internal" href="#output-options"><em>OUTPUT OPTIONS</em></a>
+section for more information.</p>
+</div>
+<div class="section" id="lit-infrastructure">
+<span id="id6"></span><h2>LIT INFRASTRUCTURE<a class="headerlink" href="#lit-infrastructure" title="Permalink to this headline">¶</a></h2>
+<p>This section describes the <strong class="program">lit</strong> testing architecture for users interested in
+creating a new <strong class="program">lit</strong> testing implementation, or extending an existing one.</p>
+<p><strong class="program">lit</strong> proper is primarily an infrastructure for discovering and running
+arbitrary tests, and to expose a single convenient interface to these
+tests. <strong class="program">lit</strong> itself doesn’t know how to run tests, rather this logic is
+defined by <em>test suites</em>.</p>
+<div class="section" id="test-suites">
+<h3>TEST SUITES<a class="headerlink" href="#test-suites" title="Permalink to this headline">¶</a></h3>
+<p>As described in <a class="reference internal" href="#test-discovery"><em>TEST DISCOVERY</em></a>, tests are always located inside a <em>test
+suite</em>.  Test suites serve to define the format of the tests they contain, the
+logic for finding those tests, and any additional information to run the tests.</p>
+<p><strong class="program">lit</strong> identifies test suites as directories containing <tt class="docutils literal"><span class="pre">lit.cfg</span></tt> or
+<tt class="docutils literal"><span class="pre">lit.site.cfg</span></tt> files (see also <a class="reference internal" href="#cmdoption--config-prefix"><em class="xref std std-option">--config-prefix</em></a>).  Test suites are
+initially discovered by recursively searching up the directory hierarchy for
+all the input files passed on the command line.  You can use
+<a class="reference internal" href="#cmdoption--show-suites"><em class="xref std std-option">--show-suites</em></a> to display the discovered test suites at startup.</p>
+<p>Once a test suite is discovered, its config file is loaded.  Config files
+themselves are Python modules which will be executed.  When the config file is
+executed, two important global variables are predefined:</p>
+<p><strong>lit</strong></p>
+<blockquote>
+<div>The global <strong>lit</strong> configuration object (a <em>LitConfig</em> instance), which defines
+the builtin test formats, global configuration parameters, and other helper
+routines for implementing test configurations.</div></blockquote>
+<p><strong>config</strong></p>
+<blockquote>
+<div><p>This is the config object (a <em>TestingConfig</em> instance) for the test suite,
+which the config file is expected to populate.  The following variables are also
+available on the <em>config</em> object, some of which must be set by the config and
+others are optional or predefined:</p>
+<p><strong>name</strong> <em>[required]</em> The name of the test suite, for use in reports and
+diagnostics.</p>
+<p><strong>test_format</strong> <em>[required]</em> The test format object which will be used to
+discover and run tests in the test suite.  Generally this will be a builtin test
+format available from the <em>lit.formats</em> module.</p>
+<p><strong>test_source_root</strong> The filesystem path to the test suite root.  For out-of-dir
+builds this is the directory that will be scanned for tests.</p>
+<p><strong>test_exec_root</strong> For out-of-dir builds, the path to the test suite root inside
+the object directory.  This is where tests will be run and temporary output files
+placed.</p>
+<p><strong>environment</strong> A dictionary representing the environment to use when executing
+tests in the suite.</p>
+<p><strong>suffixes</strong> For <strong>lit</strong> test formats which scan directories for tests, this
+variable is a list of suffixes to identify test files.  Used by: <em>ShTest</em>.</p>
+<p><strong>substitutions</strong> For <strong>lit</strong> test formats which substitute variables into a test
+script, the list of substitutions to perform.  Used by: <em>ShTest</em>.</p>
+<p><strong>unsupported</strong> Mark an unsupported directory, all tests within it will be
+reported as unsupported.  Used by: <em>ShTest</em>.</p>
+<p><strong>parent</strong> The parent configuration, this is the config object for the directory
+containing the test suite, or None.</p>
+<p><strong>root</strong> The root configuration.  This is the top-most <strong class="program">lit</strong> configuration in
+the project.</p>
+<p><strong>on_clone</strong> The config is actually cloned for every subdirectory inside a test
+suite, to allow local configuration on a per-directory basis.  The <em>on_clone</em>
+variable can be set to a Python function which will be called whenever a
+configuration is cloned (for a subdirectory).  The function should takes three
+arguments: (1) the parent configuration, (2) the new configuration (which the
+<em>on_clone</em> function will generally modify), and (3) the test path to the new
+directory being scanned.</p>
+<p><strong>pipefail</strong> Normally a test using a shell pipe fails if any of the commands
+on the pipe fail. If this is not desired, setting this variable to false
+makes the test fail only if the last command in the pipe fails.</p>
+</div></blockquote>
+</div>
+<div class="section" id="id7">
+<h3>TEST DISCOVERY<a class="headerlink" href="#id7" title="Permalink to this headline">¶</a></h3>
+<p>Once test suites are located, <strong class="program">lit</strong> recursively traverses the source
+directory (following <em>test_source_root</em>) looking for tests.  When <strong class="program">lit</strong>
+enters a sub-directory, it first checks to see if a nested test suite is
+defined in that directory.  If so, it loads that test suite recursively,
+otherwise it instantiates a local test config for the directory (see
+<a class="reference internal" href="#local-configuration-files"><em>LOCAL CONFIGURATION FILES</em></a>).</p>
+<p>Tests are identified by the test suite they are contained within, and the
+relative path inside that suite.  Note that the relative path may not refer to
+an actual file on disk; some test formats (such as <em>GoogleTest</em>) define
+“virtual tests” which have a path that contains both the path to the actual
+test file and a subpath to identify the virtual test.</p>
+</div>
+<div class="section" id="local-configuration-files">
+<span id="id8"></span><h3>LOCAL CONFIGURATION FILES<a class="headerlink" href="#local-configuration-files" title="Permalink to this headline">¶</a></h3>
+<p>When <strong class="program">lit</strong> loads a subdirectory in a test suite, it instantiates a
+local test configuration by cloning the configuration for the parent direction
+— the root of this configuration chain will always be a test suite.  Once the
+test configuration is cloned <strong class="program">lit</strong> checks for a <em>lit.local.cfg</em> file
+in the subdirectory.  If present, this file will be loaded and can be used to
+specialize the configuration for each individual directory.  This facility can
+be used to define subdirectories of optional tests, or to change other
+configuration parameters — for example, to change the test format, or the
+suffixes which identify test files.</p>
+</div>
+<div class="section" id="test-run-output-format">
+<h3>TEST RUN OUTPUT FORMAT<a class="headerlink" href="#test-run-output-format" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">lit</strong> output for a test run conforms to the following schema, in
+both short and verbose modes (although in short mode no PASS lines will be
+shown).  This schema has been chosen to be relatively easy to reliably parse by
+a machine (for example in buildbot log scraping), and for other tools to
+generate.</p>
+<p>Each test result is expected to appear on a line that matches:</p>
+<div class="highlight-none"><div class="highlight"><pre><result code>: <test name> (<progress info>)
+</pre></div>
+</div>
+<p>where <tt class="docutils literal"><span class="pre"><result-code></span></tt> is a standard test result such as PASS, FAIL, XFAIL,
+XPASS, UNRESOLVED, or UNSUPPORTED.  The performance result codes of IMPROVED and
+REGRESSED are also allowed.</p>
+<p>The <tt class="docutils literal"><span class="pre"><test</span> <span class="pre">name></span></tt> field can consist of an arbitrary string containing no
+newline.</p>
+<p>The <tt class="docutils literal"><span class="pre"><progress</span> <span class="pre">info></span></tt> field can be used to report progress information such
+as (1/300) or can be empty, but even when empty the parentheses are required.</p>
+<p>Each test result may include additional (multiline) log information in the
+following format:</p>
+<div class="highlight-none"><div class="highlight"><pre><log delineator> TEST '(<test name>)' <trailing delineator>
+... log message ...
+<log delineator>
+</pre></div>
+</div>
+<p>where <tt class="docutils literal"><span class="pre"><test</span> <span class="pre">name></span></tt> should be the name of a preceding reported test, <tt class="docutils literal"><span class="pre"><log</span>
+<span class="pre">delineator></span></tt> is a string of “*” characters <em>at least</em> four characters long
+(the recommended length is 20), and <tt class="docutils literal"><span class="pre"><trailing</span> <span class="pre">delineator></span></tt> is an arbitrary
+(unparsed) string.</p>
+<p>The following is an example of a test run output which consists of four tests A,
+B, C, and D, and a log message for the failing test C:</p>
+<div class="highlight-none"><div class="highlight"><pre>PASS: A (1 of 4)
+PASS: B (2 of 4)
+FAIL: C (3 of 4)
+******************** TEST 'C' FAILED ********************
+Test 'C' failed as a result of exit code 1.
+********************
+PASS: D (4 of 4)
+</pre></div>
+</div>
+</div>
+<div class="section" id="lit-example-tests">
+<h3>LIT EXAMPLE TESTS<a class="headerlink" href="#lit-example-tests" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">lit</strong> distribution contains several example implementations of
+test suites in the <em>ExampleTests</em> directory.</p>
+</div>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>valgrind(1)</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="llvm-build.html" title="llvm-build - LLVM Project Build Utility"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/llc.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/llc.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/llc.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/llc.html Wed May  7 15:09:32 2014
@@ -0,0 +1,316 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>llc - LLVM static compiler — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="lli - directly execute programs from LLVM bitcode" href="lli.html" />
+    <link rel="prev" title="opt - LLVM optimizer" href="opt.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="lli.html" title="lli - directly execute programs from LLVM bitcode"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="opt.html" title="opt - LLVM optimizer"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llc-llvm-static-compiler">
+<h1>llc - LLVM static compiler<a class="headerlink" href="#llc-llvm-static-compiler" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llc</strong> [<em>options</em>] [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong class="program">llc</strong> command compiles LLVM source inputs into assembly language
+for a specified architecture.  The assembly language output can then be passed
+through a native assembler and linker to generate a native executable.</p>
+<p>The choice of architecture for the output assembly code is automatically
+determined from the input file, unless the <a class="reference internal" href="#cmdoption-march"><em class="xref std std-option">-march</em></a> option is used to
+override the default.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p>If <tt class="docutils literal"><span class="pre">filename</span></tt> is “<tt class="docutils literal"><span class="pre">-</span></tt>” or omitted, <strong class="program">llc</strong> reads from standard input.
+Otherwise, it will from <tt class="docutils literal"><span class="pre">filename</span></tt>.  Inputs can be in either the LLVM assembly
+language format (<tt class="docutils literal"><span class="pre">.ll</span></tt>) or the LLVM bitcode format (<tt class="docutils literal"><span class="pre">.bc</span></tt>).</p>
+<p>If the <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a> option is omitted, then <strong class="program">llc</strong> will send its output
+to standard output if the input is from standard input.  If the <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a>
+option specifies “<tt class="docutils literal"><span class="pre">-</span></tt>”, then the output will also be sent to standard output.</p>
+<p>If no <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a> option is specified and an input file other than “<tt class="docutils literal"><span class="pre">-</span></tt>” is
+specified, then <strong class="program">llc</strong> creates the output filename by taking the input
+filename, removing any existing <tt class="docutils literal"><span class="pre">.bc</span></tt> extension, and adding a <tt class="docutils literal"><span class="pre">.s</span></tt> suffix.</p>
+<p>Other <strong class="program">llc</strong> options are described below.</p>
+<div class="section" id="end-user-options">
+<h3>End-user Options<a class="headerlink" href="#end-user-options" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-O">
+<tt class="descname">-O</tt><tt class="descclassname">=uint</tt><a class="headerlink" href="#cmdoption-O" title="Permalink to this definition">¶</a></dt>
+<dd><p>Generate code at different optimization levels.  These correspond to the
+<tt class="docutils literal"><span class="pre">-O0</span></tt>, <tt class="docutils literal"><span class="pre">-O1</span></tt>, <tt class="docutils literal"><span class="pre">-O2</span></tt>, and <tt class="docutils literal"><span class="pre">-O3</span></tt> optimization levels used by
+<strong class="program">llvm-gcc</strong> and <strong class="program">clang</strong>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mtriple">
+<tt class="descname">-mtriple</tt><tt class="descclassname">=<target triple></tt><a class="headerlink" href="#cmdoption-mtriple" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override the target triple specified in the input file with the specified
+string.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-march">
+<tt class="descname">-march</tt><tt class="descclassname">=<arch></tt><a class="headerlink" href="#cmdoption-march" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the architecture for which to generate assembly, overriding the target
+encoded in the input file.  See the output of <tt class="docutils literal"><span class="pre">llc</span> <span class="pre">-help</span></tt> for a list of
+valid architectures.  By default this is inferred from the target triple or
+autodetected to the current architecture.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mcpu">
+<tt class="descname">-mcpu</tt><tt class="descclassname">=<cpuname></tt><a class="headerlink" href="#cmdoption-mcpu" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture.  For a list of available CPUs, use:</p>
+<div class="highlight-none"><div class="highlight"><pre>llvm-as < /dev/null | llc -march=xyz -mcpu=help
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-filetype">
+<tt class="descname">-filetype</tt><tt class="descclassname">=<output file type></tt><a class="headerlink" href="#cmdoption-filetype" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify what kind of output <tt class="docutils literal"><span class="pre">llc</span></tt> should generated.  Options are: <tt class="docutils literal"><span class="pre">asm</span></tt>
+for textual assembly ( <tt class="docutils literal"><span class="pre">'.s'</span></tt>), <tt class="docutils literal"><span class="pre">obj</span></tt> for native object files (<tt class="docutils literal"><span class="pre">'.o'</span></tt>)
+and <tt class="docutils literal"><span class="pre">null</span></tt> for not emitting anything (for performance testing).</p>
+<p>Note that not all targets support all options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mattr">
+<tt class="descname">-mattr</tt><tt class="descclassname">=a1,+a2,-a3,...</tt><a class="headerlink" href="#cmdoption-mattr" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not.  The default set of attributes is set by the
+current CPU.  For a list of available attributes, use:</p>
+<div class="highlight-none"><div class="highlight"><pre>llvm-as < /dev/null | llc -march=xyz -mattr=help
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--disable-fp-elim">
+<tt class="descname">--disable-fp-elim</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--disable-fp-elim" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable frame pointer elimination optimization.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--disable-excess-fp-precision">
+<tt class="descname">--disable-excess-fp-precision</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--disable-excess-fp-precision" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable optimizations that may produce excess precision for floating point.
+Note that this option can dramatically slow down code on some systems
+(e.g. X86).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-no-infs-fp-math">
+<tt class="descname">--enable-no-infs-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-no-infs-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that assume no Inf values.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-no-nans-fp-math">
+<tt class="descname">--enable-no-nans-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-no-nans-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that assume no NAN values.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-unsafe-fp-math">
+<tt class="descname">--enable-unsafe-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-unsafe-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that make unsafe assumptions about IEEE math (e.g. that
+addition is associative) or may not work for all input ranges.  These
+optimizations allow the code generator to make use of some instructions which
+would otherwise not be usable (such as <tt class="docutils literal"><span class="pre">fsin</span></tt> on X86).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-correct-eh-support">
+<tt class="descname">--enable-correct-eh-support</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-correct-eh-support" title="Permalink to this definition">¶</a></dt>
+<dd><p>Instruct the <strong>lowerinvoke</strong> pass to insert code for correct exception
+handling support.  This is expensive and is by default omitted for efficiency.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--stats">
+<tt class="descname">--stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print statistics recorded by code-generation passes.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--time-passes">
+<tt class="descname">--time-passes</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--time-passes" title="Permalink to this definition">¶</a></dt>
+<dd><p>Record the amount of time needed for each pass and print a report to standard
+error.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--load">
+<tt class="descname">--load</tt><tt class="descclassname">=<dso_path></tt><a class="headerlink" href="#cmdoption--load" title="Permalink to this definition">¶</a></dt>
+<dd><p>Dynamically load <tt class="docutils literal"><span class="pre">dso_path</span></tt> (a path to a dynamically shared object) that
+implements an LLVM target.  This will permit the target name to be used with
+the <a class="reference internal" href="#cmdoption-march"><em class="xref std std-option">-march</em></a> option so that code can be generated for that target.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="tuning-configuration-options">
+<h3>Tuning/Configuration Options<a class="headerlink" href="#tuning-configuration-options" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption--print-machineinstrs">
+<tt class="descname">--print-machineinstrs</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--print-machineinstrs" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print generated machine code between compilation phases (useful for debugging).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--regalloc">
+<tt class="descname">--regalloc</tt><tt class="descclassname">=<allocator></tt><a class="headerlink" href="#cmdoption--regalloc" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the register allocator to use.
+Valid register allocators are:</p>
+<p><em>basic</em></p>
+<blockquote>
+<div>Basic register allocator.</div></blockquote>
+<p><em>fast</em></p>
+<blockquote>
+<div>Fast register allocator. It is the default for unoptimized code.</div></blockquote>
+<p><em>greedy</em></p>
+<blockquote>
+<div>Greedy register allocator. It is the default for optimized code.</div></blockquote>
+<p><em>pbqp</em></p>
+<blockquote>
+<div>Register allocator based on ‘Partitioned Boolean Quadratic Programming’.</div></blockquote>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--spiller">
+<tt class="descname">--spiller</tt><tt class="descclassname">=<spiller></tt><a class="headerlink" href="#cmdoption--spiller" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the spiller to use for register allocators that support it.  Currently
+this option is used only by the linear scan register allocator.  The default
+<tt class="docutils literal"><span class="pre">spiller</span></tt> is <em>local</em>.  Valid spillers are:</p>
+<p><em>simple</em></p>
+<blockquote>
+<div>Simple spiller</div></blockquote>
+<p><em>local</em></p>
+<blockquote>
+<div>Local spiller</div></blockquote>
+</dd></dl>
+
+</div>
+<div class="section" id="intel-ia-32-specific-options">
+<h3>Intel IA-32-specific Options<a class="headerlink" href="#intel-ia-32-specific-options" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption--x86-asm-syntax">
+<tt class="descname">--x86-asm-syntax</tt><tt class="descclassname">=[att|intel]</tt><a class="headerlink" href="#cmdoption--x86-asm-syntax" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify whether to emit assembly code in AT&T syntax (the default) or Intel
+syntax.</p>
+</dd></dl>
+
+</div>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">llc</strong> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>lli</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="lli.html" title="lli - directly execute programs from LLVM bitcode"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="opt.html" title="opt - LLVM optimizer"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/lli.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/lli.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/lli.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/lli.html Wed May  7 15:09:32 2014
@@ -0,0 +1,278 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>lli - directly execute programs from LLVM bitcode — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="llvm-link - LLVM bitcode linker" href="llvm-link.html" />
+    <link rel="prev" title="llc - LLVM static compiler" href="llc.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="llc.html" title="llc - LLVM static compiler"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="lli-directly-execute-programs-from-llvm-bitcode">
+<h1>lli - directly execute programs from LLVM bitcode<a class="headerlink" href="#lli-directly-execute-programs-from-llvm-bitcode" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>lli</strong> [<em>options</em>] [<em>filename</em>] [<em>program args</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>lli</strong> directly executes programs in LLVM bitcode format.  It takes a program
+in LLVM bitcode format and executes it using a just-in-time compiler, if one is
+available for the current architecture, or an interpreter.  <strong>lli</strong> takes all of
+the same code generator options as llc|llc, but they are only effective when
+<strong>lli</strong> is using the just-in-time compiler.</p>
+<p>If <em>filename</em> is not specified, then <strong>lli</strong> reads the LLVM bitcode for the
+program from standard input.</p>
+<p>The optional <em>args</em> specified on the command line are passed to the program as
+arguments.</p>
+</div>
+<div class="section" id="general-options">
+<h2>GENERAL OPTIONS<a class="headerlink" href="#general-options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-fake-argv0</strong>=<em>executable</em></p>
+<blockquote>
+<div>Override the <tt class="docutils literal"><span class="pre">argv[0]</span></tt> value passed into the executing program.</div></blockquote>
+<p><strong>-force-interpreter</strong>=<em>{false,true}</em></p>
+<blockquote>
+<div>If set to true, use the interpreter even if a just-in-time compiler is available
+for this architecture. Defaults to false.</div></blockquote>
+<p><strong>-help</strong></p>
+<blockquote>
+<div>Print a summary of command line options.</div></blockquote>
+<p><strong>-load</strong>=<em>pluginfilename</em></p>
+<blockquote>
+<div>Causes <strong>lli</strong> to load the plugin (shared object) named <em>pluginfilename</em> and use
+it for optimization.</div></blockquote>
+<p><strong>-stats</strong></p>
+<blockquote>
+<div>Print statistics from the code-generation passes. This is only meaningful for
+the just-in-time compiler, at present.</div></blockquote>
+<p><strong>-time-passes</strong></p>
+<blockquote>
+<div>Record the amount of time needed for each code-generation pass and print it to
+standard error.</div></blockquote>
+<p><strong>-version</strong></p>
+<blockquote>
+<div>Print out the version of <strong>lli</strong> and exit without doing anything else.</div></blockquote>
+</div>
+<div class="section" id="target-options">
+<h2>TARGET OPTIONS<a class="headerlink" href="#target-options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-mtriple</strong>=<em>target triple</em></p>
+<blockquote>
+<div>Override the target triple specified in the input bitcode file with the
+specified string.  This may result in a crash if you pick an
+architecture which is not compatible with the current system.</div></blockquote>
+<p><strong>-march</strong>=<em>arch</em></p>
+<blockquote>
+<div>Specify the architecture for which to generate assembly, overriding the target
+encoded in the bitcode file.  See the output of <strong>llc -help</strong> for a list of
+valid architectures.  By default this is inferred from the target triple or
+autodetected to the current architecture.</div></blockquote>
+<p><strong>-mcpu</strong>=<em>cpuname</em></p>
+<blockquote>
+<div>Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture.  For a list of available CPUs, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mcpu=help</strong></div></blockquote>
+<p><strong>-mattr</strong>=<em>a1,+a2,-a3,...</em></p>
+<blockquote>
+<div>Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not.  The default set of attributes is set by the
+current CPU.  For a list of available attributes, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mattr=help</strong></div></blockquote>
+</div>
+<div class="section" id="floating-point-options">
+<h2>FLOATING POINT OPTIONS<a class="headerlink" href="#floating-point-options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-disable-excess-fp-precision</strong></p>
+<blockquote>
+<div>Disable optimizations that may increase floating point precision.</div></blockquote>
+<p><strong>-enable-no-infs-fp-math</strong></p>
+<blockquote>
+<div>Enable optimizations that assume no Inf values.</div></blockquote>
+<p><strong>-enable-no-nans-fp-math</strong></p>
+<blockquote>
+<div>Enable optimizations that assume no NAN values.</div></blockquote>
+<p><strong>-enable-unsafe-fp-math</strong></p>
+<blockquote>
+<div>Causes <strong>lli</strong> to enable optimizations that may decrease floating point
+precision.</div></blockquote>
+<p><strong>-soft-float</strong></p>
+<blockquote>
+<div>Causes <strong>lli</strong> to generate software floating point library calls instead of
+equivalent hardware instructions.</div></blockquote>
+</div>
+<div class="section" id="code-generation-options">
+<h2>CODE GENERATION OPTIONS<a class="headerlink" href="#code-generation-options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-code-model</strong>=<em>model</em></p>
+<blockquote>
+<div><p>Choose the code model from:</p>
+<div class="highlight-perl"><div class="highlight"><pre><span class="n">default:</span> <span class="n">Target</span> <span class="n">default</span> <span class="n">code</span> <span class="n">model</span>
+<span class="n">small:</span> <span class="n">Small</span> <span class="n">code</span> <span class="n">model</span>
+<span class="n">kernel:</span> <span class="n">Kernel</span> <span class="n">code</span> <span class="n">model</span>
+<span class="n">medium:</span> <span class="n">Medium</span> <span class="n">code</span> <span class="n">model</span>
+<span class="n">large:</span> <span class="n">Large</span> <span class="n">code</span> <span class="n">model</span>
+</pre></div>
+</div>
+</div></blockquote>
+<p><strong>-disable-post-RA-scheduler</strong></p>
+<blockquote>
+<div>Disable scheduling after register allocation.</div></blockquote>
+<p><strong>-disable-spill-fusing</strong></p>
+<blockquote>
+<div>Disable fusing of spill code into instructions.</div></blockquote>
+<p><strong>-enable-correct-eh-support</strong></p>
+<blockquote>
+<div>Make the -lowerinvoke pass insert expensive, but correct, EH code.</div></blockquote>
+<p><strong>-jit-enable-eh</strong></p>
+<blockquote>
+<div>Exception handling should be enabled in the just-in-time compiler.</div></blockquote>
+<p><strong>-join-liveintervals</strong></p>
+<blockquote>
+<div>Coalesce copies (default=true).</div></blockquote>
+<p><strong>-nozero-initialized-in-bss</strong> Don’t place zero-initialized symbols into the BSS section.</p>
+<p><strong>-pre-RA-sched</strong>=<em>scheduler</em></p>
+<blockquote>
+<div><p>Instruction schedulers available (before register allocation):</p>
+<div class="highlight-perl"><div class="highlight"><pre><span class="o">=</span><span class="n">default:</span> <span class="n">Best</span> <span class="n">scheduler</span> <span class="k">for</span> <span class="n">the</span> <span class="n">target</span>
+<span class="o">=</span><span class="n">none:</span> <span class="n">No</span> <span class="n">scheduling:</span> <span class="n">breadth</span> <span class="n">first</span> <span class="n">sequencing</span>
+<span class="o">=</span><span class="n">simple:</span> <span class="n">Simple</span> <span class="n">two</span> <span class="n">pass</span> <span class="n">scheduling:</span> <span class="n">minimize</span> <span class="n">critical</span> <span class="n">path</span> <span class="ow">and</span> <span class="n">maximize</span> <span class="n">processor</span> <span class="n">utilization</span>
+<span class="o">=</span><span class="n">simple</span><span class="o">-</span><span class="n">noitin:</span> <span class="n">Simple</span> <span class="n">two</span> <span class="n">pass</span> <span class="n">scheduling:</span> <span class="n">Same</span> <span class="n">as</span> <span class="n">simple</span> <span class="n">except</span> <span class="n">using</span> <span class="n">generic</span> <span class="n">latency</span>
+<span class="o">=</span><span class="n">list</span><span class="o">-</span><span class="n">burr:</span> <span class="n">Bottom</span><span class="o">-</span><span class="n">up</span> <span class="n">register</span> <span class="n">reduction</span> <span class="n">list</span> <span class="n">scheduling</span>
+<span class="o">=</span><span class="n">list</span><span class="o">-</span><span class="n">tdrr:</span> <span class="n">Top</span><span class="o">-</span><span class="n">down</span> <span class="n">register</span> <span class="n">reduction</span> <span class="n">list</span> <span class="n">scheduling</span>
+<span class="o">=</span><span class="n">list</span><span class="o">-</span><span class="n">td:</span> <span class="n">Top</span><span class="o">-</span><span class="n">down</span> <span class="n">list</span> <span class="n">scheduler</span> <span class="o">-</span><span class="k">print</span><span class="o">-</span><span class="n">machineinstrs</span> <span class="o">-</span> <span class="n">Print</span> <span class="n">generated</span> <span class="n">machine</span> <span class="n">code</span>
+</pre></div>
+</div>
+</div></blockquote>
+<p><strong>-regalloc</strong>=<em>allocator</em></p>
+<blockquote>
+<div><p>Register allocator to use (default=linearscan)</p>
+<div class="highlight-perl"><div class="highlight"><pre><span class="o">=</span><span class="n">bigblock:</span> <span class="n">Big</span><span class="o">-</span><span class="n">block</span> <span class="n">register</span> <span class="n">allocator</span>
+<span class="o">=</span><span class="n">linearscan:</span> <span class="n">linear</span> <span class="n">scan</span> <span class="n">register</span> <span class="n">allocator</span> <span class="o">=</span><span class="nb">local</span> <span class="o">-</span>   <span class="nb">local</span> <span class="n">register</span> <span class="n">allocator</span>
+<span class="o">=</span><span class="n">simple:</span> <span class="n">simple</span> <span class="n">register</span> <span class="n">allocator</span>
+</pre></div>
+</div>
+</div></blockquote>
+<p><strong>-relocation-model</strong>=<em>model</em></p>
+<blockquote>
+<div><p>Choose relocation model from:</p>
+<div class="highlight-perl"><div class="highlight"><pre><span class="o">=</span><span class="n">default:</span> <span class="n">Target</span> <span class="n">default</span> <span class="n">relocation</span> <span class="n">model</span>
+<span class="o">=</span><span class="n">static:</span> <span class="n">Non</span><span class="o">-</span><span class="n">relocatable</span> <span class="n">code</span> <span class="o">=</span><span class="n">pic</span> <span class="o">-</span>   <span class="n">Fully</span> <span class="n">relocatable</span><span class="p">,</span> <span class="n">position</span> <span class="n">independent</span> <span class="n">code</span>
+<span class="o">=</span><span class="n">dynamic</span><span class="o">-</span><span class="nb">no</span><span class="o">-</span><span class="n">pic:</span> <span class="n">Relocatable</span> <span class="n">external</span> <span class="n">references</span><span class="p">,</span> <span class="n">non</span><span class="o">-</span><span class="n">relocatable</span> <span class="n">code</span>
+</pre></div>
+</div>
+</div></blockquote>
+<p><strong>-spiller</strong></p>
+<blockquote>
+<div><p>Spiller to use (default=local)</p>
+<div class="highlight-perl"><div class="highlight"><pre><span class="o">=</span><span class="n">simple:</span> <span class="n">simple</span> <span class="n">spiller</span>
+<span class="o">=</span><span class="nb">local</span><span class="p">:</span> <span class="nb">local</span> <span class="n">spiller</span>
+</pre></div>
+</div>
+</div></blockquote>
+<p><strong>-x86-asm-syntax</strong>=<em>syntax</em></p>
+<blockquote>
+<div><p>Choose style of code to emit from X86 backend:</p>
+<div class="highlight-perl"><div class="highlight"><pre><span class="o">=</span><span class="n">att:</span> <span class="n">Emit</span> <span class="n">AT</span><span class="o">&</span><span class="n">T</span><span class="o">-</span><span class="n">style</span> <span class="n">assembly</span>
+<span class="o">=</span><span class="n">intel:</span> <span class="n">Emit</span> <span class="n">Intel</span><span class="o">-</span><span class="n">style</span> <span class="n">assembly</span>
+</pre></div>
+</div>
+</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>lli</strong> fails to load the program, it will exit with an exit code of 1.
+Otherwise, it will return the exit code of the program it executes.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>llc|llc</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="llc.html" title="llc - LLVM static compiler"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/llvm-ar.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/llvm-ar.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/llvm-ar.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/llvm-ar.html Wed May  7 15:09:32 2014
@@ -0,0 +1,347 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>llvm-ar - LLVM archiver — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="llvm-nm - list LLVM bitcode and object file’s symbol table" href="llvm-nm.html" />
+    <link rel="prev" title="llvm-link - LLVM bitcode linker" href="llvm-link.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-nm.html" title="llvm-nm - list LLVM bitcode and object file’s symbol table"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-ar-llvm-archiver">
+<h1>llvm-ar - LLVM archiver<a class="headerlink" href="#llvm-ar-llvm-archiver" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-ar</strong> [-]{dmpqrtx}[Rabfikou] [relpos] [count] <archive> [files...]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong>llvm-ar</strong> command is similar to the common Unix utility, <tt class="docutils literal"><span class="pre">ar</span></tt>. It
+archives several files together into a single file. The intent for this is
+to produce archive libraries by LLVM bitcode that can be linked into an
+LLVM program. However, the archive can contain any kind of file. By default,
+<strong>llvm-ar</strong> generates a symbol table that makes linking faster because
+only the symbol table needs to be consulted, not each individual file member
+of the archive.</p>
+<p>The <strong>llvm-ar</strong> command can be used to <em>read</em> SVR4, GNU and BSD style archive
+files. However, right now it can only write in the GNU format. If an
+SVR4 or BSD style archive is used with the <tt class="docutils literal"><span class="pre">r</span></tt> (replace) or <tt class="docutils literal"><span class="pre">q</span></tt> (quick
+update) operations, the archive will be reconstructed in GNU format.</p>
+<p>Here’s where <strong>llvm-ar</strong> departs from previous <tt class="docutils literal"><span class="pre">ar</span></tt> implementations:</p>
+<p><em>Symbol Table</em></p>
+<blockquote>
+<div>Since <strong>llvm-ar</strong> supports bitcode files. The symbol table it creates
+is in GNU format and includes both native and bitcode files.</div></blockquote>
+<p><em>Long Paths</em></p>
+<blockquote>
+<div>Currently <strong>llvm-ar</strong> can read GNU and BSD long file names, but only writes
+archives with the GNU format.</div></blockquote>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p>The options to <strong>llvm-ar</strong> are compatible with other <tt class="docutils literal"><span class="pre">ar</span></tt> implementations.
+However, there are a few modifiers (<em>R</em>) that are not found in other <tt class="docutils literal"><span class="pre">ar</span></tt>
+implementations. The options to <strong>llvm-ar</strong> specify a single basic operation to
+perform on the archive, a variety of modifiers for that operation, the name of
+the archive file, and an optional list of file names. These options are used to
+determine how <strong>llvm-ar</strong> should process the archive file.</p>
+<p>The Operations and Modifiers are explained in the sections below. The minimal
+set of options is at least one operator and the name of the archive. Typically
+archive files end with a <tt class="docutils literal"><span class="pre">.a</span></tt> suffix, but this is not required. Following
+the <em>archive-name</em> comes a list of <em>files</em> that indicate the specific members
+of the archive to operate on. If the <em>files</em> option is not specified, it
+generally means either “none” or “all” members, depending on the operation.</p>
+<div class="section" id="operations">
+<h3>Operations<a class="headerlink" href="#operations" title="Permalink to this headline">¶</a></h3>
+<p>d</p>
+<blockquote>
+<div>Delete files from the archive. No modifiers are applicable to this operation.
+The <em>files</em> options specify which members should be removed from the
+archive. It is not an error if a specified file does not appear in the archive.
+If no <em>files</em> are specified, the archive is not modified.</div></blockquote>
+<p>m[abi]</p>
+<blockquote>
+<div>Move files from one location in the archive to another. The <em>a</em>, <em>b</em>, and
+<em>i</em> modifiers apply to this operation. The <em>files</em> will all be moved
+to the location given by the modifiers. If no modifiers are used, the files
+will be moved to the end of the archive. If no <em>files</em> are specified, the
+archive is not modified.</div></blockquote>
+<p>p</p>
+<blockquote>
+<div>Print files to the standard output. This operation simply prints the
+<em>files</em> indicated to the standard output. If no <em>files</em> are
+specified, the entire  archive is printed.  Printing bitcode files is
+ill-advised as they might confuse your terminal settings. The <em>p</em>
+operation never modifies the archive.</div></blockquote>
+<p>q</p>
+<blockquote>
+<div>Quickly append files to the end of the archive.  This operation quickly adds the
+<em>files</em> to the archive without checking for duplicates that should be
+removed first. If no <em>files</em> are specified, the archive is not modified.
+Because of the way that <strong>llvm-ar</strong> constructs the archive file, its dubious
+whether the <em>q</em> operation is any faster than the <em>r</em> operation.</div></blockquote>
+<p>r[abu]</p>
+<blockquote>
+<div>Replace or insert file members. The <em>a</em>, <em>b</em>,  and <em>u</em>
+modifiers apply to this operation. This operation will replace existing
+<em>files</em> or insert them at the end of the archive if they do not exist. If no
+<em>files</em> are specified, the archive is not modified.</div></blockquote>
+<p>t[v]</p>
+<blockquote>
+<div>Print the table of contents. Without any modifiers, this operation just prints
+the names of the members to the standard output. With the <em>v</em> modifier,
+<strong>llvm-ar</strong> also prints out the file type (B=bitcode, S=symbol
+table, blank=regular file), the permission mode, the owner and group, the
+size, and the date. If any <em>files</em> are specified, the listing is only for
+those files. If no <em>files</em> are specified, the table of contents for the
+whole archive is printed.</div></blockquote>
+<p>x[oP]</p>
+<blockquote>
+<div>Extract archive members back to files. The <em>o</em> modifier applies to this
+operation. This operation retrieves the indicated <em>files</em> from the archive
+and writes them back to the operating system’s file system. If no
+<em>files</em> are specified, the entire archive is extract.</div></blockquote>
+</div>
+<div class="section" id="modifiers-operation-specific">
+<h3>Modifiers (operation specific)<a class="headerlink" href="#modifiers-operation-specific" title="Permalink to this headline">¶</a></h3>
+<p>The modifiers below are specific to certain operations. See the Operations
+section (above) to determine which modifiers are applicable to which operations.</p>
+<p>[a]</p>
+<blockquote>
+<div>When inserting or moving member files, this option specifies the destination of
+the new files as being after the <em>relpos</em> member. If <em>relpos</em> is not found,
+the files are placed at the end of the archive.</div></blockquote>
+<p>[b]</p>
+<blockquote>
+<div>When inserting or moving member files, this option specifies the destination of
+the new files as being before the <em>relpos</em> member. If <em>relpos</em> is not
+found, the files are placed at the end of the archive. This modifier is
+identical to the <em>i</em> modifier.</div></blockquote>
+<p>[i]</p>
+<blockquote>
+<div>A synonym for the <em>b</em> option.</div></blockquote>
+<p>[o]</p>
+<blockquote>
+<div>When extracting files, this option will cause <strong>llvm-ar</strong> to preserve the
+original modification times of the files it writes.</div></blockquote>
+<p>[u]</p>
+<blockquote>
+<div>When replacing existing files in the archive, only replace those files that have
+a time stamp than the time stamp of the member in the archive.</div></blockquote>
+</div>
+<div class="section" id="modifiers-generic">
+<h3>Modifiers (generic)<a class="headerlink" href="#modifiers-generic" title="Permalink to this headline">¶</a></h3>
+<p>The modifiers below may be applied to any operation.</p>
+<p>[c]</p>
+<blockquote>
+<div>For all operations, <strong>llvm-ar</strong> will always create the archive if it doesn’t
+exist. Normally, <strong>llvm-ar</strong> will print a warning message indicating that the
+archive is being created. Using this modifier turns off that warning.</div></blockquote>
+<p>[s]</p>
+<blockquote>
+<div>This modifier requests that an archive index (or symbol table) be added to the
+archive. This is the default mode of operation. The symbol table will contain
+all the externally visible functions and global variables defined by all the
+bitcode files in the archive.</div></blockquote>
+<p>[S]</p>
+<blockquote>
+<div>This modifier is the opposite of the <em>s</em> modifier. It instructs <strong>llvm-ar</strong> to
+not build the symbol table. If both <em>s</em> and <em>S</em> are used, the last modifier to
+occur in the options will prevail.</div></blockquote>
+<p>[v]</p>
+<blockquote>
+<div>This modifier instructs <strong>llvm-ar</strong> to be verbose about what it is doing. Each
+editing operation taken against the archive will produce a line of output saying
+what is being done.</div></blockquote>
+</div>
+</div>
+<div class="section" id="standards">
+<h2>STANDARDS<a class="headerlink" href="#standards" title="Permalink to this headline">¶</a></h2>
+<p>The <strong>llvm-ar</strong> utility is intended to provide a superset of the IEEE Std 1003.2
+(POSIX.2) functionality for <tt class="docutils literal"><span class="pre">ar</span></tt>. <strong>llvm-ar</strong> can read both SVR4 and BSD4.4 (or
+Mac OS X) archives. If the <tt class="docutils literal"><span class="pre">f</span></tt> modifier is given to the <tt class="docutils literal"><span class="pre">x</span></tt> or <tt class="docutils literal"><span class="pre">r</span></tt> operations
+then <strong>llvm-ar</strong> will write SVR4 compatible archives. Without this modifier,
+<strong>llvm-ar</strong> will write BSD4.4 compatible archives that have long names
+immediately after the header and indicated using the “#1/ddd” notation for the
+name in the header.</p>
+</div>
+<div class="section" id="file-format">
+<h2>FILE FORMAT<a class="headerlink" href="#file-format" title="Permalink to this headline">¶</a></h2>
+<p>The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
+archive files. In fact, except for the symbol table, the <tt class="docutils literal"><span class="pre">ar</span></tt> commands on those
+operating systems should be able to read LLVM archive files. The details of the
+file format follow.</p>
+<p>Each archive begins with the archive magic number which is the eight printable
+characters ”!<arch>n” where n represents the newline character (0x0A).
+Following the magic number, the file is composed of even length members that
+begin with an archive header and end with a n padding character if necessary
+(to make the length even). Each file member is composed of a header (defined
+below), an optional newline-terminated “long file name” and the contents of
+the file.</p>
+<p>The fields of the header are described in the items below. All fields of the
+header contain only ASCII characters, are left justified and are right padded
+with space characters.</p>
+<p>name - char[16]</p>
+<blockquote>
+<div>This field of the header provides the name of the archive member. If the name is
+longer than 15 characters or contains a slash (/) character, then this field
+contains <tt class="docutils literal"><span class="pre">#1/nnn</span></tt> where <tt class="docutils literal"><span class="pre">nnn</span></tt> provides the length of the name and the <tt class="docutils literal"><span class="pre">#1/</span></tt>
+is literal.  In this case, the actual name of the file is provided in the <tt class="docutils literal"><span class="pre">nnn</span></tt>
+bytes immediately following the header. If the name is 15 characters or less, it
+is contained directly in this field and terminated with a slash (/) character.</div></blockquote>
+<p>date - char[12]</p>
+<blockquote>
+<div>This field provides the date of modification of the file in the form of a
+decimal encoded number that provides the number of seconds since the epoch
+(since 00:00:00 Jan 1, 1970) per Posix specifications.</div></blockquote>
+<p>uid - char[6]</p>
+<blockquote>
+<div>This field provides the user id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_uid field of the stat structure returned by the stat(2)
+operating system call.</div></blockquote>
+<p>gid - char[6]</p>
+<blockquote>
+<div>This field provides the group id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_gid field of the stat structure returned by the stat(2)
+operating system call.</div></blockquote>
+<p>mode - char[8]</p>
+<blockquote>
+<div>This field provides the access mode of the file encoded as an octal ASCII
+string. This field might not make much sense on non-Unix systems. On Unix, it
+is the same value as the st_mode field of the stat structure returned by the
+stat(2) operating system call.</div></blockquote>
+<p>size - char[10]</p>
+<blockquote>
+<div>This field provides the size of the file, in bytes, encoded as a decimal ASCII
+string.</div></blockquote>
+<p>fmag - char[2]</p>
+<blockquote>
+<div>This field is the archive file member magic number. Its content is always the
+two characters back tick (0x60) and newline (0x0A). This provides some measure
+utility in identifying archive files that have been corrupted.</div></blockquote>
+<p>offset - vbr encoded 32-bit integer</p>
+<blockquote>
+<div>The offset item provides the offset into the archive file where the bitcode
+member is stored that is associated with the symbol. The offset value is 0
+based at the start of the first “normal” file member. To derive the actual
+file offset of the member, you must add the number of bytes occupied by the file
+signature (8 bytes) and the symbol tables. The value of this item is encoded
+using variable bit rate encoding to reduce the size of the symbol table.
+Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
+if there are more bytes to follow. The remaining 7 bits in each byte carry bits
+from the value. The final byte does not have the high bit set.</div></blockquote>
+<p>length - vbr encoded 32-bit integer</p>
+<blockquote>
+<div>The length item provides the length of the symbol that follows. Like this
+<em>offset</em> item, the length is variable bit rate encoded.</div></blockquote>
+<p>symbol - character array</p>
+<blockquote>
+<div>The symbol item provides the text of the symbol that is associated with the
+<em>offset</em>. The symbol is not terminated by any character. Its length is provided
+by the <em>length</em> field. Note that is allowed (but unwise) to use non-printing
+characters (even 0x00) in the symbol. This allows for multiple encodings of
+symbol names.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>llvm-ar</strong> succeeds, it will exit with 0.  A usage error, results
+in an exit code of 1. A hard (file system typically) error results in an
+exit code of 2. Miscellaneous or unknown errors result in an
+exit code of 3.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>ar(1)</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="llvm-nm.html" title="llvm-nm - list LLVM bitcode and object file’s symbol table"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/llvm-as.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/llvm-as.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/llvm-as.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/llvm-as.html Wed May  7 15:09:32 2014
@@ -0,0 +1,148 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>llvm-as - LLVM assembler — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="llvm-dis - LLVM disassembler" href="llvm-dis.html" />
+    <link rel="prev" title="LLVM Command Guide" href="index.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-dis.html" title="llvm-dis - LLVM disassembler"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="index.html" title="LLVM Command Guide"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-as-llvm-assembler">
+<h1>llvm-as - LLVM assembler<a class="headerlink" href="#llvm-as-llvm-assembler" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-as</strong> [<em>options</em>] [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-as</strong> is the LLVM assembler.  It reads a file containing human-readable
+LLVM assembly language, translates it to LLVM bitcode, and writes the result
+into a file or to standard output.</p>
+<p>If <em>filename</em> is omitted or is <tt class="docutils literal"><span class="pre">-</span></tt>, then <strong>llvm-as</strong> reads its input from
+standard input.</p>
+<p>If an output file is not specified with the <strong>-o</strong> option, then
+<strong>llvm-as</strong> sends its output to a file or standard output by following
+these rules:</p>
+<ul class="simple">
+<li>If the input is standard input, then the output is standard output.</li>
+<li>If the input is a file that ends with <tt class="docutils literal"><span class="pre">.ll</span></tt>, then the output file is of the
+same name, except that the suffix is changed to <tt class="docutils literal"><span class="pre">.bc</span></tt>.</li>
+<li>If the input is a file that does not end with the <tt class="docutils literal"><span class="pre">.ll</span></tt> suffix, then the
+output file has the same name as the input file, except that the <tt class="docutils literal"><span class="pre">.bc</span></tt>
+suffix is appended.</li>
+</ul>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="docutils">
+<dt><strong>-f</strong></dt>
+<dd>Enable binary output on terminals.  Normally, <strong>llvm-as</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>llvm-as</strong> will write raw bitcode regardless of the output device.</dd>
+<dt><strong>-help</strong></dt>
+<dd>Print a summary of command line options.</dd>
+<dt><strong>-o</strong> <em>filename</em></dt>
+<dd>Specify the output file name.  If <em>filename</em> is <tt class="docutils literal"><span class="pre">-</span></tt>, then <strong>llvm-as</strong>
+sends its output to standard output.</dd>
+</dl>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>llvm-as</strong> succeeds, it will exit with 0.  Otherwise, if an error occurs, it
+will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>llvm-dis|llvm-dis, gccas|gccas</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="llvm-dis.html" title="llvm-dis - LLVM disassembler"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="index.html" title="LLVM Command Guide"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/llvm-bcanalyzer.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/llvm-bcanalyzer.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/llvm-bcanalyzer.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/llvm-bcanalyzer.html Wed May  7 15:09:32 2014
@@ -0,0 +1,354 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>llvm-bcanalyzer - LLVM bitcode analyzer — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="FileCheck - Flexible pattern matching file verifier" href="FileCheck.html" />
+    <link rel="prev" title="llvm-extract - extract a function from an LLVM module" href="llvm-extract.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="FileCheck.html" title="FileCheck - Flexible pattern matching file verifier"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-bcanalyzer-llvm-bitcode-analyzer">
+<h1>llvm-bcanalyzer - LLVM bitcode analyzer<a class="headerlink" href="#llvm-bcanalyzer-llvm-bitcode-analyzer" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-bcanalyzer</strong> [<em>options</em>] [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong class="program">llvm-bcanalyzer</strong> command is a small utility for analyzing bitcode
+files.  The tool reads a bitcode file (such as generated with the
+<strong class="program">llvm-as</strong> tool) and produces a statistical report on the contents of
+the bitcode file.  The tool can also dump a low level but human readable
+version of the bitcode file.  This tool is probably not of much interest or
+utility except for those working directly with the bitcode file format.  Most
+LLVM users can just ignore this tool.</p>
+<p>If <em>filename</em> is omitted or is <tt class="docutils literal"><span class="pre">-</span></tt>, then <strong class="program">llvm-bcanalyzer</strong> reads its
+input from standard input.  This is useful for combining the tool into a
+pipeline.  Output is written to the standard output.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-nodetails">
+<tt class="descname">-nodetails</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-nodetails" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">llvm-bcanalyzer</strong> to abbreviate its output by writing out only
+a module level summary.  The details for individual functions are not
+displayed.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-dump">
+<tt class="descname">-dump</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-dump" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">llvm-bcanalyzer</strong> to dump the bitcode in a human readable
+format.  This format is significantly different from LLVM assembly and
+provides details about the encoding of the bitcode file.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-verify">
+<tt class="descname">-verify</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-verify" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">llvm-bcanalyzer</strong> to verify the module produced by reading the
+bitcode.  This ensures that the statistics generated are based on a consistent
+module.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">llvm-bcanalyzer</strong> succeeds, it will exit with 0.  Otherwise, if an
+error occurs, it will exit with a non-zero value, usually 1.</p>
+</div>
+<div class="section" id="summary-output-definitions">
+<h2>SUMMARY OUTPUT DEFINITIONS<a class="headerlink" href="#summary-output-definitions" title="Permalink to this headline">¶</a></h2>
+<p>The following items are always printed by llvm-bcanalyzer.  They comprize the
+summary output.</p>
+<p><strong>Bitcode Analysis Of Module</strong></p>
+<blockquote>
+<div>This just provides the name of the module for which bitcode analysis is being
+generated.</div></blockquote>
+<p><strong>Bitcode Version Number</strong></p>
+<blockquote>
+<div>The bitcode version (not LLVM version) of the file read by the analyzer.</div></blockquote>
+<p><strong>File Size</strong></p>
+<blockquote>
+<div>The size, in bytes, of the entire bitcode file.</div></blockquote>
+<p><strong>Module Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the module block.  Percentage is relative to File Size.</div></blockquote>
+<p><strong>Function Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the function blocks.  Percentage is relative to File
+Size.</div></blockquote>
+<p><strong>Global Types Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the Global Types Pool.  Percentage is relative to File
+Size.  This is the size of the definitions of all types in the bitcode file.</div></blockquote>
+<p><strong>Constant Pool Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
+Size.</div></blockquote>
+<p><strong>Module Globals Bytes</strong></p>
+<blockquote>
+<div>Ths size, in bytes, of the Global Variable Definitions and their initializers.
+Percentage is relative to File Size.</div></blockquote>
+<p><strong>Instruction List Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the instruction lists in all the functions.
+Percentage is relative to File Size.  Note that this value is also included in
+the Function Bytes.</div></blockquote>
+<p><strong>Compaction Table Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the compaction tables in all the functions.
+Percentage is relative to File Size.  Note that this value is also included in
+the Function Bytes.</div></blockquote>
+<p><strong>Symbol Table Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the symbol tables in all the functions.  Percentage is
+relative to File Size.  Note that this value is also included in the Function
+Bytes.</div></blockquote>
+<p><strong>Dependent Libraries Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the list of dependent libraries in the module.  Percentage
+is relative to File Size.  Note that this value is also included in the Module
+Global Bytes.</div></blockquote>
+<p><strong>Number Of Bitcode Blocks</strong></p>
+<blockquote>
+<div>The total number of blocks of any kind in the bitcode file.</div></blockquote>
+<p><strong>Number Of Functions</strong></p>
+<blockquote>
+<div>The total number of function definitions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Types</strong></p>
+<blockquote>
+<div>The total number of types defined in the Global Types Pool.</div></blockquote>
+<p><strong>Number Of Constants</strong></p>
+<blockquote>
+<div>The total number of constants (of any type) defined in the Constant Pool.</div></blockquote>
+<p><strong>Number Of Basic Blocks</strong></p>
+<blockquote>
+<div>The total number of basic blocks defined in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Instructions</strong></p>
+<blockquote>
+<div>The total number of instructions defined in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Long Instructions</strong></p>
+<blockquote>
+<div>The total number of long instructions defined in all functions in the bitcode
+file.  Long instructions are those taking greater than 4 bytes.  Typically long
+instructions are GetElementPtr with several indices, PHI nodes, and calls to
+functions with large numbers of arguments.</div></blockquote>
+<p><strong>Number Of Operands</strong></p>
+<blockquote>
+<div>The total number of operands used in all instructions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Compaction Tables</strong></p>
+<blockquote>
+<div>The total number of compaction tables in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Symbol Tables</strong></p>
+<blockquote>
+<div>The total number of symbol tables in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Dependent Libs</strong></p>
+<blockquote>
+<div>The total number of dependent libraries found in the bitcode file.</div></blockquote>
+<p><strong>Total Instruction Size</strong></p>
+<blockquote>
+<div>The total size of the instructions in all functions in the bitcode file.</div></blockquote>
+<p><strong>Average Instruction Size</strong></p>
+<blockquote>
+<div>The average number of bytes per instruction across all functions in the bitcode
+file.  This value is computed by dividing Total Instruction Size by Number Of
+Instructions.</div></blockquote>
+<p><strong>Maximum Type Slot Number</strong></p>
+<blockquote>
+<div>The maximum value used for a type’s slot number.  Larger slot number values take
+more bytes to encode.</div></blockquote>
+<p><strong>Maximum Value Slot Number</strong></p>
+<blockquote>
+<div>The maximum value used for a value’s slot number.  Larger slot number values take
+more bytes to encode.</div></blockquote>
+<p><strong>Bytes Per Value</strong></p>
+<blockquote>
+<div>The average size of a Value definition (of any type).  This is computed by
+dividing File Size by the total number of values of any type.</div></blockquote>
+<p><strong>Bytes Per Global</strong></p>
+<blockquote>
+<div>The average size of a global definition (constants and global variables).</div></blockquote>
+<p><strong>Bytes Per Function</strong></p>
+<blockquote>
+<div>The average number of bytes per function definition.  This is computed by
+dividing Function Bytes by Number Of Functions.</div></blockquote>
+<p><strong># of VBR 32-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 32-bit integers encoded using the Variable Bit Rate
+encoding scheme.</div></blockquote>
+<p><strong># of VBR 64-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 64-bit integers encoded using the Variable Bit Rate encoding
+scheme.</div></blockquote>
+<p><strong># of VBR Compressed Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes consumed by the 32-bit and 64-bit integers that use
+the Variable Bit Rate encoding scheme.</div></blockquote>
+<p><strong># of VBR Expanded Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes that would have been consumed by the 32-bit and 64-bit
+integers had they not been compressed with the Variable Bit Rage encoding
+scheme.</div></blockquote>
+<p><strong>Bytes Saved With VBR</strong></p>
+<blockquote>
+<div>The total number of bytes saved by using the Variable Bit Rate encoding scheme.
+The percentage is relative to # of VBR Expanded Bytes.</div></blockquote>
+</div>
+<div class="section" id="detailed-output-definitions">
+<h2>DETAILED OUTPUT DEFINITIONS<a class="headerlink" href="#detailed-output-definitions" title="Permalink to this headline">¶</a></h2>
+<p>The following definitions occur only if the -nodetails option was not given.
+The detailed output provides additional information on a per-function basis.</p>
+<p><strong>Type</strong></p>
+<blockquote>
+<div>The type signature of the function.</div></blockquote>
+<p><strong>Byte Size</strong></p>
+<blockquote>
+<div>The total number of bytes in the function’s block.</div></blockquote>
+<p><strong>Basic Blocks</strong></p>
+<blockquote>
+<div>The number of basic blocks defined by the function.</div></blockquote>
+<p><strong>Instructions</strong></p>
+<blockquote>
+<div>The number of instructions defined by the function.</div></blockquote>
+<p><strong>Long Instructions</strong></p>
+<blockquote>
+<div>The number of instructions using the long instruction format in the function.</div></blockquote>
+<p><strong>Operands</strong></p>
+<blockquote>
+<div>The number of operands used by all instructions in the function.</div></blockquote>
+<p><strong>Instruction Size</strong></p>
+<blockquote>
+<div>The number of bytes consumed by instructions in the function.</div></blockquote>
+<p><strong>Average Instruction Size</strong></p>
+<blockquote>
+<div>The average number of bytes consumed by the instructions in the function.
+This value is computed by dividing Instruction Size by Instructions.</div></blockquote>
+<p><strong>Bytes Per Instruction</strong></p>
+<blockquote>
+<div>The average number of bytes used by the function per instruction.  This value
+is computed by dividing Byte Size by Instructions.  Note that this is not the
+same as Average Instruction Size.  It computes a number relative to the total
+function size not just the size of the instruction list.</div></blockquote>
+<p><strong>Number of VBR 32-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 32-bit integers found in this function (for any use).</div></blockquote>
+<p><strong>Number of VBR 64-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 64-bit integers found in this function (for any use).</div></blockquote>
+<p><strong>Number of VBR Compressed Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes in this function consumed by the 32-bit and 64-bit
+integers that use the Variable Bit Rate encoding scheme.</div></blockquote>
+<p><strong>Number of VBR Expanded Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes in this function that would have been consumed by
+the 32-bit and 64-bit integers had they not been compressed with the Variable
+Bit Rate encoding scheme.</div></blockquote>
+<p><strong>Bytes Saved With VBR</strong></p>
+<blockquote>
+<div>The total number of bytes saved in this function by using the Variable Bit
+Rate encoding scheme.  The percentage is relative to # of VBR Expanded Bytes.</div></blockquote>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p><a class="reference internal" href="llvm-dis.html"><em>llvm-dis - LLVM disassembler</em></a>, <a class="reference internal" href="../BitCodeFormat.html"><em>LLVM Bitcode File Format</em></a></p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="FileCheck.html" title="FileCheck - Flexible pattern matching file verifier"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/llvm-build.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/llvm-build.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/llvm-build.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/llvm-build.html Wed May  7 15:09:32 2014
@@ -0,0 +1,165 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>llvm-build - LLVM Project Build Utility — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="llvm-readobj - LLVM Object Reader" href="llvm-readobj.html" />
+    <link rel="prev" title="lit - LLVM Integrated Tester" href="lit.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-readobj.html" title="llvm-readobj - LLVM Object Reader"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="lit.html" title="lit - LLVM Integrated Tester"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="llvm-build-llvm-project-build-utility">
+<h1>llvm-build - LLVM Project Build Utility<a class="headerlink" href="#llvm-build-llvm-project-build-utility" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-build</strong> [<em>options</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-build</strong> is a tool for working with LLVM projects that use the LLVMBuild
+system for describing their components.</p>
+<p>At heart, <strong>llvm-build</strong> is responsible for loading, verifying, and manipulating
+the project’s component data. The tool is primarily designed for use in
+implementing build systems and tools which need access to the project structure
+information.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-h</strong>, <strong>–help</strong></p>
+<blockquote>
+<div>Print the builtin program help.</div></blockquote>
+<p><strong>–source-root</strong>=<em>PATH</em></p>
+<blockquote>
+<div>If given, load the project at the given source root path. If this option is not
+given, the location of the project sources will be inferred from the location of
+the <strong>llvm-build</strong> script itself.</div></blockquote>
+<p><strong>–print-tree</strong></p>
+<blockquote>
+<div>Print the component tree for the project.</div></blockquote>
+<p><strong>–write-library-table</strong></p>
+<blockquote>
+<div>Write out the C++ fragment which defines the components, library names, and
+required libraries. This C++ fragment is built into llvm-config|llvm-config
+in order to provide clients with the list of required libraries for arbitrary
+component combinations.</div></blockquote>
+<p><strong>–write-llvmbuild</strong></p>
+<blockquote>
+<div>Write out new <em>LLVMBuild.txt</em> files based on the loaded components. This is
+useful for auto-upgrading the schema of the files. <strong>llvm-build</strong> will try to a
+limited extent to preserve the comments which were written in the original
+source file, although at this time it only preserves block comments that precede
+the section names in the <em>LLVMBuild</em> files.</div></blockquote>
+<p><strong>–write-cmake-fragment</strong></p>
+<blockquote>
+<div>Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
+consumed by the CMake based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with CMake, see LLVM’s
+top-level CMakeLists.txt.</div></blockquote>
+<p><strong>–write-make-fragment</strong></p>
+<blockquote>
+<div>Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be
+consumed by a Make based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with the Makefiles, see
+LLVM’s Makefile.rules.</div></blockquote>
+<p><strong>–llvmbuild-source-root</strong>=<em>PATH</em></p>
+<blockquote>
+<div>If given, expect the <em>LLVMBuild</em> files for the project to be rooted at the
+given path, instead of inside the source tree itself. This option is primarily
+designed for use in conjunction with <strong>–write-llvmbuild</strong> to test changes to
+<em>LLVMBuild</em> schema.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-build</strong> exits with 0 if operation was successful. Otherwise, it will exist
+with a non-zero value.</p>
+</div>
+</div>
+
+
+          </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             >index</a></li>
+        <li class="right" >
+          <a href="llvm-readobj.html" title="llvm-readobj - LLVM Object Reader"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="lit.html" title="lit - LLVM Integrated Tester"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="../index.html">Documentation</a>»</li>
+
+          <li><a href="index.html" >LLVM Command Guide</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2013, LLVM Project.
+      Last updated on 2014-05-06.
+      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.4.1/docs/CommandGuide/llvm-config.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.4.1/docs/CommandGuide/llvm-config.html?rev=208244&view=auto
==============================================================================
--- www-releases/trunk/3.4.1/docs/CommandGuide/llvm-config.html (added)
+++ www-releases/trunk/3.4.1/docs/CommandGuide/llvm-config.html Wed May  7 15:09:32 2014
@@ -0,0 +1,197 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    
+    <title>llvm-config - Print LLVM compilation options — LLVM 3.4 documentation</title>
+    
+    <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '3.4',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="top" title="LLVM 3.4 documentation" href="../index.html" />
+    <link rel="up" title="LLVM Command Guide" href="index.html" />
+    <link rel="next" title="llvm-diff - LLVM structural ‘diff’" href="llvm-diff.html" />
+    <link rel="prev" title="llvm-prof - print execution profile of LLVM program" href="llvm-prof.html" />
+<style type="text/css">
+  table.right { float: right; margin-left: 20px; }
+  table.right td { border: 1px solid #ccc; }
+</style>
+
+  </head>
+  <body>
+<div class="logo">
+  <a href="../index.html">
+    <img src="../_static/logo.png"
+         alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+    <div class="related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="../genindex.html" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="llvm-diff.html" title="llvm-diff - LLVM structural ‘diff’"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a hre