[www-releases] r280493 - Add 3.9.0 source, docs and binaries
Hans Wennborg via llvm-commits
llvm-commits at lists.llvm.org
Fri Sep 2 08:56:56 PDT 2016
Author: hans
Date: Fri Sep 2 10:56:46 2016
New Revision: 280493
URL: http://llvm.org/viewvc/llvm-project?rev=280493&view=rev
Log:
Add 3.9.0 source, docs and binaries
Added:
www-releases/trunk/3.9.0/
www-releases/trunk/3.9.0/LICENSE.TXT
www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe (with props)
www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe.sig (with props)
www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe (with props)
www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe.sig (with props)
www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-amd64-unknown-freebsd10.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-amd64-unknown-freebsd10.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-i386-unknown-freebsd10.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-i386-unknown-freebsd10.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-i586-opensuse13.2.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-i586-opensuse13.2.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-i686-fedora23.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-i686-fedora23.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-apple-darwin.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-apple-darwin.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-fedora23.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-fedora23.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-opensuse13.2.tar.xz (with props)
www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-opensuse13.2.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/clang-tools-extra_doxygen-3.9.0.tar.xz (with props)
www-releases/trunk/3.9.0/clang_doxygen-3.9.0.tar.xz (with props)
www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/docs/
www-releases/trunk/3.9.0/docs/.buildinfo
www-releases/trunk/3.9.0/docs/AMDGPUUsage.html
www-releases/trunk/3.9.0/docs/AdvancedBuilds.html
www-releases/trunk/3.9.0/docs/AliasAnalysis.html
www-releases/trunk/3.9.0/docs/Atomics.html
www-releases/trunk/3.9.0/docs/BigEndianNEON.html
www-releases/trunk/3.9.0/docs/BitCodeFormat.html
www-releases/trunk/3.9.0/docs/BlockFrequencyTerminology.html
www-releases/trunk/3.9.0/docs/BranchWeightMetadata.html
www-releases/trunk/3.9.0/docs/Bugpoint.html
www-releases/trunk/3.9.0/docs/CMake.html
www-releases/trunk/3.9.0/docs/CMakePrimer.html
www-releases/trunk/3.9.0/docs/CodeGenerator.html
www-releases/trunk/3.9.0/docs/CodeOfConduct.html
www-releases/trunk/3.9.0/docs/CodingStandards.html
www-releases/trunk/3.9.0/docs/CommandGuide/
www-releases/trunk/3.9.0/docs/CommandGuide/FileCheck.html
www-releases/trunk/3.9.0/docs/CommandGuide/bugpoint.html
www-releases/trunk/3.9.0/docs/CommandGuide/index.html
www-releases/trunk/3.9.0/docs/CommandGuide/lit.html
www-releases/trunk/3.9.0/docs/CommandGuide/llc.html
www-releases/trunk/3.9.0/docs/CommandGuide/lli.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-ar.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-as.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-bcanalyzer.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-build.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-config.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-cov.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-diff.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-dis.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-dwarfdump.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-extract.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-lib.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-link.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-nm.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-profdata.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-readobj.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-stress.html
www-releases/trunk/3.9.0/docs/CommandGuide/llvm-symbolizer.html
www-releases/trunk/3.9.0/docs/CommandGuide/opt.html
www-releases/trunk/3.9.0/docs/CommandGuide/tblgen.html
www-releases/trunk/3.9.0/docs/CommandLine.html
www-releases/trunk/3.9.0/docs/CompileCudaWithLLVM.html
www-releases/trunk/3.9.0/docs/CompilerWriterInfo.html
www-releases/trunk/3.9.0/docs/CoverageMappingFormat.html
www-releases/trunk/3.9.0/docs/DebuggingJITedCode.html
www-releases/trunk/3.9.0/docs/DeveloperPolicy.html
www-releases/trunk/3.9.0/docs/ExceptionHandling.html
www-releases/trunk/3.9.0/docs/ExtendingLLVM.html
www-releases/trunk/3.9.0/docs/Extensions.html
www-releases/trunk/3.9.0/docs/FAQ.html
www-releases/trunk/3.9.0/docs/FaultMaps.html
www-releases/trunk/3.9.0/docs/Frontend/
www-releases/trunk/3.9.0/docs/Frontend/PerformanceTips.html
www-releases/trunk/3.9.0/docs/GarbageCollection.html
www-releases/trunk/3.9.0/docs/GetElementPtr.html
www-releases/trunk/3.9.0/docs/GettingStarted.html
www-releases/trunk/3.9.0/docs/GettingStartedVS.html
www-releases/trunk/3.9.0/docs/GoldPlugin.html
www-releases/trunk/3.9.0/docs/HowToAddABuilder.html
www-releases/trunk/3.9.0/docs/HowToBuildOnARM.html
www-releases/trunk/3.9.0/docs/HowToCrossCompileLLVM.html
www-releases/trunk/3.9.0/docs/HowToReleaseLLVM.html
www-releases/trunk/3.9.0/docs/HowToSetUpLLVMStyleRTTI.html
www-releases/trunk/3.9.0/docs/HowToSubmitABug.html
www-releases/trunk/3.9.0/docs/HowToUseAttributes.html
www-releases/trunk/3.9.0/docs/HowToUseInstrMappings.html
www-releases/trunk/3.9.0/docs/InAlloca.html
www-releases/trunk/3.9.0/docs/LLVMBuild.html
www-releases/trunk/3.9.0/docs/LangRef.html
www-releases/trunk/3.9.0/docs/Lexicon.html
www-releases/trunk/3.9.0/docs/LibFuzzer.html
www-releases/trunk/3.9.0/docs/LinkTimeOptimization.html
www-releases/trunk/3.9.0/docs/MCJITDesignAndImplementation.html
www-releases/trunk/3.9.0/docs/MIRLangRef.html
www-releases/trunk/3.9.0/docs/MarkedUpDisassembly.html
www-releases/trunk/3.9.0/docs/MergeFunctions.html
www-releases/trunk/3.9.0/docs/NVPTXUsage.html
www-releases/trunk/3.9.0/docs/Packaging.html
www-releases/trunk/3.9.0/docs/Passes.html
www-releases/trunk/3.9.0/docs/Phabricator.html
www-releases/trunk/3.9.0/docs/ProgrammersManual.html
www-releases/trunk/3.9.0/docs/Projects.html
www-releases/trunk/3.9.0/docs/ReleaseNotes.html
www-releases/trunk/3.9.0/docs/ReleaseProcess.html
www-releases/trunk/3.9.0/docs/ReportingGuide.html
www-releases/trunk/3.9.0/docs/ScudoHardenedAllocator.html
www-releases/trunk/3.9.0/docs/SegmentedStacks.html
www-releases/trunk/3.9.0/docs/SourceLevelDebugging.html
www-releases/trunk/3.9.0/docs/SphinxQuickstartTemplate.html
www-releases/trunk/3.9.0/docs/StackMaps.html
www-releases/trunk/3.9.0/docs/Statepoints.html
www-releases/trunk/3.9.0/docs/SystemLibrary.html
www-releases/trunk/3.9.0/docs/TableGen/
www-releases/trunk/3.9.0/docs/TableGen/BackEnds.html
www-releases/trunk/3.9.0/docs/TableGen/Deficiencies.html
www-releases/trunk/3.9.0/docs/TableGen/LangIntro.html
www-releases/trunk/3.9.0/docs/TableGen/LangRef.html
www-releases/trunk/3.9.0/docs/TableGen/index.html
www-releases/trunk/3.9.0/docs/TableGenFundamentals.html
www-releases/trunk/3.9.0/docs/TestSuiteMakefileGuide.html
www-releases/trunk/3.9.0/docs/TestingGuide.html
www-releases/trunk/3.9.0/docs/TypeMetadata.html
www-releases/trunk/3.9.0/docs/Vectorizers.html
www-releases/trunk/3.9.0/docs/WritingAnLLVMBackend.html
www-releases/trunk/3.9.0/docs/WritingAnLLVMPass.html
www-releases/trunk/3.9.0/docs/YamlIO.html
www-releases/trunk/3.9.0/docs/_images/
www-releases/trunk/3.9.0/docs/_images/ARM-BE-bitcastfail.png (with props)
www-releases/trunk/3.9.0/docs/_images/ARM-BE-bitcastsuccess.png (with props)
www-releases/trunk/3.9.0/docs/_images/ARM-BE-ld1.png (with props)
www-releases/trunk/3.9.0/docs/_images/ARM-BE-ldr.png (with props)
www-releases/trunk/3.9.0/docs/_images/LangImpl05-cfg.png (with props)
www-releases/trunk/3.9.0/docs/_images/MCJIT-creation.png (with props)
www-releases/trunk/3.9.0/docs/_images/MCJIT-dyld-load.png (with props)
www-releases/trunk/3.9.0/docs/_images/MCJIT-engine-builder.png (with props)
www-releases/trunk/3.9.0/docs/_images/MCJIT-load-object.png (with props)
www-releases/trunk/3.9.0/docs/_images/MCJIT-load.png (with props)
www-releases/trunk/3.9.0/docs/_images/MCJIT-resolve-relocations.png (with props)
www-releases/trunk/3.9.0/docs/_images/gcc-loops.png (with props)
www-releases/trunk/3.9.0/docs/_images/linpack-pc.png (with props)
www-releases/trunk/3.9.0/docs/_sources/
www-releases/trunk/3.9.0/docs/_sources/AMDGPUUsage.txt
www-releases/trunk/3.9.0/docs/_sources/AdvancedBuilds.txt
www-releases/trunk/3.9.0/docs/_sources/AliasAnalysis.txt
www-releases/trunk/3.9.0/docs/_sources/Atomics.txt
www-releases/trunk/3.9.0/docs/_sources/BigEndianNEON.txt
www-releases/trunk/3.9.0/docs/_sources/BitCodeFormat.txt
www-releases/trunk/3.9.0/docs/_sources/BlockFrequencyTerminology.txt
www-releases/trunk/3.9.0/docs/_sources/BranchWeightMetadata.txt
www-releases/trunk/3.9.0/docs/_sources/Bugpoint.txt
www-releases/trunk/3.9.0/docs/_sources/CMake.txt
www-releases/trunk/3.9.0/docs/_sources/CMakePrimer.txt
www-releases/trunk/3.9.0/docs/_sources/CodeGenerator.txt
www-releases/trunk/3.9.0/docs/_sources/CodeOfConduct.txt
www-releases/trunk/3.9.0/docs/_sources/CodingStandards.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/FileCheck.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/bugpoint.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/index.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/lit.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llc.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/lli.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-ar.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-as.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-bcanalyzer.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-build.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-config.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-cov.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-diff.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-dis.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-dwarfdump.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-extract.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-lib.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-link.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-nm.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-profdata.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-readobj.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-stress.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/llvm-symbolizer.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/opt.txt
www-releases/trunk/3.9.0/docs/_sources/CommandGuide/tblgen.txt
www-releases/trunk/3.9.0/docs/_sources/CommandLine.txt
www-releases/trunk/3.9.0/docs/_sources/CompileCudaWithLLVM.txt
www-releases/trunk/3.9.0/docs/_sources/CompilerWriterInfo.txt
www-releases/trunk/3.9.0/docs/_sources/CoverageMappingFormat.txt
www-releases/trunk/3.9.0/docs/_sources/DebuggingJITedCode.txt
www-releases/trunk/3.9.0/docs/_sources/DeveloperPolicy.txt
www-releases/trunk/3.9.0/docs/_sources/ExceptionHandling.txt
www-releases/trunk/3.9.0/docs/_sources/ExtendingLLVM.txt
www-releases/trunk/3.9.0/docs/_sources/Extensions.txt
www-releases/trunk/3.9.0/docs/_sources/FAQ.txt
www-releases/trunk/3.9.0/docs/_sources/FaultMaps.txt
www-releases/trunk/3.9.0/docs/_sources/Frontend/
www-releases/trunk/3.9.0/docs/_sources/Frontend/PerformanceTips.txt
www-releases/trunk/3.9.0/docs/_sources/GarbageCollection.txt
www-releases/trunk/3.9.0/docs/_sources/GetElementPtr.txt
www-releases/trunk/3.9.0/docs/_sources/GettingStarted.txt
www-releases/trunk/3.9.0/docs/_sources/GettingStartedVS.txt
www-releases/trunk/3.9.0/docs/_sources/GoldPlugin.txt
www-releases/trunk/3.9.0/docs/_sources/HowToAddABuilder.txt
www-releases/trunk/3.9.0/docs/_sources/HowToBuildOnARM.txt
www-releases/trunk/3.9.0/docs/_sources/HowToCrossCompileLLVM.txt
www-releases/trunk/3.9.0/docs/_sources/HowToReleaseLLVM.txt
www-releases/trunk/3.9.0/docs/_sources/HowToSetUpLLVMStyleRTTI.txt
www-releases/trunk/3.9.0/docs/_sources/HowToSubmitABug.txt
www-releases/trunk/3.9.0/docs/_sources/HowToUseAttributes.txt
www-releases/trunk/3.9.0/docs/_sources/HowToUseInstrMappings.txt
www-releases/trunk/3.9.0/docs/_sources/InAlloca.txt
www-releases/trunk/3.9.0/docs/_sources/LLVMBuild.txt
www-releases/trunk/3.9.0/docs/_sources/LangRef.txt
www-releases/trunk/3.9.0/docs/_sources/Lexicon.txt
www-releases/trunk/3.9.0/docs/_sources/LibFuzzer.txt
www-releases/trunk/3.9.0/docs/_sources/LinkTimeOptimization.txt
www-releases/trunk/3.9.0/docs/_sources/MCJITDesignAndImplementation.txt
www-releases/trunk/3.9.0/docs/_sources/MIRLangRef.txt
www-releases/trunk/3.9.0/docs/_sources/MarkedUpDisassembly.txt
www-releases/trunk/3.9.0/docs/_sources/MergeFunctions.txt
www-releases/trunk/3.9.0/docs/_sources/NVPTXUsage.txt
www-releases/trunk/3.9.0/docs/_sources/Packaging.txt
www-releases/trunk/3.9.0/docs/_sources/Passes.txt
www-releases/trunk/3.9.0/docs/_sources/Phabricator.txt
www-releases/trunk/3.9.0/docs/_sources/ProgrammersManual.txt
www-releases/trunk/3.9.0/docs/_sources/Projects.txt
www-releases/trunk/3.9.0/docs/_sources/ReleaseNotes.txt
www-releases/trunk/3.9.0/docs/_sources/ReleaseProcess.txt
www-releases/trunk/3.9.0/docs/_sources/ReportingGuide.txt
www-releases/trunk/3.9.0/docs/_sources/ScudoHardenedAllocator.txt
www-releases/trunk/3.9.0/docs/_sources/SegmentedStacks.txt
www-releases/trunk/3.9.0/docs/_sources/SourceLevelDebugging.txt
www-releases/trunk/3.9.0/docs/_sources/SphinxQuickstartTemplate.txt
www-releases/trunk/3.9.0/docs/_sources/StackMaps.txt
www-releases/trunk/3.9.0/docs/_sources/Statepoints.txt
www-releases/trunk/3.9.0/docs/_sources/SystemLibrary.txt
www-releases/trunk/3.9.0/docs/_sources/TableGen/
www-releases/trunk/3.9.0/docs/_sources/TableGen/BackEnds.txt
www-releases/trunk/3.9.0/docs/_sources/TableGen/Deficiencies.txt
www-releases/trunk/3.9.0/docs/_sources/TableGen/LangIntro.txt
www-releases/trunk/3.9.0/docs/_sources/TableGen/LangRef.txt
www-releases/trunk/3.9.0/docs/_sources/TableGen/index.txt
www-releases/trunk/3.9.0/docs/_sources/TableGenFundamentals.txt
www-releases/trunk/3.9.0/docs/_sources/TestSuiteMakefileGuide.txt
www-releases/trunk/3.9.0/docs/_sources/TestingGuide.txt
www-releases/trunk/3.9.0/docs/_sources/TypeMetadata.txt
www-releases/trunk/3.9.0/docs/_sources/Vectorizers.txt
www-releases/trunk/3.9.0/docs/_sources/WritingAnLLVMBackend.txt
www-releases/trunk/3.9.0/docs/_sources/WritingAnLLVMPass.txt
www-releases/trunk/3.9.0/docs/_sources/YamlIO.txt
www-releases/trunk/3.9.0/docs/_sources/index.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/
www-releases/trunk/3.9.0/docs/_sources/tutorial/BuildingAJIT1.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/BuildingAJIT2.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/BuildingAJIT3.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/BuildingAJIT4.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/BuildingAJIT5.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl01.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl02.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl03.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl04.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl05.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl06.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl07.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl08.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl09.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/LangImpl10.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl1.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl2.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl3.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl4.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl5.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl6.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl7.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/OCamlLangImpl8.txt
www-releases/trunk/3.9.0/docs/_sources/tutorial/index.txt
www-releases/trunk/3.9.0/docs/_sources/yaml2obj.txt
www-releases/trunk/3.9.0/docs/_static/
www-releases/trunk/3.9.0/docs/_static/ajax-loader.gif (with props)
www-releases/trunk/3.9.0/docs/_static/basic.css
www-releases/trunk/3.9.0/docs/_static/comment-bright.png (with props)
www-releases/trunk/3.9.0/docs/_static/comment-close.png (with props)
www-releases/trunk/3.9.0/docs/_static/comment.png (with props)
www-releases/trunk/3.9.0/docs/_static/contents.png (with props)
www-releases/trunk/3.9.0/docs/_static/doctools.js
www-releases/trunk/3.9.0/docs/_static/down-pressed.png (with props)
www-releases/trunk/3.9.0/docs/_static/down.png (with props)
www-releases/trunk/3.9.0/docs/_static/file.png (with props)
www-releases/trunk/3.9.0/docs/_static/jquery.js
www-releases/trunk/3.9.0/docs/_static/lines.gif (with props)
www-releases/trunk/3.9.0/docs/_static/llvm-theme.css
www-releases/trunk/3.9.0/docs/_static/llvm.css
www-releases/trunk/3.9.0/docs/_static/logo.png (with props)
www-releases/trunk/3.9.0/docs/_static/minus.png (with props)
www-releases/trunk/3.9.0/docs/_static/navigation.png (with props)
www-releases/trunk/3.9.0/docs/_static/plus.png (with props)
www-releases/trunk/3.9.0/docs/_static/pygments.css
www-releases/trunk/3.9.0/docs/_static/searchtools.js
www-releases/trunk/3.9.0/docs/_static/underscore.js
www-releases/trunk/3.9.0/docs/_static/up-pressed.png (with props)
www-releases/trunk/3.9.0/docs/_static/up.png (with props)
www-releases/trunk/3.9.0/docs/_static/websupport.js
www-releases/trunk/3.9.0/docs/genindex.html
www-releases/trunk/3.9.0/docs/index.html
www-releases/trunk/3.9.0/docs/objects.inv (with props)
www-releases/trunk/3.9.0/docs/search.html
www-releases/trunk/3.9.0/docs/searchindex.js
www-releases/trunk/3.9.0/docs/tutorial/
www-releases/trunk/3.9.0/docs/tutorial/BuildingAJIT1.html
www-releases/trunk/3.9.0/docs/tutorial/BuildingAJIT2.html
www-releases/trunk/3.9.0/docs/tutorial/BuildingAJIT3.html
www-releases/trunk/3.9.0/docs/tutorial/BuildingAJIT4.html
www-releases/trunk/3.9.0/docs/tutorial/BuildingAJIT5.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl01.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl02.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl03.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl04.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl05.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl06.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl07.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl08.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl09.html
www-releases/trunk/3.9.0/docs/tutorial/LangImpl10.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl1.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl2.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl3.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl4.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl5.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl6.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl7.html
www-releases/trunk/3.9.0/docs/tutorial/OCamlLangImpl8.html
www-releases/trunk/3.9.0/docs/tutorial/index.html
www-releases/trunk/3.9.0/docs/yaml2obj.html
www-releases/trunk/3.9.0/libcxx-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/libcxx-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/libcxxabi-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/libcxxabi-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/libunwind-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/libunwind-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/lld-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/lld-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/lldb-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/lldb-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/llvm-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/llvm-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/llvm_doxygen-3.9.0.tar.xz (with props)
www-releases/trunk/3.9.0/openmp-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/openmp-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/polly-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/polly-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/projects/
www-releases/trunk/3.9.0/projects/libcxx/
www-releases/trunk/3.9.0/projects/libcxx/docs/
www-releases/trunk/3.9.0/projects/libcxx/docs/.buildinfo
www-releases/trunk/3.9.0/projects/libcxx/docs/BuildingLibcxx.html
www-releases/trunk/3.9.0/projects/libcxx/docs/DesignDocs/
www-releases/trunk/3.9.0/projects/libcxx/docs/DesignDocs/ABIVersioning.html
www-releases/trunk/3.9.0/projects/libcxx/docs/DesignDocs/CapturingConfigInfo.html
www-releases/trunk/3.9.0/projects/libcxx/docs/TestingLibcxx.html
www-releases/trunk/3.9.0/projects/libcxx/docs/UsingLibcxx.html
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/BuildingLibcxx.txt
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/DesignDocs/
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/DesignDocs/ABIVersioning.txt
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/DesignDocs/CapturingConfigInfo.txt
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/TestingLibcxx.txt
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/UsingLibcxx.txt
www-releases/trunk/3.9.0/projects/libcxx/docs/_sources/index.txt
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/ajax-loader.gif (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/alert_info_32.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/alert_warning_32.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/basic.css
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/bg-page.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/bullet_orange.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/comment-bright.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/comment-close.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/comment.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/doctools.js
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/down-pressed.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/down.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/file.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/haiku.css
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/jquery.js
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/minus.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/plus.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/pygments.css
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/searchtools.js
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/underscore.js
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/up-pressed.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/up.png (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/_static/websupport.js
www-releases/trunk/3.9.0/projects/libcxx/docs/genindex.html
www-releases/trunk/3.9.0/projects/libcxx/docs/index.html
www-releases/trunk/3.9.0/projects/libcxx/docs/objects.inv (with props)
www-releases/trunk/3.9.0/projects/libcxx/docs/search.html
www-releases/trunk/3.9.0/projects/libcxx/docs/searchindex.js
www-releases/trunk/3.9.0/test-suite-3.9.0.src.tar.xz (with props)
www-releases/trunk/3.9.0/test-suite-3.9.0.src.tar.xz.sig (with props)
www-releases/trunk/3.9.0/tools/
www-releases/trunk/3.9.0/tools/clang/
www-releases/trunk/3.9.0/tools/clang/docs/
www-releases/trunk/3.9.0/tools/clang/docs/.buildinfo
www-releases/trunk/3.9.0/tools/clang/docs/AddressSanitizer.html
www-releases/trunk/3.9.0/tools/clang/docs/AttributeReference.html
www-releases/trunk/3.9.0/tools/clang/docs/AutomaticReferenceCounting.html
www-releases/trunk/3.9.0/tools/clang/docs/Block-ABI-Apple.html
www-releases/trunk/3.9.0/tools/clang/docs/BlockLanguageSpec.html
www-releases/trunk/3.9.0/tools/clang/docs/ClangCheck.html
www-releases/trunk/3.9.0/tools/clang/docs/ClangFormat.html
www-releases/trunk/3.9.0/tools/clang/docs/ClangFormatStyleOptions.html
www-releases/trunk/3.9.0/tools/clang/docs/ClangPlugins.html
www-releases/trunk/3.9.0/tools/clang/docs/ClangTools.html
www-releases/trunk/3.9.0/tools/clang/docs/CommandGuide/
www-releases/trunk/3.9.0/tools/clang/docs/CommandGuide/clang.html
www-releases/trunk/3.9.0/tools/clang/docs/CommandGuide/index.html
www-releases/trunk/3.9.0/tools/clang/docs/ControlFlowIntegrity.html
www-releases/trunk/3.9.0/tools/clang/docs/ControlFlowIntegrityDesign.html
www-releases/trunk/3.9.0/tools/clang/docs/CrossCompilation.html
www-releases/trunk/3.9.0/tools/clang/docs/DataFlowSanitizer.html
www-releases/trunk/3.9.0/tools/clang/docs/DataFlowSanitizerDesign.html
www-releases/trunk/3.9.0/tools/clang/docs/DriverInternals.html
www-releases/trunk/3.9.0/tools/clang/docs/ExternalClangExamples.html
www-releases/trunk/3.9.0/tools/clang/docs/FAQ.html
www-releases/trunk/3.9.0/tools/clang/docs/HowToSetupToolingForLLVM.html
www-releases/trunk/3.9.0/tools/clang/docs/InternalsManual.html
www-releases/trunk/3.9.0/tools/clang/docs/IntroductionToTheClangAST.html
www-releases/trunk/3.9.0/tools/clang/docs/ItaniumMangleAbiTags.html
www-releases/trunk/3.9.0/tools/clang/docs/JSONCompilationDatabase.html
www-releases/trunk/3.9.0/tools/clang/docs/LTOVisibility.html
www-releases/trunk/3.9.0/tools/clang/docs/LanguageExtensions.html
www-releases/trunk/3.9.0/tools/clang/docs/LeakSanitizer.html
www-releases/trunk/3.9.0/tools/clang/docs/LibASTMatchers.html
www-releases/trunk/3.9.0/tools/clang/docs/LibASTMatchersReference.html
www-releases/trunk/3.9.0/tools/clang/docs/LibASTMatchersTutorial.html
www-releases/trunk/3.9.0/tools/clang/docs/LibFormat.html
www-releases/trunk/3.9.0/tools/clang/docs/LibTooling.html
www-releases/trunk/3.9.0/tools/clang/docs/MSVCCompatibility.html
www-releases/trunk/3.9.0/tools/clang/docs/MemorySanitizer.html
www-releases/trunk/3.9.0/tools/clang/docs/Modules.html
www-releases/trunk/3.9.0/tools/clang/docs/ObjectiveCLiterals.html
www-releases/trunk/3.9.0/tools/clang/docs/PCHInternals.html
www-releases/trunk/3.9.0/tools/clang/docs/PTHInternals.html
www-releases/trunk/3.9.0/tools/clang/docs/RAVFrontendAction.html
www-releases/trunk/3.9.0/tools/clang/docs/ReleaseNotes.html
www-releases/trunk/3.9.0/tools/clang/docs/SafeStack.html
www-releases/trunk/3.9.0/tools/clang/docs/SanitizerCoverage.html
www-releases/trunk/3.9.0/tools/clang/docs/SanitizerSpecialCaseList.html
www-releases/trunk/3.9.0/tools/clang/docs/SanitizerStats.html
www-releases/trunk/3.9.0/tools/clang/docs/SourceBasedCodeCoverage.html
www-releases/trunk/3.9.0/tools/clang/docs/ThreadSafetyAnalysis.html
www-releases/trunk/3.9.0/tools/clang/docs/ThreadSanitizer.html
www-releases/trunk/3.9.0/tools/clang/docs/Tooling.html
www-releases/trunk/3.9.0/tools/clang/docs/UndefinedBehaviorSanitizer.html
www-releases/trunk/3.9.0/tools/clang/docs/UsersManual.html
www-releases/trunk/3.9.0/tools/clang/docs/_images/
www-releases/trunk/3.9.0/tools/clang/docs/_images/DriverArchitecture.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_images/PCHLayout.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_sources/
www-releases/trunk/3.9.0/tools/clang/docs/_sources/AddressSanitizer.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/AttributeReference.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/AutomaticReferenceCounting.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/Block-ABI-Apple.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/BlockLanguageSpec.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ClangCheck.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ClangFormat.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ClangFormatStyleOptions.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ClangPlugins.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ClangTools.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/CommandGuide/
www-releases/trunk/3.9.0/tools/clang/docs/_sources/CommandGuide/clang.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/CommandGuide/index.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ControlFlowIntegrity.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ControlFlowIntegrityDesign.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/CrossCompilation.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/DataFlowSanitizer.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/DataFlowSanitizerDesign.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/DriverInternals.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ExternalClangExamples.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/FAQ.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/HowToSetupToolingForLLVM.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/InternalsManual.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/IntroductionToTheClangAST.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ItaniumMangleAbiTags.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/JSONCompilationDatabase.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/LTOVisibility.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/LanguageExtensions.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/LeakSanitizer.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/LibASTMatchers.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/LibASTMatchersTutorial.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/LibFormat.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/LibTooling.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/MSVCCompatibility.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/MemorySanitizer.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/Modules.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ObjectiveCLiterals.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/PCHInternals.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/PTHInternals.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/RAVFrontendAction.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ReleaseNotes.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/SafeStack.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/SanitizerCoverage.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/SanitizerSpecialCaseList.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/SanitizerStats.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/SourceBasedCodeCoverage.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ThreadSafetyAnalysis.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/ThreadSanitizer.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/Tooling.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/UndefinedBehaviorSanitizer.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/UsersManual.txt
www-releases/trunk/3.9.0/tools/clang/docs/_sources/index.txt
www-releases/trunk/3.9.0/tools/clang/docs/_static/
www-releases/trunk/3.9.0/tools/clang/docs/_static/ajax-loader.gif (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/alert_info_32.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/alert_warning_32.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/basic.css
www-releases/trunk/3.9.0/tools/clang/docs/_static/bg-page.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/bullet_orange.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/comment-bright.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/comment-close.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/comment.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/doctools.js
www-releases/trunk/3.9.0/tools/clang/docs/_static/down-pressed.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/down.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/file.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/haiku.css
www-releases/trunk/3.9.0/tools/clang/docs/_static/jquery.js
www-releases/trunk/3.9.0/tools/clang/docs/_static/minus.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/plus.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/pygments.css
www-releases/trunk/3.9.0/tools/clang/docs/_static/searchtools.js
www-releases/trunk/3.9.0/tools/clang/docs/_static/underscore.js
www-releases/trunk/3.9.0/tools/clang/docs/_static/up-pressed.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/up.png (with props)
www-releases/trunk/3.9.0/tools/clang/docs/_static/websupport.js
www-releases/trunk/3.9.0/tools/clang/docs/genindex.html
www-releases/trunk/3.9.0/tools/clang/docs/index.html
www-releases/trunk/3.9.0/tools/clang/docs/objects.inv (with props)
www-releases/trunk/3.9.0/tools/clang/docs/search.html
www-releases/trunk/3.9.0/tools/clang/docs/searchindex.js
www-releases/trunk/3.9.0/tools/clang/tools/
www-releases/trunk/3.9.0/tools/clang/tools/extra/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/.buildinfo
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/ModularizeUsage.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/ReleaseNotes.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/ModularizeUsage.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/ReleaseNotes.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-modernize.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-rename.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/boost-use-to-string.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-dcl03-c.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-dcl50-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-dcl54-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-dcl59-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-env33-c.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-err34-c.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-err52-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-err58-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-err60-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-err61-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-fio38-c.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-flp30-c.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cert-oop11-cpp.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-interfaces-global-init.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-type-const-cast.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-type-cstyle-cast.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-type-static-cast-downcast.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-type-union-access.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/cppcoreguidelines-pro-type-vararg.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-build-explicit-make-pair.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-build-namespaces.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-build-using-namespace.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-default-arguments.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-explicit-constructor.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-global-names-in-headers.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-readability-braces-around-statements.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-readability-casting.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-readability-function-size.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-readability-namespace-comments.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-readability-redundant-smartptr-get.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-readability-todo.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-runtime-int.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-runtime-member-string-references.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-runtime-memset.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-runtime-operator.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/google-runtime-references.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/list.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/llvm-header-guard.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/llvm-include-order.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/llvm-namespace-comment.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/llvm-twine-local.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-argument-comment.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-assert-side-effect.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-bool-pointer-implicit-conversion.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-dangling-handle.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-definitions-in-headers.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-fold-init-type.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-forward-declaration-namespace.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-inaccurate-erase.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-incorrect-roundings.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-inefficient-algorithm.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-macro-parentheses.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-macro-repeated-side-effects.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-misplaced-const.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-misplaced-widening-cast.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-move-const-arg.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-move-constructor-init.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-multiple-statement-macro.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-new-delete-overloads.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-noexcept-move-constructor.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-non-copyable-objects.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-pointer-and-integral-operation.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-redundant-expression.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-sizeof-container.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-sizeof-expression.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-static-assert.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-string-constructor.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-string-integer-assignment.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-string-literal-with-embedded-nul.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-suspicious-missing-comma.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-suspicious-semicolon.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-suspicious-string-compare.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-swapped-arguments.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-throw-by-value-catch-by-reference.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-unconventional-assign-operator.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-undelegated-constructor.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-uniqueptr-reset-release.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-unused-alias-decls.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-unused-parameters.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-unused-raii.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-unused-using-decls.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/misc-virtual-near-miss.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-avoid-bind.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-deprecated-headers.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-loop-convert.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-make-shared.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-make-unique.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-pass-by-value.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-raw-string-literal.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-redundant-void-arg.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-replace-auto-ptr.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-shrink-to-fit.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-use-auto.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-use-bool-literals.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-use-default.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-use-emplace.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-use-nullptr.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-use-override.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/modernize-use-using.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/performance-faster-string-find.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/performance-for-range-copy.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/performance-implicit-cast-in-loop.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/performance-unnecessary-copy-initialization.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/performance-unnecessary-value-param.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-avoid-const-params-in-decls.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-braces-around-statements.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-container-size-empty.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-deleted-default.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-else-after-return.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-function-size.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-identifier-naming.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-implicit-bool-cast.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-named-parameter.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-redundant-control-flow.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-redundant-smartptr-get.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-redundant-string-cstr.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-redundant-string-init.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-simplify-boolean-expr.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-static-definition-in-anonymous-namespace.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/checks/readability-uniqueptr-delete-release.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/clang-tidy/index.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/cpp11-migrate.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/include-fixer.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/index.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/modularize.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_sources/pp-trace.txt
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/ajax-loader.gif (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/alert_info_32.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/alert_warning_32.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/basic.css
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/bg-page.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/bullet_orange.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/comment-bright.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/comment-close.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/comment.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/doctools.js
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/down-pressed.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/down.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/file.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/haiku.css
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/jquery.js
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/minus.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/plus.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/pygments.css
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/searchtools.js
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/underscore.js
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/up-pressed.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/up.png (with props)
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/_static/websupport.js
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-modernize.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-rename.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/boost-use-to-string.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-dcl03-c.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-dcl50-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-dcl54-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-dcl59-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-env33-c.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-err34-c.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-err52-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-err58-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-err60-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-err61-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-fio38-c.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-flp30-c.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cert-oop11-cpp.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-interfaces-global-init.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-const-cast.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-cstyle-cast.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-static-cast-downcast.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-union-access.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-vararg.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-build-explicit-make-pair.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-build-namespaces.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-build-using-namespace.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-default-arguments.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-explicit-constructor.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-global-names-in-headers.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-readability-braces-around-statements.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-readability-casting.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-readability-function-size.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-readability-namespace-comments.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-readability-redundant-smartptr-get.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-readability-todo.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-runtime-int.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-runtime-member-string-references.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-runtime-memset.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-runtime-operator.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/google-runtime-references.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/list.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/llvm-header-guard.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/llvm-include-order.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/llvm-namespace-comment.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/llvm-twine-local.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-argument-comment.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-assert-side-effect.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-bool-pointer-implicit-conversion.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-dangling-handle.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-definitions-in-headers.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-fold-init-type.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-forward-declaration-namespace.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-inaccurate-erase.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-incorrect-roundings.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-inefficient-algorithm.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-macro-parentheses.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-macro-repeated-side-effects.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-misplaced-const.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-misplaced-widening-cast.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-move-const-arg.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-move-constructor-init.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-multiple-statement-macro.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-new-delete-overloads.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-noexcept-move-constructor.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-non-copyable-objects.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-pointer-and-integral-operation.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-redundant-expression.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-sizeof-container.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-sizeof-expression.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-static-assert.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-string-constructor.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-string-integer-assignment.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-string-literal-with-embedded-nul.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-suspicious-missing-comma.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-suspicious-semicolon.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-suspicious-string-compare.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-swapped-arguments.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-throw-by-value-catch-by-reference.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-unconventional-assign-operator.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-undelegated-constructor.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-uniqueptr-reset-release.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-unused-alias-decls.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-unused-parameters.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-unused-raii.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-unused-using-decls.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc-virtual-near-miss.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-avoid-bind.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-deprecated-headers.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-loop-convert.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-make-shared.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-make-unique.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-pass-by-value.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-raw-string-literal.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-redundant-void-arg.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-replace-auto-ptr.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-shrink-to-fit.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-auto.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-bool-literals.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-default.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-emplace.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-nullptr.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-override.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-using.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/performance-faster-string-find.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/performance-for-range-copy.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/performance-implicit-cast-in-loop.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/performance-unnecessary-copy-initialization.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/performance-unnecessary-value-param.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-avoid-const-params-in-decls.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-braces-around-statements.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-container-size-empty.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-deleted-default.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-else-after-return.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-function-size.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-identifier-naming.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-implicit-bool-cast.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-named-parameter.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-redundant-control-flow.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-redundant-smartptr-get.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-redundant-string-cstr.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-redundant-string-init.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-static-definition-in-anonymous-namespace.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-uniqueptr-delete-release.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/clang-tidy/index.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/cpp11-migrate.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/genindex.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/include-fixer.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/index.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/modularize.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/objects.inv
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/pp-trace.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/search.html
www-releases/trunk/3.9.0/tools/clang/tools/extra/docs/searchindex.js
www-releases/trunk/3.9.0/tools/lld/
www-releases/trunk/3.9.0/tools/lld/docs/
www-releases/trunk/3.9.0/tools/lld/docs/.buildinfo
www-releases/trunk/3.9.0/tools/lld/docs/AtomLLD.html
www-releases/trunk/3.9.0/tools/lld/docs/C++11.html
www-releases/trunk/3.9.0/tools/lld/docs/Driver.html
www-releases/trunk/3.9.0/tools/lld/docs/NewLLD.html
www-releases/trunk/3.9.0/tools/lld/docs/Readers.html
www-releases/trunk/3.9.0/tools/lld/docs/ReleaseNotes.html
www-releases/trunk/3.9.0/tools/lld/docs/_images/
www-releases/trunk/3.9.0/tools/lld/docs/_images/hello.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_sources/
www-releases/trunk/3.9.0/tools/lld/docs/_sources/AtomLLD.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/C++11.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/Driver.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/NewLLD.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/Readers.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/ReleaseNotes.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/design.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/development.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/getting_started.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/index.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/open_projects.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/sphinx_intro.txt
www-releases/trunk/3.9.0/tools/lld/docs/_sources/windows_support.txt
www-releases/trunk/3.9.0/tools/lld/docs/_static/
www-releases/trunk/3.9.0/tools/lld/docs/_static/ajax-loader.gif (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/basic.css
www-releases/trunk/3.9.0/tools/lld/docs/_static/comment-bright.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/comment-close.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/comment.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/contents.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/doctools.js
www-releases/trunk/3.9.0/tools/lld/docs/_static/down-pressed.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/down.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/favicon.ico (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/file.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/jquery.js
www-releases/trunk/3.9.0/tools/lld/docs/_static/llvm.css
www-releases/trunk/3.9.0/tools/lld/docs/_static/logo.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/minus.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/navigation.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/plus.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/pygments.css
www-releases/trunk/3.9.0/tools/lld/docs/_static/searchtools.js
www-releases/trunk/3.9.0/tools/lld/docs/_static/underscore.js
www-releases/trunk/3.9.0/tools/lld/docs/_static/up-pressed.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/up.png (with props)
www-releases/trunk/3.9.0/tools/lld/docs/_static/websupport.js
www-releases/trunk/3.9.0/tools/lld/docs/design.html
www-releases/trunk/3.9.0/tools/lld/docs/development.html
www-releases/trunk/3.9.0/tools/lld/docs/genindex.html
www-releases/trunk/3.9.0/tools/lld/docs/getting_started.html
www-releases/trunk/3.9.0/tools/lld/docs/index.html
www-releases/trunk/3.9.0/tools/lld/docs/objects.inv (with props)
www-releases/trunk/3.9.0/tools/lld/docs/open_projects.html
www-releases/trunk/3.9.0/tools/lld/docs/search.html
www-releases/trunk/3.9.0/tools/lld/docs/searchindex.js
www-releases/trunk/3.9.0/tools/lld/docs/sphinx_intro.html
www-releases/trunk/3.9.0/tools/lld/docs/windows_support.html
Modified:
www-releases/trunk/download.html
www-releases/trunk/index.html
Added: www-releases/trunk/3.9.0/LICENSE.TXT
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/LICENSE.TXT?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/LICENSE.TXT (added)
+++ www-releases/trunk/3.9.0/LICENSE.TXT Fri Sep 2 10:56:46 2016
@@ -0,0 +1,70 @@
+==============================================================================
+LLVM Release License
+==============================================================================
+University of Illinois/NCSA
+Open Source License
+
+Copyright (c) 2003-2016 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
+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.9.0/LLVM-3.9.0-win32.exe
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe
------------------------------------------------------------------------------
svn:executable = *
Propchange: www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/LLVM-3.9.0-win32.exe.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe
------------------------------------------------------------------------------
svn:executable = *
Propchange: www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/LLVM-3.9.0-win64.exe.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/cfe-3.9.0.src.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-aarch64-linux-gnu.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-aarch64-linux-gnu.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-amd64-unknown-freebsd10.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-amd64-unknown-freebsd10.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-amd64-unknown-freebsd10.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-amd64-unknown-freebsd10.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-amd64-unknown-freebsd10.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-amd64-unknown-freebsd10.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-armv7a-linux-gnueabihf.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-armv7a-linux-gnueabihf.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i386-unknown-freebsd10.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-i386-unknown-freebsd10.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i386-unknown-freebsd10.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i386-unknown-freebsd10.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-i386-unknown-freebsd10.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i386-unknown-freebsd10.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i586-opensuse13.2.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-i586-opensuse13.2.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i586-opensuse13.2.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i586-opensuse13.2.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-i586-opensuse13.2.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i586-opensuse13.2.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i686-fedora23.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-i686-fedora23.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i686-fedora23.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i686-fedora23.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-i686-fedora23.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-i686-fedora23.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-apple-darwin.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-apple-darwin.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-apple-darwin.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-apple-darwin.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-apple-darwin.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-apple-darwin.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-fedora23.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-fedora23.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-fedora23.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-fedora23.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-fedora23.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-fedora23.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-opensuse13.2.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-opensuse13.2.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-opensuse13.2.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-opensuse13.2.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang%2Bllvm-3.9.0-x86_64-opensuse13.2.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang+llvm-3.9.0-x86_64-opensuse13.2.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang-tools-extra-3.9.0.src.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang-tools-extra_doxygen-3.9.0.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang-tools-extra_doxygen-3.9.0.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang-tools-extra_doxygen-3.9.0.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/clang_doxygen-3.9.0.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/clang_doxygen-3.9.0.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/clang_doxygen-3.9.0.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz.sig
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz.sig?rev=280493&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/3.9.0/compiler-rt-3.9.0.src.tar.xz.sig
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: www-releases/trunk/3.9.0/docs/.buildinfo
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/.buildinfo?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/.buildinfo (added)
+++ www-releases/trunk/3.9.0/docs/.buildinfo Fri Sep 2 10:56:46 2016
@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 698eb3c511903e293bb5830c26472c2f
+tags: 645f666f9bcd5a90fca523b33c5a78b7
Added: www-releases/trunk/3.9.0/docs/AMDGPUUsage.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/AMDGPUUsage.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/AMDGPUUsage.html (added)
+++ www-releases/trunk/3.9.0/docs/AMDGPUUsage.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,299 @@
+
+<!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>User Guide for AMDGPU Back-end — LLVM 3.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="Stack maps and patch points in LLVM" href="StackMaps.html" />
+ <link rel="prev" title="User Guide for NVPTX Back-end" href="NVPTXUsage.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="StackMaps.html" title="Stack maps and patch points in LLVM"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="NVPTXUsage.html" title="User Guide for NVPTX Back-end"
+ 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="user-guide-for-amdgpu-back-end">
+<h1>User Guide for AMDGPU Back-end<a class="headerlink" href="#user-guide-for-amdgpu-back-end" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="introduction">
+<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>The AMDGPU back-end provides ISA code generation for AMD GPUs, starting with
+the R600 family up until the current Volcanic Islands (GCN Gen 3).</p>
+</div>
+<div class="section" id="conventions">
+<h2>Conventions<a class="headerlink" href="#conventions" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="address-spaces">
+<h3>Address Spaces<a class="headerlink" href="#address-spaces" title="Permalink to this headline">¶</a></h3>
+<p>The AMDGPU back-end uses the following address space mapping:</p>
+<blockquote>
+<div><table border="1" class="docutils">
+<colgroup>
+<col width="23%" />
+<col width="77%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Address Space</th>
+<th class="head">Memory Space</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0</td>
+<td>Private</td>
+</tr>
+<tr class="row-odd"><td>1</td>
+<td>Global</td>
+</tr>
+<tr class="row-even"><td>2</td>
+<td>Constant</td>
+</tr>
+<tr class="row-odd"><td>3</td>
+<td>Local</td>
+</tr>
+<tr class="row-even"><td>4</td>
+<td>Generic (Flat)</td>
+</tr>
+<tr class="row-odd"><td>5</td>
+<td>Region</td>
+</tr>
+</tbody>
+</table>
+</div></blockquote>
+<p>The terminology in the table, aside from the region memory space, is from the
+OpenCL standard.</p>
+</div>
+</div>
+<div class="section" id="assembler">
+<h2>Assembler<a class="headerlink" href="#assembler" title="Permalink to this headline">¶</a></h2>
+<p>The assembler is currently considered experimental.</p>
+<p>For syntax examples look in test/MC/AMDGPU.</p>
+<p>Below some of the currently supported features (modulo bugs). These
+all apply to the Southern Islands ISA, Sea Islands and Volcanic Islands
+are also supported but may be missing some instructions and have more bugs:</p>
+<div class="section" id="ds-instructions">
+<h3>DS Instructions<a class="headerlink" href="#ds-instructions" title="Permalink to this headline">¶</a></h3>
+<p>All DS instructions are supported.</p>
+</div>
+<div class="section" id="flat-instructions">
+<h3>FLAT Instructions<a class="headerlink" href="#flat-instructions" title="Permalink to this headline">¶</a></h3>
+<p>These instructions are only present in the Sea Islands and Volcanic Islands
+instruction set. All FLAT instructions are supported for these architectures</p>
+</div>
+<div class="section" id="mubuf-instructions">
+<h3>MUBUF Instructions<a class="headerlink" href="#mubuf-instructions" title="Permalink to this headline">¶</a></h3>
+<p>All non-atomic MUBUF instructions are supported.</p>
+</div>
+<div class="section" id="smrd-instructions">
+<h3>SMRD Instructions<a class="headerlink" href="#smrd-instructions" title="Permalink to this headline">¶</a></h3>
+<p>Only the s_load_dword* SMRD instructions are supported.</p>
+</div>
+<div class="section" id="sop1-instructions">
+<h3>SOP1 Instructions<a class="headerlink" href="#sop1-instructions" title="Permalink to this headline">¶</a></h3>
+<p>All SOP1 instructions are supported.</p>
+</div>
+<div class="section" id="sop2-instructions">
+<h3>SOP2 Instructions<a class="headerlink" href="#sop2-instructions" title="Permalink to this headline">¶</a></h3>
+<p>All SOP2 instructions are supported.</p>
+</div>
+<div class="section" id="sopc-instructions">
+<h3>SOPC Instructions<a class="headerlink" href="#sopc-instructions" title="Permalink to this headline">¶</a></h3>
+<p>All SOPC instructions are supported.</p>
+</div>
+<div class="section" id="sopp-instructions">
+<h3>SOPP Instructions<a class="headerlink" href="#sopp-instructions" title="Permalink to this headline">¶</a></h3>
+<p>Unless otherwise mentioned, all SOPP instructions that have one or more
+operands accept integer operands only. No verification is performed
+on the operands, so it is up to the programmer to be familiar with the
+range or acceptable values.</p>
+<div class="section" id="s-waitcnt">
+<h4>s_waitcnt<a class="headerlink" href="#s-waitcnt" title="Permalink to this headline">¶</a></h4>
+<p>s_waitcnt accepts named arguments to specify which memory counter(s) to
+wait for.</p>
+<div class="highlight-nasm"><div class="highlight"><pre><span class="c1">; Wait for all counters to be 0</span>
+<span class="nf">s_waitcnt</span> <span class="mi">0</span>
+
+<span class="c1">; Equivalent to s_waitcnt 0. Counter names can also be delimited by</span>
+<span class="c1">; '&' or ','.</span>
+<span class="nf">s_waitcnt</span> <span class="nv">vmcnt</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="nv">expcnt</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="nv">lgkcmt</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span>
+
+<span class="c1">; Wait for vmcnt counter to be 1.</span>
+<span class="nf">s_waitcnt</span> <span class="nv">vmcnt</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="vop1-vop2-vop3-vopc-instructions">
+<h3>VOP1, VOP2, VOP3, VOPC Instructions<a class="headerlink" href="#vop1-vop2-vop3-vopc-instructions" title="Permalink to this headline">¶</a></h3>
+<p>All 32-bit and 64-bit encodings should work.</p>
+<p>The assembler will automatically detect which encoding size to use for
+VOP1, VOP2, and VOPC instructions based on the operands. If you want to force
+a specific encoding size, you can add an _e32 (for 32-bit encoding) or
+_e64 (for 64-bit encoding) suffix to the instruction. Most, but not all
+instructions support an explicit suffix. These are all valid assembly
+strings:</p>
+<div class="highlight-nasm"><div class="highlight"><pre><span class="nf">v_mul_i32_i24</span> <span class="nv">v1</span><span class="p">,</span> <span class="nv">v2</span><span class="p">,</span> <span class="nv">v3</span>
+<span class="nf">v_mul_i32_i24_e32</span> <span class="nv">v1</span><span class="p">,</span> <span class="nv">v2</span><span class="p">,</span> <span class="nv">v3</span>
+<span class="nf">v_mul_i32_i24_e64</span> <span class="nv">v1</span><span class="p">,</span> <span class="nv">v2</span><span class="p">,</span> <span class="nv">v3</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="assembler-directives">
+<h3>Assembler Directives<a class="headerlink" href="#assembler-directives" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="hsa-code-object-version-major-minor">
+<h4>.hsa_code_object_version major, minor<a class="headerlink" href="#hsa-code-object-version-major-minor" title="Permalink to this headline">¶</a></h4>
+<p><em>major</em> and <em>minor</em> are integers that specify the version of the HSA code
+object that will be generated by the assembler. This value will be stored
+in an entry of the .note section.</p>
+</div>
+<div class="section" id="hsa-code-object-isa-major-minor-stepping-vendor-arch">
+<h4>.hsa_code_object_isa [major, minor, stepping, vendor, arch]<a class="headerlink" href="#hsa-code-object-isa-major-minor-stepping-vendor-arch" title="Permalink to this headline">¶</a></h4>
+<p><em>major</em>, <em>minor</em>, and <em>stepping</em> are all integers that describe the instruction
+set architecture (ISA) version of the assembly program.</p>
+<p><em>vendor</em> and <em>arch</em> are quoted strings. <em>vendor</em> should always be equal to
+“AMD” and <em>arch</em> should always be equal to “AMDGPU”.</p>
+<p>If no arguments are specified, then the assembler will derive the ISA version,
+<em>vendor</em>, and <em>arch</em> from the value of the -mcpu option that is passed to the
+assembler.</p>
+<p>ISA version, <em>vendor</em>, and <em>arch</em> will all be stored in a single entry of the
+.note section.</p>
+</div>
+<div class="section" id="amd-kernel-code-t">
+<h4>.amd_kernel_code_t<a class="headerlink" href="#amd-kernel-code-t" title="Permalink to this headline">¶</a></h4>
+<p>This directive marks the beginning of a list of key / value pairs that are used
+to specify the amd_kernel_code_t object that will be emitted by the assembler.
+The list must be terminated by the <em>.end_amd_kernel_code_t</em> directive. For
+any amd_kernel_code_t values that are unspecified a default value will be
+used. The default value for all keys is 0, with the following exceptions:</p>
+<ul class="simple">
+<li><em>kernel_code_version_major</em> defaults to 1.</li>
+<li><em>machine_kind</em> defaults to 1.</li>
+<li><em>machine_version_major</em>, <em>machine_version_minor</em>, and
+<em>machine_version_stepping</em> are derived from the value of the -mcpu option
+that is passed to the assembler.</li>
+<li><em>kernel_code_entry_byte_offset</em> defaults to 256.</li>
+<li><em>wavefront_size</em> defaults to 6.</li>
+<li><em>kernarg_segment_alignment</em>, <em>group_segment_alignment</em>, and
+<em>private_segment_alignment</em> default to 4. Note that alignments are specified
+as a power of two, so a value of <strong>n</strong> means an alignment of 2^ <strong>n</strong>.</li>
+</ul>
+<p>The <em>.amd_kernel_code_t</em> directive must be placed immediately after the
+function label and before any instructions.</p>
+<p>For a full list of amd_kernel_code_t keys, see the examples in
+test/CodeGen/AMDGPU/hsa.s. For an explanation of the meanings of the different
+keys, see the comments in lib/Target/AMDGPU/AmdKernelCodeT.h</p>
+<p>Here is an example of a minimal amd_kernel_code_t specification:</p>
+<div class="highlight-nasm"><div class="highlight"><pre>.hsa_code_object_version 1,0
+.hsa_code_object_isa
+
+.hsatext
+.globl hello_world
+.p2align 8
+.amdgpu_hsa_kernel hello_world
+
+hello_world:
+
+ .amd_kernel_code_t
+ enable_sgpr_kernarg_segment_ptr = 1
+ is_ptr64 = 1
+ compute_pgm_rsrc1_vgprs = 0
+ compute_pgm_rsrc1_sgprs = 0
+ compute_pgm_rsrc2_user_sgpr = 2
+ kernarg_segment_byte_size = 8
+ wavefront_sgpr_count = 2
+ workitem_vgpr_count = 3
+ .end_amd_kernel_code_t
+
+ s_load_dwordx2 s[0:1], s[0:1] 0x0
+ v_mov_b32 v0, 3.14159
+ s_waitcnt lgkmcnt(0)
+ v_mov_b32 v1, s0
+ v_mov_b32 v2, s1
+ flat_store_dword v[1:2], v0
+ s_endpgm
+.Lfunc_end0:
+ .size hello_world, .Lfunc_end0-hello_world
+</pre></div>
+</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="StackMaps.html" title="Stack maps and patch points in LLVM"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="NVPTXUsage.html" title="User Guide for NVPTX Back-end"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/AdvancedBuilds.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/AdvancedBuilds.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/AdvancedBuilds.html (added)
+++ www-releases/trunk/3.9.0/docs/AdvancedBuilds.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,239 @@
+
+<!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>Advanced Build Configurations — LLVM 3.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="How To Build On ARM" href="HowToBuildOnARM.html" />
+ <link rel="prev" title="CMake Primer" href="CMakePrimer.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="CMakePrimer.html" title="CMake Primer"
+ 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="advanced-build-configurations">
+<h1>Advanced Build Configurations<a class="headerlink" href="#advanced-build-configurations" 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="#bootstrap-builds" id="id2">Bootstrap Builds</a></li>
+<li><a class="reference internal" href="#apple-clang-builds-a-more-complex-bootstrap" id="id3">Apple Clang Builds (A More Complex Bootstrap)</a></li>
+<li><a class="reference internal" href="#multi-stage-pgo" id="id4">Multi-stage PGO</a></li>
+<li><a class="reference internal" href="#stage-non-determinism" id="id5">3-Stage Non-Determinism</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><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 <strong>you are a new contributor</strong>, please start with the <a class="reference internal" href="GettingStarted.html"><em>Getting Started with the LLVM System</em></a> or
+<a class="reference internal" href="CMake.html"><em>Building LLVM with CMake</em></a> pages. This page is intended for users doing more complex builds.</p>
+<p>Many of the examples below are written assuming specific CMake Generators.
+Unless otherwise explicitly called out these commands should work with any CMake
+generator.</p>
+</div>
+<div class="section" id="bootstrap-builds">
+<h2><a class="toc-backref" href="#id2">Bootstrap Builds</a><a class="headerlink" href="#bootstrap-builds" title="Permalink to this headline">¶</a></h2>
+<p>The Clang CMake build system supports bootstrap (aka multi-stage) builds. At a
+high level a multi-stage build is a chain of builds that pass data from one
+stage into the next. The most common and simple version of this is a traditional
+bootstrap build.</p>
+<p>In a simple two-stage bootstrap build, we build clang using the system compiler,
+then use that just-built clang to build clang again. In CMake this simplest form
+of a bootstrap build can be configured with a single option,
+CLANG_ENABLE_BOOTSTRAP.</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -G Ninja -DCLANG_ENABLE_BOOTSTRAP<span class="o">=</span>On <path to <span class="nb">source</span>>
+<span class="gp">$</span> ninja stage2
+</pre></div>
+</div>
+<p>This command itself isn’t terribly useful because it assumes default
+configurations for each stage. The next series of examples utilize CMake cache
+scripts to provide more complex options.</p>
+<p>The clang build system refers to builds as stages. A stage1 build is a standard
+build using the compiler installed on the host, and a stage2 build is built
+using the stage1 compiler. This nomenclature holds up to more stages too. In
+general a stage*n* build is built using the output from stage*n-1*.</p>
+</div>
+<div class="section" id="apple-clang-builds-a-more-complex-bootstrap">
+<h2><a class="toc-backref" href="#id3">Apple Clang Builds (A More Complex Bootstrap)</a><a class="headerlink" href="#apple-clang-builds-a-more-complex-bootstrap" title="Permalink to this headline">¶</a></h2>
+<p>Apple’s Clang builds are a slightly more complicated example of the simple
+bootstrapping scenario. Apple Clang is built using a 2-stage build.</p>
+<p>The stage1 compiler is a host-only compiler with some options set. The stage1
+compiler is a balance of optimization vs build time because it is a throwaway.
+The stage2 compiler is the fully optimized compiler intended to ship to users.</p>
+<p>Setting up these compilers requires a lot of options. To simplify the
+configuration the Apple Clang build settings are contained in CMake Cache files.
+You can build an Apple Clang compiler using the following commands:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -G Ninja -C <path to clang>/cmake/caches/Apple-stage1.cmake <path to <span class="nb">source</span>>
+<span class="gp">$</span> ninja stage2-distribution
+</pre></div>
+</div>
+<p>This CMake invocation configures the stage1 host compiler, and sets
+CLANG_BOOTSTRAP_CMAKE_ARGS to pass the Apple-stage2.cmake cache script to the
+stage2 configuration step.</p>
+<p>When you build the stage2-distribution target it builds the minimal stage1
+compiler and required tools, then configures and builds the stage2 compiler
+based on the settings in Apple-stage2.cmake.</p>
+<p>This pattern of using cache scripts to set complex settings, and specifically to
+make later stage builds include cache scripts is common in our more advanced
+build configurations.</p>
+</div>
+<div class="section" id="multi-stage-pgo">
+<h2><a class="toc-backref" href="#id4">Multi-stage PGO</a><a class="headerlink" href="#multi-stage-pgo" title="Permalink to this headline">¶</a></h2>
+<p>Profile-Guided Optimizations (PGO) is a really great way to optimize the code
+clang generates. Our multi-stage PGO builds are a workflow for generating PGO
+profiles that can be used to optimize clang.</p>
+<p>At a high level, the way PGO works is that you build an instrumented compiler,
+then you run the instrumented compiler against sample source files. While the
+instrumented compiler runs it will output a bunch of files containing
+performance counters (.profraw files). After generating all the profraw files
+you use llvm-profdata to merge the files into a single profdata file that you
+can feed into the LLVM_PROFDATA_FILE option.</p>
+<p>Our PGO.cmake cache script automates that whole process. You can use it by
+running:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -G Ninja -C <path_to_clang>/cmake/caches/PGO.cmake <<span class="nb">source </span>dir>
+<span class="gp">$</span> ninja stage2-instrumented-generate-profdata
+</pre></div>
+</div>
+<p>If you let that run for a few hours or so, it will place a profdata file in your
+build directory. This takes a really long time because it builds clang twice,
+and you <em>must</em> have compiler-rt in your build tree.</p>
+<p>This process uses any source files under the perf-training directory as training
+data as long as the source files are marked up with LIT-style RUN lines.</p>
+<p>After it finishes you can use âfind . -name clang.profdataâ to find it, but it
+should be at a path something like:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="go"><build dir>/tools/clang/stage2-instrumented-bins/utils/perf-training/clang.profdata</span>
+</pre></div>
+</div>
+<p>You can feed that file into the LLVM_PROFDATA_FILE option when you build your
+optimized compiler.</p>
+<p>The PGO came cache has a slightly different stage naming scheme than other
+multi-stage builds. It generates three stages; stage1, stage2-instrumented, and
+stage2. Both of the stage2 builds are built using the stage1 compiler.</p>
+<p>The PGO came cache generates the following additional targets:</p>
+<dl class="docutils">
+<dt><strong>stage2-instrumented</strong></dt>
+<dd>Builds a stage1 x86 compiler, runtime, and required tools (llvm-config,
+llvm-profdata) then uses that compiler to build an instrumented stage2 compiler.</dd>
+<dt><strong>stage2-instrumented-generate-profdata</strong></dt>
+<dd>Depends on “stage2-instrumented” and will use the instrumented compiler to
+generate profdata based on the training files in <clang>/utils/perf-training</dd>
+<dt><strong>stage2</strong></dt>
+<dd>Depends of “stage2-instrumented-generate-profdata” and will use the stage1
+compiler with the stage2 profdata to build a PGO-optimized compiler.</dd>
+<dt><strong>stage2-check-llvm</strong></dt>
+<dd>Depends on stage2 and runs check-llvm using the stage2 compiler.</dd>
+<dt><strong>stage2-check-clang</strong></dt>
+<dd>Depends on stage2 and runs check-clang using the stage2 compiler.</dd>
+<dt><strong>stage2-check-all</strong></dt>
+<dd>Depends on stage2 and runs check-all using the stage2 compiler.</dd>
+<dt><strong>stage2-test-suite</strong></dt>
+<dd>Depends on stage2 and runs the test-suite using the stage3 compiler (requires
+in-tree test-suite).</dd>
+</dl>
+</div>
+<div class="section" id="stage-non-determinism">
+<h2><a class="toc-backref" href="#id5">3-Stage Non-Determinism</a><a class="headerlink" href="#stage-non-determinism" title="Permalink to this headline">¶</a></h2>
+<p>In the ancient lore of compilers non-determinism is like the multi-headed hydra.
+Whenever it’s head pops up, terror and chaos ensue.</p>
+<p>Historically one of the tests to verify that a compiler was deterministic would
+be a three stage build. The idea of a three stage build is you take your sources
+and build a compiler (stage1), then use that compiler to rebuild the sources
+(stage2), then you use that compiler to rebuild the sources a third time
+(stage3) with an identical configuration to the stage2 build. At the end of
+this, you have a stage2 and stage3 compiler that should be bit-for-bit
+identical.</p>
+<p>You can perform one of these 3-stage builds with LLVM & clang using the
+following commands:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -G Ninja -C <path_to_clang>/cmake/caches/3-stage.cmake <<span class="nb">source </span>dir>
+<span class="gp">$</span> ninja stage3
+</pre></div>
+</div>
+<p>After the build you can compare the stage2 & stage3 compilers. We have a bot
+setup <a class="reference external" href="http://lab.llvm.org:8011/builders/clang-3stage-ubuntu">here</a> that runs
+this build and compare configuration.</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="HowToBuildOnARM.html" title="How To Build On ARM"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="CMakePrimer.html" title="CMake Primer"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/AliasAnalysis.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/AliasAnalysis.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/AliasAnalysis.html (added)
+++ www-releases/trunk/3.9.0/docs/AliasAnalysis.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,764 @@
+
+<!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.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="LLVM Bitcode File Format" href="BitCodeFormat.html" />
+ <link rel="prev" title="Scudo Hardened Allocator" href="ScudoHardenedAllocator.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="ScudoHardenedAllocator.html" title="Scudo Hardened Allocator"
+ 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="#required-methods-to-override" id="id13">Required methods to override</a></li>
+<li><a class="reference internal" href="#interfaces-which-may-be-specified" id="id14">Interfaces which may be specified</a></li>
+<li><a class="reference internal" href="#aliasanalysis-chaining-behavior" id="id15"><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="id16">Updating analysis results for transformations</a><ul>
+<li><a class="reference internal" href="#the-deletevalue-method" id="id17">The <tt class="docutils literal"><span class="pre">deleteValue</span></tt> method</a></li>
+<li><a class="reference internal" href="#the-copyvalue-method" id="id18">The <tt class="docutils literal"><span class="pre">copyValue</span></tt> method</a></li>
+<li><a class="reference internal" href="#the-replacewithnewvalue-method" id="id19">The <tt class="docutils literal"><span class="pre">replaceWithNewValue</span></tt> method</a></li>
+<li><a class="reference internal" href="#the-addescapinguse-method" id="id20">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="id21">Efficiency Issues</a></li>
+<li><a class="reference internal" href="#limitations" id="id22">Limitations</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#using-alias-analysis-results" id="id23">Using alias analysis results</a><ul>
+<li><a class="reference internal" href="#using-the-memorydependenceanalysis-pass" id="id24">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="id25">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="id26">The AliasSetTracker implementation</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#using-the-aliasanalysis-interface-directly" id="id27">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="id28">Existing alias analysis implementations and clients</a><ul>
+<li><a class="reference internal" href="#available-aliasanalysis-implementations" id="id29">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="id30">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="id31">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="id32">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="id33">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="id34">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="id35">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="id36">Alias analysis driven transformations</a><ul>
+<li><a class="reference internal" href="#the-adce-pass" id="id37">The <tt class="docutils literal"><span class="pre">-adce</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-licm-pass" id="id38">The <tt class="docutils literal"><span class="pre">-licm</span></tt> pass</a></li>
+<li><a class="reference internal" href="#the-argpromotion-pass" id="id39">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="id40">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="id41">Clients for debugging and evaluation of implementations</a><ul>
+<li><a class="reference internal" href="#the-print-alias-sets-pass" id="id42">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="id43">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="id44">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="id45">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.</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 internal" href="LangRef.html#constants"><em>constants</em></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 internal" href="LangRef.html#constants"><em>constant</em></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 internal" href="LangRef.html#noalias"><em>noalias</em></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 satisfy <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="required-methods-to-override">
+<h3><a class="toc-backref" href="#id13">Required methods to override</a><a class="headerlink" href="#required-methods-to-override" title="Permalink to this headline">¶</a></h3>
+<p>You must override the <tt class="docutils literal"><span class="pre">getAdjustedAnalysisPointer</span></tt> method on all subclasses
+of <tt class="docutils literal"><span class="pre">AliasAnalysis</span></tt>. An example implementation of this method would look like:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">void</span> <span class="o">*</span><span class="n">getAdjustedAnalysisPointer</span><span class="p">(</span><span class="k">const</span> <span class="kt">void</span><span class="o">*</span> <span class="n">ID</span><span class="p">)</span> <span class="n">override</span> <span class="p">{</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">ID</span> <span class="o">==</span> <span class="o">&</span><span class="n">AliasAnalysis</span><span class="o">::</span><span class="n">ID</span><span class="p">)</span>
+ <span class="k">return</span> <span class="p">(</span><span class="n">AliasAnalysis</span><span class="o">*</span><span class="p">)</span><span class="k">this</span><span class="p">;</span>
+ <span class="k">return</span> <span class="k">this</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="#id14">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="#id15"><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">AliasResult</span> <span class="nf">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="#id16">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="#id17">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="#id18">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="#id19">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="#id20">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="#id21">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="#id22">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>) 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="#id23">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="#id24">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="#id25">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="#id26">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="#id27">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="#id28">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="#id29">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="#id30">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="#id31">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="#id32">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="#id33">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="#id34">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="#id35">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="#id36">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="#id37">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="#id38">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>It 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="#id39">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="#id40">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="#id41">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="#id42">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="#id43">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="#id44">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="#id45">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="ScudoHardenedAllocator.html" title="Scudo Hardened Allocator"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/Atomics.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/Atomics.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/Atomics.html (added)
+++ www-releases/trunk/3.9.0/docs/Atomics.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,635 @@
+
+<!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.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="LLVM Coding Standards" href="CodingStandards.html" />
+ <link rel="prev" title="Reporting Guide" href="ReportingGuide.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="ReportingGuide.html" title="Reporting 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-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>
+<li><a class="reference internal" href="#libcalls-atomic" id="id17">Libcalls: __atomic_*</a></li>
+<li><a class="reference internal" href="#libcalls-sync" id="id18">Libcalls: __sync_*</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>LLVM supports instructions which are well-defined in the presence of threads and
+asynchronous signals.</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 C++11 <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++11 draft available here</a>.) (<a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg14/">C11 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://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html">Java Specification</a>)</li>
+<li>gcc-compatible <tt class="docutils literal"><span class="pre">__sync_*</span></tt> builtins. (<a class="reference external" href="https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-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.</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, and a Monotonic store following a Release fence is roughly
+equivalent to a Release store. SequentiallyConsistent fences behave as both
+an Acquire and a Release fence, and offer some additional complicated
+guarantees, see the C++11 standard for details.</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 llvm-dev.)</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 does 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++11/C11 <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++11/C11 <tt class="docutils literal"><span class="pre">memory_order_acquire</span></tt>. It should also be
+used for C++11/C11 <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++11/C11 <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++11/C11 <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++11/C11 <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><tt class="docutils literal"><span class="pre">isStrongerThan</span></tt> / <tt class="docutils literal"><span class="pre">isAtLeastOrStrongerThan</span></tt>: These are predicates on
+orderings. They can be useful for passes that are aware of atomics, for
+example to do DSE across a single atomic access, but not across a
+release-acquire pair (see MemoryDependencyAnalysis for an example of this)</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. It is possible in some case for DSE to operate across a stronger
+atomic operation, but it is fairly tricky. DSE delegates this reasoning to
+MemoryDependencyAnalysis (which is also used by other passes like GVN).</li>
+<li>Folding a load: Any atomic load from a constant global can be constant-folded,
+because it cannot be observed. Similar reasoning allows sroa 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 can be emitted by the AtomicExpand Codegen pass if
+<tt class="docutils literal"><span class="pre">setInsertFencesForAtomic()</span></tt> was used.</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>One very important property of the atomic operations is that if your backend
+supports any inline lock-free atomic operations of a given size, you should
+support <em>ALL</em> operations of that size in a lock-free manner.</p>
+<p>When the target implements atomic <tt class="docutils literal"><span class="pre">cmpxchg</span></tt> or LL/SC instructions (as most do)
+this is trivial: all the other operations can be implemented on top of those
+primitives. However, on many older CPUs (e.g. ARMv5, SparcV8, Intel 80386) there
+are atomic load and store instructions, but no <tt class="docutils literal"><span class="pre">cmpxchg</span></tt> or LL/SC. As it is
+invalid to implement <tt class="docutils literal"><span class="pre">atomic</span> <span class="pre">load</span></tt> using the native instruction, but
+<tt class="docutils literal"><span class="pre">cmpxchg</span></tt> using a library call to a function that uses a mutex, <tt class="docutils literal"><span class="pre">atomic</span>
+<span class="pre">load</span></tt> must <em>also</em> expand to a library call on such architectures, so that it
+can remain atomic with regards to a simultaneous <tt class="docutils literal"><span class="pre">cmpxchg</span></tt>, by using the same
+mutex.</p>
+<p>AtomicExpandPass can help with that: it will expand all atomic operations to the
+proper <tt class="docutils literal"><span class="pre">__atomic_*</span></tt> libcalls for any size above the maximum set by
+<tt class="docutils literal"><span class="pre">setMaxAtomicSizeInBitsSupported</span></tt> (which defaults to 0).</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. <tt class="docutils literal"><span class="pre">cmpxchg</span></tt> 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 (before v8), 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.).</p>
+<p>It is often easiest for backends to use AtomicExpandPass to lower some of the
+atomic constructs. Here are some lowerings it can do:</p>
+<ul class="simple">
+<li>cmpxchg -> loop with load-linked/store-conditional
+by overriding <tt class="docutils literal"><span class="pre">shouldExpandAtomicCmpXchgInIR()</span></tt>, <tt class="docutils literal"><span class="pre">emitLoadLinked()</span></tt>,
+<tt class="docutils literal"><span class="pre">emitStoreConditional()</span></tt></li>
+<li>large loads/stores -> ll-sc/cmpxchg
+by overriding <tt class="docutils literal"><span class="pre">shouldExpandAtomicStoreInIR()</span></tt>/<tt class="docutils literal"><span class="pre">shouldExpandAtomicLoadInIR()</span></tt></li>
+<li>strong atomic accesses -> monotonic accesses + fences by overriding
+<tt class="docutils literal"><span class="pre">shouldInsertFencesForAtomic()</span></tt>, <tt class="docutils literal"><span class="pre">emitLeadingFence()</span></tt>, and
+<tt class="docutils literal"><span class="pre">emitTrailingFence()</span></tt></li>
+<li>atomic rmw -> loop with cmpxchg or load-linked/store-conditional
+by overriding <tt class="docutils literal"><span class="pre">expandAtomicRMWInIR()</span></tt></li>
+<li>expansion to __atomic_* libcalls for unsupported sizes.</li>
+</ul>
+<p>For an example of all of these, look at the ARM backend.</p>
+</div>
+<div class="section" id="libcalls-atomic">
+<h2><a class="toc-backref" href="#id17">Libcalls: __atomic_*</a><a class="headerlink" href="#libcalls-atomic" title="Permalink to this headline">¶</a></h2>
+<p>There are two kinds of atomic library calls that are generated by LLVM. Please
+note that both sets of library functions somewhat confusingly share the names of
+builtin functions defined by clang. Despite this, the library functions are
+not directly related to the builtins: it is <em>not</em> the case that <tt class="docutils literal"><span class="pre">__atomic_*</span></tt>
+builtins lower to <tt class="docutils literal"><span class="pre">__atomic_*</span></tt> library calls and <tt class="docutils literal"><span class="pre">__sync_*</span></tt> builtins lower
+to <tt class="docutils literal"><span class="pre">__sync_*</span></tt> library calls.</p>
+<p>The first set of library functions are named <tt class="docutils literal"><span class="pre">__atomic_*</span></tt>. This set has been
+“standardized” by GCC, and is described below. (See also <a class="reference external" href="https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary">GCC’s documentation</a>)</p>
+<p>LLVM’s AtomicExpandPass will translate atomic operations on data sizes above
+<tt class="docutils literal"><span class="pre">MaxAtomicSizeInBitsSupported</span></tt> into calls to these functions.</p>
+<p>There are four generic functions, which can be called with data of any size or
+alignment:</p>
+<div class="highlight-python"><div class="highlight"><pre>void __atomic_load(size_t size, void *ptr, void *ret, int ordering)
+void __atomic_store(size_t size, void *ptr, void *val, int ordering)
+void __atomic_exchange(size_t size, void *ptr, void *val, void *ret, int ordering)
+bool __atomic_compare_exchange(size_t size, void *ptr, void *expected, void *desired, int success_order, int failure_order)
+</pre></div>
+</div>
+<p>There are also size-specialized versions of the above functions, which can only
+be used with <em>naturally-aligned</em> pointers of the appropriate size. In the
+signatures below, “N” is one of 1, 2, 4, 8, and 16, and “iN” is the appropriate
+integer type of that size; if no such integer type exists, the specialization
+cannot be used:</p>
+<div class="highlight-python"><div class="highlight"><pre>iN __atomic_load_N(iN *ptr, iN val, int ordering)
+void __atomic_store_N(iN *ptr, iN val, int ordering)
+iN __atomic_exchange_N(iN *ptr, iN val, int ordering)
+bool __atomic_compare_exchange_N(iN *ptr, iN *expected, iN desired, int success_order, int failure_order)
+</pre></div>
+</div>
+<p>Finally there are some read-modify-write functions, which are only available in
+the size-specific variants (any other sizes use a <tt class="docutils literal"><span class="pre">__atomic_compare_exchange</span></tt>
+loop):</p>
+<div class="highlight-python"><div class="highlight"><pre>iN __atomic_fetch_add_N(iN *ptr, iN val, int ordering)
+iN __atomic_fetch_sub_N(iN *ptr, iN val, int ordering)
+iN __atomic_fetch_and_N(iN *ptr, iN val, int ordering)
+iN __atomic_fetch_or_N(iN *ptr, iN val, int ordering)
+iN __atomic_fetch_xor_N(iN *ptr, iN val, int ordering)
+iN __atomic_fetch_nand_N(iN *ptr, iN val, int ordering)
+</pre></div>
+</div>
+<p>This set of library functions have some interesting implementation requirements
+to take note of:</p>
+<ul class="simple">
+<li>They support all sizes and alignments – including those which cannot be
+implemented natively on any existing hardware. Therefore, they will certainly
+use mutexes in for some sizes/alignments.</li>
+<li>As a consequence, they cannot be shipped in a statically linked
+compiler-support library, as they have state which must be shared amongst all
+DSOs loaded in the program. They must be provided in a shared library used by
+all objects.</li>
+<li>The set of atomic sizes supported lock-free must be a superset of the sizes
+any compiler can emit. That is: if a new compiler introduces support for
+inline-lock-free atomics of size N, the <tt class="docutils literal"><span class="pre">__atomic_*</span></tt> functions must also have a
+lock-free implementation for size N. This is a requirement so that code
+produced by an old compiler (which will have called the <tt class="docutils literal"><span class="pre">__atomic_*</span></tt> function)
+interoperates with code produced by the new compiler (which will use native
+the atomic instruction).</li>
+</ul>
+<p>Note that it’s possible to write an entirely target-independent implementation
+of these library functions by using the compiler atomic builtins themselves to
+implement the operations on naturally-aligned pointers of supported sizes, and a
+generic mutex implementation otherwise.</p>
+</div>
+<div class="section" id="libcalls-sync">
+<h2><a class="toc-backref" href="#id18">Libcalls: __sync_*</a><a class="headerlink" href="#libcalls-sync" title="Permalink to this headline">¶</a></h2>
+<p>Some targets or OS/target combinations can support lock-free atomics, but for
+various reasons, it is not practical to emit the instructions inline.</p>
+<p>There’s two typical examples of this.</p>
+<p>Some CPUs support multiple instruction sets which can be swiched back and forth
+on function-call boundaries. For example, MIPS supports the MIPS16 ISA, which
+has a smaller instruction encoding than the usual MIPS32 ISA. ARM, similarly,
+has the Thumb ISA. In MIPS16 and earlier versions of Thumb, the atomic
+instructions are not encodable. However, those instructions are available via a
+function call to a function with the longer encoding.</p>
+<p>Additionally, a few OS/target pairs provide kernel-supported lock-free
+atomics. ARM/Linux is an example of this: the kernel <a class="reference external" href="https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt">provides</a> a
+function which on older CPUs contains a “magically-restartable” atomic sequence
+(which looks atomic so long as there’s only one CPU), and contains actual atomic
+instructions on newer multicore models. This sort of functionality can typically
+be provided on any architecture, if all CPUs which are missing atomic
+compare-and-swap support are uniprocessor (no SMP). This is almost always the
+case. The only common architecture without that property is SPARC – SPARCV8 SMP
+systems were common, yet it doesn’t support any sort of compare-and-swap
+operation.</p>
+<p>In either of these cases, the Target in LLVM can claim support for atomics of an
+appropriate size, and then implement some subset of the operations via libcalls
+to a <tt class="docutils literal"><span class="pre">__sync_*</span></tt> function. Such functions <em>must</em> not use locks in their
+implementation, because unlike the <tt class="docutils literal"><span class="pre">__atomic_*</span></tt> routines used by
+AtomicExpandPass, these may be mixed-and-matched with native instructions by the
+target lowering.</p>
+<p>Further, these routines do not need to be shared, as they are stateless. So,
+there is no issue with having multiple copies included in one binary. Thus,
+typically these routines are implemented by the statically-linked compiler
+runtime support library.</p>
+<p>LLVM will emit a call to an appropriate <tt class="docutils literal"><span class="pre">__sync_*</span></tt> routine if the target
+ISelLowering code has set the corresponding <tt class="docutils literal"><span class="pre">ATOMIC_CMPXCHG</span></tt>, <tt class="docutils literal"><span class="pre">ATOMIC_SWAP</span></tt>,
+or <tt class="docutils literal"><span class="pre">ATOMIC_LOAD_*</span></tt> operation to “Expand”, and if it has opted-into the
+availability of those library functions via a call to <tt class="docutils literal"><span class="pre">initSyncLibcalls()</span></tt>.</p>
+<p>The full set of functions that may be called by LLVM is (for <tt class="docutils literal"><span class="pre">N</span></tt> being 1, 2,
+4, 8, or 16):</p>
+<div class="highlight-python"><div class="highlight"><pre>iN __sync_val_compare_and_swap_N(iN *ptr, iN expected, iN desired)
+iN __sync_lock_test_and_set_N(iN *ptr, iN val)
+iN __sync_fetch_and_add_N(iN *ptr, iN val)
+iN __sync_fetch_and_sub_N(iN *ptr, iN val)
+iN __sync_fetch_and_and_N(iN *ptr, iN val)
+iN __sync_fetch_and_or_N(iN *ptr, iN val)
+iN __sync_fetch_and_xor_N(iN *ptr, iN val)
+iN __sync_fetch_and_nand_N(iN *ptr, iN val)
+iN __sync_fetch_and_max_N(iN *ptr, iN val)
+iN __sync_fetch_and_umax_N(iN *ptr, iN val)
+iN __sync_fetch_and_min_N(iN *ptr, iN val)
+iN __sync_fetch_and_umin_N(iN *ptr, iN val)
+</pre></div>
+</div>
+<p>This list doesn’t include any function for atomic load or store; all known
+architectures support atomic loads and stores directly (possibly by emitting a
+fence on either side of a normal load or store.)</p>
+<p>There’s also, somewhat separately, the possibility to lower <tt class="docutils literal"><span class="pre">ATOMIC_FENCE</span></tt> to
+<tt class="docutils literal"><span class="pre">__sync_synchronize()</span></tt>. This may happen or not happen independent of all the
+above, controlled purely by <tt class="docutils literal"><span class="pre">setOperationAction(ISD::ATOMIC_FENCE,</span> <span class="pre">...)</span></tt>.</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="ReportingGuide.html" title="Reporting 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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/BigEndianNEON.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/BigEndianNEON.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/BigEndianNEON.html (added)
+++ www-releases/trunk/3.9.0/docs/BigEndianNEON.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,301 @@
+
+<!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>Using ARM NEON instructions in big endian mode — LLVM 3.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="LLVM Code Coverage Mapping Format" href="CoverageMappingFormat.html" />
+ <link rel="prev" title="Design and Usage of the InAlloca Attribute" href="InAlloca.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="CoverageMappingFormat.html" title="LLVM Code Coverage Mapping Format"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="InAlloca.html" title="Design and Usage of the InAlloca Attribute"
+ 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="using-arm-neon-instructions-in-big-endian-mode">
+<h1>Using ARM NEON instructions in big endian mode<a class="headerlink" href="#using-arm-neon-instructions-in-big-endian-mode" 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="id3">Introduction</a><ul>
+<li><a class="reference internal" href="#example-c-level-intrinsics-assembly" id="id4">Example: C-level intrinsics -> assembly</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#problem" id="id5">Problem</a></li>
+<li><a class="reference internal" href="#ldr-and-ld1" id="id6"><tt class="docutils literal"><span class="pre">LDR</span></tt> and <tt class="docutils literal"><span class="pre">LD1</span></tt></a></li>
+<li><a class="reference internal" href="#considerations" id="id7">Considerations</a><ul>
+<li><a class="reference internal" href="#llvm-ir-lane-ordering" id="id8">LLVM IR Lane ordering</a></li>
+<li><a class="reference internal" href="#aapcs" id="id9">AAPCS</a></li>
+<li><a class="reference internal" href="#alignment" id="id10">Alignment</a></li>
+<li><a class="reference internal" href="#summary" id="id11">Summary</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#implementation" id="id12">Implementation</a><ul>
+<li><a class="reference internal" href="#bitconverts" id="id13">Bitconverts</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id3">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>Generating code for big endian ARM processors is for the most part straightforward. NEON loads and stores however have some interesting properties that make code generation decisions less obvious in big endian mode.</p>
+<p>The aim of this document is to explain the problem with NEON loads and stores, and the solution that has been implemented in LLVM.</p>
+<p>In this document the term “vector” refers to what the ARM ABI calls a “short vector”, which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is sligtly different to A64. Apart from that, the same concepts apply.</p>
+<div class="section" id="example-c-level-intrinsics-assembly">
+<h3><a class="toc-backref" href="#id4">Example: C-level intrinsics -> assembly</a><a class="headerlink" href="#example-c-level-intrinsics-assembly" title="Permalink to this headline">¶</a></h3>
+<p>It may be helpful first to illustrate how C-level ARM NEON intrinsics are lowered to instructions.</p>
+<p>This trivial C function takes a vector of four ints and sets the zero’th lane to the value “42”:</p>
+<div class="highlight-python"><div class="highlight"><pre>#include <arm_neon.h>
+int32x4_t f(int32x4_t p) {
+ return vsetq_lane_s32(42, p, 0);
+}
+</pre></div>
+</div>
+<p>arm_neon.h intrinsics generate “generic” IR where possible (that is, normal IR instructions not <tt class="docutils literal"><span class="pre">llvm.arm.neon.*</span></tt> intrinsic calls). The above generates:</p>
+<div class="highlight-python"><div class="highlight"><pre>define <4 x i32> @f(<4 x i32> %p) {
+ %vset_lane = insertelement <4 x i32> %p, i32 42, i32 0
+ ret <4 x i32> %vset_lane
+}
+</pre></div>
+</div>
+<p>Which then becomes the following trivial assembly:</p>
+<div class="highlight-python"><div class="highlight"><pre>f: // @f
+ movz w8, #0x2a
+ ins v0.s[0], w8
+ ret
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="problem">
+<h2><a class="toc-backref" href="#id5">Problem</a><a class="headerlink" href="#problem" title="Permalink to this headline">¶</a></h2>
+<p>The main problem is how vectors are represented in memory and in registers.</p>
+<p>First, a recap. The “endianness” of an item affects its representation in memory only. In a register, a number is just a sequence of bits - 64 bits in the case of AArch64 general purpose registers. Memory, however, is a sequence of addressable units of 8 bits in size. Any number greater than 8 bits must therefore be split up into 8-bit chunks, and endianness describes the order in which these chunks are laid out in memory.</p>
+<p>A “little endian” layout has the least significant byte first (lowest in memory address). A “big endian” layout has the <em>most</em> significant byte first. This means that when loading an item from big endian memory, the lowest 8-bits in memory must go in the most significant 8-bits, and so forth.</p>
+</div>
+<div class="section" id="ldr-and-ld1">
+<h2><a class="toc-backref" href="#id6"><tt class="docutils literal"><span class="pre">LDR</span></tt> and <tt class="docutils literal"><span class="pre">LD1</span></tt></a><a class="headerlink" href="#ldr-and-ld1" title="Permalink to this headline">¶</a></h2>
+<div class="figure align-right">
+<img alt="_images/ARM-BE-ldr.png" src="_images/ARM-BE-ldr.png" />
+<p class="caption">Big endian vector load using <tt class="docutils literal"><span class="pre">LDR</span></tt>.</p>
+</div>
+<p>A vector is a consecutive sequence of items that are operated on simultaneously. To load a 64-bit vector, 64 bits need to be read from memory. In little endian mode, we can do this by just performing a 64-bit load - <tt class="docutils literal"><span class="pre">LDR</span> <span class="pre">q0,</span> <span class="pre">[foo]</span></tt>. However if we try this in big endian mode, because of the byte swapping the lane indices end up being swapped! The zero’th item as laid out in memory becomes the n’th lane in the vector.</p>
+<div class="figure align-right">
+<img alt="_images/ARM-BE-ld1.png" src="_images/ARM-BE-ld1.png" />
+<p class="caption">Big endian vector load using <tt class="docutils literal"><span class="pre">LD1</span></tt>. Note that the lanes retain the correct ordering.</p>
+</div>
+<p>Because of this, the instruction <tt class="docutils literal"><span class="pre">LD1</span></tt> performs a vector load but performs byte swapping not on the entire 64 bits, but on the individual items within the vector. This means that the register content is the same as it would have been on a little endian system.</p>
+<p>It may seem that <tt class="docutils literal"><span class="pre">LD1</span></tt> should suffice to peform vector loads on a big endian machine. However there are pros and cons to the two approaches that make it less than simple which register format to pick.</p>
+<p>There are two options:</p>
+<blockquote>
+<div><ol class="arabic simple">
+<li>The content of a vector register is the same <em>as if</em> it had been loaded with an <tt class="docutils literal"><span class="pre">LDR</span></tt> instruction.</li>
+<li>The content of a vector register is the same <em>as if</em> it had been loaded with an <tt class="docutils literal"><span class="pre">LD1</span></tt> instruction.</li>
+</ol>
+</div></blockquote>
+<p>Because <tt class="docutils literal"><span class="pre">LD1</span> <span class="pre">==</span> <span class="pre">LDR</span> <span class="pre">+</span> <span class="pre">REV</span></tt> and similarly <tt class="docutils literal"><span class="pre">LDR</span> <span class="pre">==</span> <span class="pre">LD1</span> <span class="pre">+</span> <span class="pre">REV</span></tt> (on a big endian system), we can simulate either type of load with the other type of load plus a <tt class="docutils literal"><span class="pre">REV</span></tt> instruction. So we’re not deciding which instructions to use, but which format to use (which will then influence which instruction is best to use).</p>
+<div class="clearer container">
+Note that throughout this section we only mention loads. Stores have exactly the same problems as their associated loads, so have been skipped for brevity.</div>
+</div>
+<div class="section" id="considerations">
+<h2><a class="toc-backref" href="#id7">Considerations</a><a class="headerlink" href="#considerations" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="llvm-ir-lane-ordering">
+<h3><a class="toc-backref" href="#id8">LLVM IR Lane ordering</a><a class="headerlink" href="#llvm-ir-lane-ordering" title="Permalink to this headline">¶</a></h3>
+<p>LLVM IR has first class vector types. In LLVM IR, the zero’th element of a vector resides at the lowest memory address. The optimizer relies on this property in certain areas, for example when concatenating vectors together. The intention is for arrays and vectors to have identical memory layouts - <tt class="docutils literal"><span class="pre">[4</span> <span class="pre">x</span> <span class="pre">i8]</span></tt> and <tt class="docutils literal"><span class="pre"><4</span> <span class="pre">x</span> <span class="pre">i8></span></tt> should be represented the same in memory. Without this property there would be many special cases that the optimizer would have to cleverly handle.</p>
+<p>Use of <tt class="docutils literal"><span class="pre">LDR</span></tt> would break this lane ordering property. This doesn’t preclude the use of <tt class="docutils literal"><span class="pre">LDR</span></tt>, but we would have to do one of two things:</p>
+<blockquote>
+<div><ol class="arabic simple">
+<li>Insert a <tt class="docutils literal"><span class="pre">REV</span></tt> instruction to reverse the lane order after every <tt class="docutils literal"><span class="pre">LDR</span></tt>.</li>
+<li>Disable all optimizations that rely on lane layout, and for every access to an individual lane (<tt class="docutils literal"><span class="pre">insertelement</span></tt>/<tt class="docutils literal"><span class="pre">extractelement</span></tt>/<tt class="docutils literal"><span class="pre">shufflevector</span></tt>) reverse the lane index.</li>
+</ol>
+</div></blockquote>
+</div>
+<div class="section" id="aapcs">
+<h3><a class="toc-backref" href="#id9">AAPCS</a><a class="headerlink" href="#aapcs" title="Permalink to this headline">¶</a></h3>
+<p>The ARM procedure call standard (AAPCS) defines the ABI for passing vectors between functions in registers. It states:</p>
+<blockquote>
+<div><p>When a short vector is transferred between registers and memory it is treated as an opaque object. That is a short vector is stored in memory as if it were stored with a single <tt class="docutils literal"><span class="pre">STR</span></tt> of the entire register; a short vector is loaded from memory using the corresponding <tt class="docutils literal"><span class="pre">LDR</span></tt> instruction. On a little-endian system this means that element 0 will always contain the lowest addressed element of a short vector; on a big-endian system element 0 will contain the highest-addressed element of a short vector.</p>
+<p class="attribution">—Procedure Call Standard for the ARM 64-bit Architecture (AArch64), 4.1.2 Short Vectors</p>
+</div></blockquote>
+<p>The use of <tt class="docutils literal"><span class="pre">LDR</span></tt> and <tt class="docutils literal"><span class="pre">STR</span></tt> as the ABI defines has at least one advantage over <tt class="docutils literal"><span class="pre">LD1</span></tt> and <tt class="docutils literal"><span class="pre">ST1</span></tt>. <tt class="docutils literal"><span class="pre">LDR</span></tt> and <tt class="docutils literal"><span class="pre">STR</span></tt> are oblivious to the size of the individual lanes of a vector. <tt class="docutils literal"><span class="pre">LD1</span></tt> and <tt class="docutils literal"><span class="pre">ST1</span></tt> are not - the lane size is encoded within them. This is important across an ABI boundary, because it would become necessary to know the lane width the callee expects. Consider the following code:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="o"><</span><span class="n">callee</span><span class="p">.</span><span class="n">c</span><span class="o">></span>
+<span class="kt">void</span> <span class="n">callee</span><span class="p">(</span><span class="kt">uint32x2_t</span> <span class="n">v</span><span class="p">)</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+
+<span class="o"><</span><span class="n">caller</span><span class="p">.</span><span class="n">c</span><span class="o">></span>
+<span class="k">extern</span> <span class="kt">void</span> <span class="n">callee</span><span class="p">(</span><span class="kt">uint32x2_t</span><span class="p">);</span>
+<span class="kt">void</span> <span class="nf">caller</span><span class="p">()</span> <span class="p">{</span>
+ <span class="n">callee</span><span class="p">(...);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>If <tt class="docutils literal"><span class="pre">callee</span></tt> changed its signature to <tt class="docutils literal"><span class="pre">uint16x4_t</span></tt>, which is equivalent in register content, if we passed as <tt class="docutils literal"><span class="pre">LD1</span></tt> we’d break this code until <tt class="docutils literal"><span class="pre">caller</span></tt> was updated and recompiled.</p>
+<p>There is an argument that if the signatures of the two functions are different then the behaviour should be undefined. But there may be functions that are agnostic to the lane layout of the vector, and treating the vector as an opaque value (just loading it and storing it) would be impossible without a common format across ABI boundaries.</p>
+<p>So to preserve ABI compatibility, we need to use the <tt class="docutils literal"><span class="pre">LDR</span></tt> lane layout across function calls.</p>
+</div>
+<div class="section" id="alignment">
+<h3><a class="toc-backref" href="#id10">Alignment</a><a class="headerlink" href="#alignment" title="Permalink to this headline">¶</a></h3>
+<p>In strict alignment mode, <tt class="docutils literal"><span class="pre">LDR</span> <span class="pre">qX</span></tt> requires its address to be 128-bit aligned, whereas <tt class="docutils literal"><span class="pre">LD1</span></tt> only requires it to be as aligned as the lane size. If we canonicalised on using <tt class="docutils literal"><span class="pre">LDR</span></tt>, we’d still need to use <tt class="docutils literal"><span class="pre">LD1</span></tt> in some places to avoid alignment faults (the result of the <tt class="docutils literal"><span class="pre">LD1</span></tt> would then need to be reversed with <tt class="docutils literal"><span class="pre">REV</span></tt>).</p>
+<p>Most operating systems however do not run with alignment faults enabled, so this is often not an issue.</p>
+</div>
+<div class="section" id="summary">
+<h3><a class="toc-backref" href="#id11">Summary</a><a class="headerlink" href="#summary" title="Permalink to this headline">¶</a></h3>
+<p>The following table summarises the instructions that are required to be emitted for each property mentioned above for each of the two solutions.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="37%" />
+<col width="37%" />
+<col width="25%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head"> </th>
+<th class="head"><tt class="docutils literal"><span class="pre">LDR</span></tt> layout</th>
+<th class="head"><tt class="docutils literal"><span class="pre">LD1</span></tt> layout</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>Lane ordering</td>
+<td><tt class="docutils literal"><span class="pre">LDR</span> <span class="pre">+</span> <span class="pre">REV</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">LD1</span></tt></td>
+</tr>
+<tr class="row-odd"><td>AAPCS</td>
+<td><tt class="docutils literal"><span class="pre">LDR</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">LD1</span> <span class="pre">+</span> <span class="pre">REV</span></tt></td>
+</tr>
+<tr class="row-even"><td>Alignment for strict mode</td>
+<td><tt class="docutils literal"><span class="pre">LDR</span></tt> / <tt class="docutils literal"><span class="pre">LD1</span> <span class="pre">+</span> <span class="pre">REV</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">LD1</span></tt></td>
+</tr>
+</tbody>
+</table>
+<p>Neither approach is perfect, and choosing one boils down to choosing the lesser of two evils. The issue with lane ordering, it was decided, would have to change target-agnostic compiler passes and would result in a strange IR in which lane indices were reversed. It was decided that this was worse than the changes that would have to be made to support <tt class="docutils literal"><span class="pre">LD1</span></tt>, so <tt class="docutils literal"><span class="pre">LD1</span></tt> was chosen as the canonical vector load instruction (and by inference, <tt class="docutils literal"><span class="pre">ST1</span></tt> for vector stores).</p>
+</div>
+</div>
+<div class="section" id="implementation">
+<h2><a class="toc-backref" href="#id12">Implementation</a><a class="headerlink" href="#implementation" title="Permalink to this headline">¶</a></h2>
+<p>There are 3 parts to the implementation:</p>
+<blockquote>
+<div><ol class="arabic simple">
+<li>Predicate <tt class="docutils literal"><span class="pre">LDR</span></tt> and <tt class="docutils literal"><span class="pre">STR</span></tt> instructions so that they are never allowed to be selected to generate vector loads and stores. The exception is one-lane vectors <a class="footnote-reference" href="#id2" id="id1">[1]</a> - these by definition cannot have lane ordering problems so are fine to use <tt class="docutils literal"><span class="pre">LDR</span></tt>/<tt class="docutils literal"><span class="pre">STR</span></tt>.</li>
+<li>Create code generation patterns for bitconverts that create <tt class="docutils literal"><span class="pre">REV</span></tt> instructions.</li>
+<li>Make sure appropriate bitconverts are created so that vector values get passed over call boundaries as 1-element vectors (which is the same as if they were loaded with <tt class="docutils literal"><span class="pre">LDR</span></tt>).</li>
+</ol>
+</div></blockquote>
+<div class="section" id="bitconverts">
+<h3><a class="toc-backref" href="#id13">Bitconverts</a><a class="headerlink" href="#bitconverts" title="Permalink to this headline">¶</a></h3>
+<img alt="_images/ARM-BE-bitcastfail.png" class="align-right" src="_images/ARM-BE-bitcastfail.png" />
+<p>The main problem with the <tt class="docutils literal"><span class="pre">LD1</span></tt> solution is dealing with bitconverts (or bitcasts, or reinterpret casts). These are pseudo instructions that only change the compiler’s interpretation of data, not the underlying data itself. A requirement is that if data is loaded and then saved again (called a “round trip”), the memory contents should be the same after the store as before the load. If a vector is loaded and is then bitconverted to a different vector type before storing, the round trip will currently be broken.</p>
+<p>Take for example this code sequence:</p>
+<div class="highlight-python"><div class="highlight"><pre>%0 = load <4 x i32> %x
+%1 = bitcast <4 x i32> %0 to <2 x i64>
+ store <2 x i64> %1, <2 x i64>* %y
+</pre></div>
+</div>
+<p>This would produce a code sequence such as that in the figure on the right. The mismatched <tt class="docutils literal"><span class="pre">LD1</span></tt> and <tt class="docutils literal"><span class="pre">ST1</span></tt> cause the stored data to differ from the loaded data.</p>
+<div class="clearer container">
+When we see a bitcast from type <tt class="docutils literal"><span class="pre">X</span></tt> to type <tt class="docutils literal"><span class="pre">Y</span></tt>, what we need to do is to change the in-register representation of the data to be <em>as if</em> it had just been loaded by a <tt class="docutils literal"><span class="pre">LD1</span></tt> of type <tt class="docutils literal"><span class="pre">Y</span></tt>.</div>
+<img alt="_images/ARM-BE-bitcastsuccess.png" class="align-right" src="_images/ARM-BE-bitcastsuccess.png" />
+<p>Conceptually this is simple - we can insert a <tt class="docutils literal"><span class="pre">REV</span></tt> undoing the <tt class="docutils literal"><span class="pre">LD1</span></tt> of type <tt class="docutils literal"><span class="pre">X</span></tt> (converting the in-register representation to the same as if it had been loaded by <tt class="docutils literal"><span class="pre">LDR</span></tt>) and then insert another <tt class="docutils literal"><span class="pre">REV</span></tt> to change the representation to be as if it had been loaded by an <tt class="docutils literal"><span class="pre">LD1</span></tt> of type <tt class="docutils literal"><span class="pre">Y</span></tt>.</p>
+<p>For the previous example, this would be:</p>
+<div class="highlight-python"><div class="highlight"><pre>LD1 v0.4s, [x]
+
+REV64 v0.4s, v0.4s // There is no REV128 instruction, so it must be synthesizedcd
+EXT v0.16b, v0.16b, v0.16b, #8 // with a REV64 then an EXT to swap the two 64-bit elements.
+
+REV64 v0.2d, v0.2d
+EXT v0.16b, v0.16b, v0.16b, #8
+
+ST1 v0.2d, [y]
+</pre></div>
+</div>
+<p>It turns out that these <tt class="docutils literal"><span class="pre">REV</span></tt> pairs can, in almost all cases, be squashed together into a single <tt class="docutils literal"><span class="pre">REV</span></tt>. For the example above, a <tt class="docutils literal"><span class="pre">REV128</span> <span class="pre">4s</span></tt> + <tt class="docutils literal"><span class="pre">REV128</span> <span class="pre">2d</span></tt> is actually a <tt class="docutils literal"><span class="pre">REV64</span> <span class="pre">4s</span></tt>, as shown in the figure on the right.</p>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>One lane vectors may seem useless as a concept but they serve to distinguish between values held in general purpose registers and values held in NEON/VFP registers. For example, an <tt class="docutils literal"><span class="pre">i64</span></tt> would live in an <tt class="docutils literal"><span class="pre">x</span></tt> register, but <tt class="docutils literal"><span class="pre"><1</span> <span class="pre">x</span> <span class="pre">i64></span></tt> would live in a <tt class="docutils literal"><span class="pre">d</span></tt> register.</td></tr>
+</tbody>
+</table>
+</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="CoverageMappingFormat.html" title="LLVM Code Coverage Mapping Format"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="InAlloca.html" title="Design and Usage of the InAlloca Attribute"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/BitCodeFormat.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/BitCodeFormat.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/BitCodeFormat.html (added)
+++ www-releases/trunk/3.9.0/docs/BitCodeFormat.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,1073 @@
+
+<!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.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="LLVM Block Frequency Terminology" href="BlockFrequencyTerminology.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="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ 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="#native-object-file-wrapper-format" id="id30">Native Object File Wrapper Format</a></li>
+<li><a class="reference internal" href="#llvm-ir-encoding" id="id31">LLVM IR Encoding</a><ul>
+<li><a class="reference internal" href="#basics" id="id32">Basics</a><ul>
+<li><a class="reference internal" href="#llvm-ir-magic-number" id="id33">LLVM IR Magic Number</a></li>
+<li><a class="reference internal" href="#signed-vbrs" id="id34">Signed VBRs</a></li>
+<li><a class="reference internal" href="#llvm-ir-blocks" id="id35">LLVM IR Blocks</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#module-block-contents" id="id36">MODULE_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#module-code-version-record" id="id37">MODULE_CODE_VERSION Record</a></li>
+<li><a class="reference internal" href="#module-code-triple-record" id="id38">MODULE_CODE_TRIPLE Record</a></li>
+<li><a class="reference internal" href="#module-code-datalayout-record" id="id39">MODULE_CODE_DATALAYOUT Record</a></li>
+<li><a class="reference internal" href="#module-code-asm-record" id="id40">MODULE_CODE_ASM Record</a></li>
+<li><a class="reference internal" href="#module-code-sectionname-record" id="id41">MODULE_CODE_SECTIONNAME Record</a></li>
+<li><a class="reference internal" href="#module-code-deplib-record" id="id42">MODULE_CODE_DEPLIB Record</a></li>
+<li><a class="reference internal" href="#module-code-globalvar-record" id="id43">MODULE_CODE_GLOBALVAR Record</a></li>
+<li><a class="reference internal" href="#module-code-function-record" id="id44">MODULE_CODE_FUNCTION Record</a></li>
+<li><a class="reference internal" href="#module-code-alias-record" id="id45">MODULE_CODE_ALIAS Record</a></li>
+<li><a class="reference internal" href="#module-code-purgevals-record" id="id46">MODULE_CODE_PURGEVALS Record</a></li>
+<li><a class="reference internal" href="#module-code-gcname-record" id="id47">MODULE_CODE_GCNAME Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#paramattr-block-contents" id="id48">PARAMATTR_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#paramattr-code-entry-record" id="id49">PARAMATTR_CODE_ENTRY Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#type-block-contents" id="id50">TYPE_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#type-code-numentry-record" id="id51">TYPE_CODE_NUMENTRY Record</a></li>
+<li><a class="reference internal" href="#type-code-void-record" id="id52">TYPE_CODE_VOID Record</a></li>
+<li><a class="reference internal" href="#type-code-half-record" id="id53">TYPE_CODE_HALF Record</a></li>
+<li><a class="reference internal" href="#type-code-float-record" id="id54">TYPE_CODE_FLOAT Record</a></li>
+<li><a class="reference internal" href="#type-code-double-record" id="id55">TYPE_CODE_DOUBLE Record</a></li>
+<li><a class="reference internal" href="#type-code-label-record" id="id56">TYPE_CODE_LABEL Record</a></li>
+<li><a class="reference internal" href="#type-code-opaque-record" id="id57">TYPE_CODE_OPAQUE Record</a></li>
+<li><a class="reference internal" href="#type-code-integer-record" id="id58">TYPE_CODE_INTEGER Record</a></li>
+<li><a class="reference internal" href="#type-code-pointer-record" id="id59">TYPE_CODE_POINTER Record</a></li>
+<li><a class="reference internal" href="#type-code-function-record" id="id60">TYPE_CODE_FUNCTION Record</a></li>
+<li><a class="reference internal" href="#type-code-struct-record" id="id61">TYPE_CODE_STRUCT Record</a></li>
+<li><a class="reference internal" href="#type-code-array-record" id="id62">TYPE_CODE_ARRAY Record</a></li>
+<li><a class="reference internal" href="#type-code-vector-record" id="id63">TYPE_CODE_VECTOR Record</a></li>
+<li><a class="reference internal" href="#type-code-x86-fp80-record" id="id64">TYPE_CODE_X86_FP80 Record</a></li>
+<li><a class="reference internal" href="#type-code-fp128-record" id="id65">TYPE_CODE_FP128 Record</a></li>
+<li><a class="reference internal" href="#type-code-ppc-fp128-record" id="id66">TYPE_CODE_PPC_FP128 Record</a></li>
+<li><a class="reference internal" href="#type-code-metadata-record" id="id67">TYPE_CODE_METADATA Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#constants-block-contents" id="id68">CONSTANTS_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#function-block-contents" id="id69">FUNCTION_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#type-symtab-block-contents" id="id70">TYPE_SYMTAB_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#tst-code-entry-record" id="id71">TST_CODE_ENTRY Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#value-symtab-block-contents" id="id72">VALUE_SYMTAB_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#metadata-block-contents" id="id73">METADATA_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#metadata-attachment-contents" id="id74">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, or in a
+<a class="reference internal" href="#native-object-file">native object file</a>. Both of these mechanisms make 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"><div class="highlight"><pre>'a' .. 'z' --- 0 .. 25
+'A' .. 'Z' --- 26 .. 51
+'0' .. '9' --- 52 .. 61
+ '.' --- 62
+ '_' --- 63
+</pre></div>
+</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"><div class="highlight"><pre>[SETBID (#1), blockid]
+[DEFINE_ABBREV, ...]
+[BLOCKNAME, ...name...]
+[SETRECORDNAME, RecordID, ...name...]
+</pre></div>
+</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="native-object-file-wrapper-format">
+<span id="native-object-file"></span><h2><a class="toc-backref" href="#id30">Native Object File Wrapper Format</a><a class="headerlink" href="#native-object-file-wrapper-format" title="Permalink to this headline">¶</a></h2>
+<p>Bitcode files for LLVM IR may also be wrapped in a native object file
+(i.e. ELF, COFF, Mach-O). The bitcode must be stored in a section of the object
+file named <tt class="docutils literal"><span class="pre">__LLVM,__bitcode</span></tt> for MachO and <tt class="docutils literal"><span class="pre">.llvmbc</span></tt> for the other object
+formats. This wrapper format is useful for accommodating LTO in compilation
+pipelines where intermediate objects must be native object files which contain
+metadata in other sections.</p>
+<p>Not all tools support this format.</p>
+</div>
+<div class="section" id="llvm-ir-encoding">
+<span id="encoding-of-llvm-ir"></span><h2><a class="toc-backref" href="#id31">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="#id32">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="#id33">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="#id34">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="#id35">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="#id36">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="#id37">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"><div class="highlight"><pre>#n = load #n-1
+#n+1 = icmp eq #n, #const0
+br #n+1, label #(bb1), label #(bb2)
+</pre></div>
+</div>
+<p>version 1 will encode the instructions as</p>
+<div class="highlight-llvm"><div class="highlight"><pre>#n = load #1
+#n+1 = icmp eq #1, (#n+1)-#const0
+br #1, label #(bb1), label #(bb2)
+</pre></div>
+</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="#id38">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="#id39">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="#id40">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="#id41">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="#id42">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="#id43">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> <span class="pre">externally_initialized,</span> <span class="pre">dllstorageclass,</span> <span class="pre">comdat]</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:<ul>
+<li><tt class="docutils literal"><span class="pre">external</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">weak</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">appending</span></tt>: code 2</li>
+<li><tt class="docutils literal"><span class="pre">internal</span></tt>: code 3</li>
+<li><tt class="docutils literal"><span class="pre">linkonce</span></tt>: code 4</li>
+<li><tt class="docutils literal"><span class="pre">dllimport</span></tt>: code 5</li>
+<li><tt class="docutils literal"><span class="pre">dllexport</span></tt>: code 6</li>
+<li><tt class="docutils literal"><span class="pre">extern_weak</span></tt>: code 7</li>
+<li><tt class="docutils literal"><span class="pre">common</span></tt>: code 8</li>
+<li><tt class="docutils literal"><span class="pre">private</span></tt>: code 9</li>
+<li><tt class="docutils literal"><span class="pre">weak_odr</span></tt>: code 10</li>
+<li><tt class="docutils literal"><span class="pre">linkonce_odr</span></tt>: code 11</li>
+<li><tt class="docutils literal"><span class="pre">available_externally</span></tt>: code 12</li>
+<li>deprecated : code 13</li>
+<li>deprecated : code 14</li>
+</ul>
+</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:<ul>
+<li><tt class="docutils literal"><span class="pre">default</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">hidden</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">protected</span></tt>: code 2</li>
+</ul>
+</li>
+</ul>
+<ul class="simple" id="bcthreadlocal">
+<li><em>threadlocal</em>: If present, an encoding of the thread local storage mode of the
+variable:<ul>
+<li><tt class="docutils literal"><span class="pre">not</span> <span class="pre">thread</span> <span class="pre">local</span></tt>: code 0</li>
+<li><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</li>
+<li><tt class="docutils literal"><span class="pre">localdynamic</span></tt>: code 2</li>
+<li><tt class="docutils literal"><span class="pre">initialexec</span></tt>: code 3</li>
+<li><tt class="docutils literal"><span class="pre">localexec</span></tt>: code 4</li>
+</ul>
+</li>
+</ul>
+<ul class="simple" id="bcunnamedaddr">
+<li><em>unnamed_addr</em>: If present, an encoding of the <tt class="docutils literal"><span class="pre">unnamed_addr</span></tt> attribute of this
+variable:<ul>
+<li>not <tt class="docutils literal"><span class="pre">unnamed_addr</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">unnamed_addr</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">local_unnamed_addr</span></tt>: code 2</li>
+</ul>
+</li>
+</ul>
+<ul class="simple" id="bcdllstorageclass">
+<li><em>dllstorageclass</em>: If present, an encoding of the DLL storage class of this variable:<ul>
+<li><tt class="docutils literal"><span class="pre">default</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">dllimport</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">dllexport</span></tt>: code 2</li>
+</ul>
+</li>
+<li><em>comdat</em>: An encoding of the COMDAT of this function</li>
+</ul>
+</div>
+<div class="section" id="module-code-function-record">
+<span id="function"></span><h4><a class="toc-backref" href="#id44">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">prologuedata,</span> <span class="pre">dllstorageclass,</span> <span class="pre">comdat,</span> <span class="pre">prefixdata,</span> <span class="pre">personalityfn]</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">webkit_jscc</span></tt>: code 12
+* <tt class="docutils literal"><span class="pre">anyregcc</span></tt>: code 13
+* <tt class="docutils literal"><span class="pre">preserve_mostcc</span></tt>: code 14
+* <tt class="docutils literal"><span class="pre">preserve_allcc</span></tt>: code 15
+* <tt class="docutils literal"><span class="pre">swiftcc</span></tt> : code 16
+* <tt class="docutils literal"><span class="pre">cxx_fast_tlscc</span></tt>: code 17
+* <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, an encoding of the
+<a class="reference internal" href="#bcunnamedaddr"><em>unnamed_addr</em></a> attribute of this function</li>
+<li><em>prologuedata</em>: If non-zero, the value index of the prologue data for this function,
+plus 1.</li>
+<li><em>dllstorageclass</em>: An encoding of the
+<a class="reference internal" href="#bcdllstorageclass"><em>dllstorageclass</em></a> of this function</li>
+<li><em>comdat</em>: An encoding of the COMDAT of this function</li>
+<li><em>prefixdata</em>: If non-zero, the value index of the prefix data for this function,
+plus 1.</li>
+<li><em>personalityfn</em>: If non-zero, the value index of the personality function for this function,
+plus 1.</li>
+</ul>
+</div>
+<div class="section" id="module-code-alias-record">
+<h4><a class="toc-backref" href="#id45">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> <span class="pre">dllstorageclass,</span> <span class="pre">threadlocal,</span> <span class="pre">unnamed_addr]</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>
+<li><em>dllstorageclass</em>: If present, an encoding of the
+<a class="reference internal" href="#bcdllstorageclass"><em>dllstorageclass</em></a> of the alias</li>
+<li><em>threadlocal</em>: If present, an encoding of the
+<a class="reference internal" href="#bcthreadlocal"><em>thread local property</em></a> of the alias</li>
+<li><em>unnamed_addr</em>: If present, an encoding of the
+<a class="reference internal" href="#bcunnamedaddr"><em>unnamed_addr</em></a> attribute of this alias</li>
+</ul>
+</div>
+<div class="section" id="module-code-purgevals-record">
+<h4><a class="toc-backref" href="#id46">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="#id47">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="#id48">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 indices 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="#id49">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="#id50">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 indices 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="#id51">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="#id52">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="#id53">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="#id54">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="#id55">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="#id56">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="#id57">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="#id58">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="#id59">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="#id60">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="#id61">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="#id62">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="#id63">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="#id64">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="#id65">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="#id66">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="#id67">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="#id68">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="#id69">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="#id70">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="#id71">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="#id72">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="#id73">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="#id74">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="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/BlockFrequencyTerminology.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/BlockFrequencyTerminology.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/BlockFrequencyTerminology.html (added)
+++ www-releases/trunk/3.9.0/docs/BlockFrequencyTerminology.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,214 @@
+
+<!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 Block Frequency Terminology — LLVM 3.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="LLVM Branch Weight Metadata" href="BranchWeightMetadata.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="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+ 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-block-frequency-terminology">
+<h1>LLVM Block Frequency Terminology<a class="headerlink" href="#llvm-block-frequency-terminology" 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="#branch-probability" id="id2">Branch Probability</a></li>
+<li><a class="reference internal" href="#branch-weight" id="id3">Branch Weight</a></li>
+<li><a class="reference internal" href="#block-frequency" id="id4">Block Frequency</a></li>
+<li><a class="reference internal" href="#implementation-a-series-of-dags" id="id5">Implementation: a series of DAGs</a></li>
+<li><a class="reference internal" href="#block-mass" id="id6">Block Mass</a></li>
+<li><a class="reference internal" href="#loop-scale" id="id7">Loop Scale</a></li>
+<li><a class="reference internal" href="#implementation-getting-from-mass-and-scale-to-frequency" id="id8">Implementation: Getting from mass and scale to frequency</a></li>
+<li><a class="reference internal" href="#block-bias" id="id9">Block Bias</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>Block Frequency is a metric for estimating the relative frequency of different
+basic blocks. This document describes the terminology that the
+<tt class="docutils literal"><span class="pre">BlockFrequencyInfo</span></tt> and <tt class="docutils literal"><span class="pre">MachineBlockFrequencyInfo</span></tt> analysis passes use.</p>
+</div>
+<div class="section" id="branch-probability">
+<h2><a class="toc-backref" href="#id2">Branch Probability</a><a class="headerlink" href="#branch-probability" title="Permalink to this headline">¶</a></h2>
+<p>Blocks with multiple successors have probabilities associated with each
+outgoing edge. These are called branch probabilities. For a given block, the
+sum of its outgoing branch probabilities should be 1.0.</p>
+</div>
+<div class="section" id="branch-weight">
+<h2><a class="toc-backref" href="#id3">Branch Weight</a><a class="headerlink" href="#branch-weight" title="Permalink to this headline">¶</a></h2>
+<p>Rather than storing fractions on each edge, we store an integer weight.
+Weights are relative to the other edges of a given predecessor block. The
+branch probability associated with a given edge is its own weight divided by
+the sum of the weights on the predecessor’s outgoing edges.</p>
+<p>For example, consider this IR:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="kt">void</span> <span class="vg">@foo</span><span class="p">()</span> <span class="p">{</span>
+ <span class="c">; ...</span>
+ <span class="nl">A:</span>
+ <span class="k">br</span> <span class="k">i1</span> <span class="nv">%cond</span><span class="p">,</span> <span class="kt">label</span> <span class="nv">%B</span><span class="p">,</span> <span class="kt">label</span> <span class="nv">%C</span><span class="p">,</span> <span class="nv">!prof</span> <span class="nv-Anonymous">!0</span>
+ <span class="c">; ...</span>
+<span class="p">}</span>
+<span class="nv-Anonymous">!0</span> <span class="p">=</span> <span class="kt">metadata</span> <span class="p">!{</span><span class="kt">metadata</span> <span class="nv">!"branch_weights"</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">,</span> <span class="k">i32</span> <span class="m">8</span><span class="p">}</span>
+</pre></div>
+</div>
+<p>and this simple graph representation:</p>
+<div class="highlight-python"><div class="highlight"><pre>A -> B (edge-weight: 7)
+A -> C (edge-weight: 8)
+</pre></div>
+</div>
+<p>The probability of branching from block A to block B is 7/15, and the
+probability of branching from block A to block C is 8/15.</p>
+<p>See <a class="reference internal" href="BranchWeightMetadata.html"><em>LLVM Branch Weight Metadata</em></a> for details about the branch weight IR
+representation.</p>
+</div>
+<div class="section" id="block-frequency">
+<h2><a class="toc-backref" href="#id4">Block Frequency</a><a class="headerlink" href="#block-frequency" title="Permalink to this headline">¶</a></h2>
+<p>Block frequency is a relative metric that represents the number of times a
+block executes. The ratio of a block frequency to the entry block frequency is
+the expected number of times the block will execute per entry to the function.</p>
+<p>Block frequency is the main output of the <tt class="docutils literal"><span class="pre">BlockFrequencyInfo</span></tt> and
+<tt class="docutils literal"><span class="pre">MachineBlockFrequencyInfo</span></tt> analysis passes.</p>
+</div>
+<div class="section" id="implementation-a-series-of-dags">
+<h2><a class="toc-backref" href="#id5">Implementation: a series of DAGs</a><a class="headerlink" href="#implementation-a-series-of-dags" title="Permalink to this headline">¶</a></h2>
+<p>The implementation of the block frequency calculation analyses each loop,
+bottom-up, ignoring backedges; i.e., as a DAG. After each loop is processed,
+it’s packaged up to act as a pseudo-node in its parent loop’s (or the
+function’s) DAG analysis.</p>
+</div>
+<div class="section" id="block-mass">
+<h2><a class="toc-backref" href="#id6">Block Mass</a><a class="headerlink" href="#block-mass" title="Permalink to this headline">¶</a></h2>
+<p>For each DAG, the entry node is assigned a mass of <tt class="docutils literal"><span class="pre">UINT64_MAX</span></tt> and mass is
+distributed to successors according to branch weights. Block Mass uses a
+fixed-point representation where <tt class="docutils literal"><span class="pre">UINT64_MAX</span></tt> represents <tt class="docutils literal"><span class="pre">1.0</span></tt> and <tt class="docutils literal"><span class="pre">0</span></tt>
+represents a number just above <tt class="docutils literal"><span class="pre">0.0</span></tt>.</p>
+<p>After mass is fully distributed, in any cut of the DAG that separates the exit
+nodes from the entry node, the sum of the block masses of the nodes succeeded
+by a cut edge should equal <tt class="docutils literal"><span class="pre">UINT64_MAX</span></tt>. In other words, mass is conserved
+as it “falls” through the DAG.</p>
+<p>If a function’s basic block graph is a DAG, then block masses are valid block
+frequencies. This works poorly in practise though, since downstream users rely
+on adding block frequencies together without hitting the maximum.</p>
+</div>
+<div class="section" id="loop-scale">
+<h2><a class="toc-backref" href="#id7">Loop Scale</a><a class="headerlink" href="#loop-scale" title="Permalink to this headline">¶</a></h2>
+<p>Loop scale is a metric that indicates how many times a loop iterates per entry.
+As mass is distributed through the loop’s DAG, the (otherwise ignored) backedge
+mass is collected. This backedge mass is used to compute the exit frequency,
+and thus the loop scale.</p>
+</div>
+<div class="section" id="implementation-getting-from-mass-and-scale-to-frequency">
+<h2><a class="toc-backref" href="#id8">Implementation: Getting from mass and scale to frequency</a><a class="headerlink" href="#implementation-getting-from-mass-and-scale-to-frequency" title="Permalink to this headline">¶</a></h2>
+<p>After analysing the complete series of DAGs, each block has a mass (local to
+its containing loop, if any), and each loop pseudo-node has a loop scale and
+its own mass (from its parent’s DAG).</p>
+<p>We can get an initial frequency assignment (with entry frequency of 1.0) by
+multiplying these masses and loop scales together. A given block’s frequency
+is the product of its mass, the mass of containing loops’ pseudo nodes, and the
+containing loops’ loop scales.</p>
+<p>Since downstream users need integers (not floating point), this initial
+frequency assignment is shifted as necessary into the range of <tt class="docutils literal"><span class="pre">uint64_t</span></tt>.</p>
+</div>
+<div class="section" id="block-bias">
+<h2><a class="toc-backref" href="#id9">Block Bias</a><a class="headerlink" href="#block-bias" title="Permalink to this headline">¶</a></h2>
+<p>Block bias is a proposed <em>absolute</em> metric to indicate a bias toward or away
+from a given block during a function’s execution. The idea is that bias can be
+used in isolation to indicate whether a block is relatively hot or cold, or to
+compare two blocks to indicate whether one is hotter or colder than the other.</p>
+<p>The proposed calculation involves calculating a <em>reference</em> block frequency,
+where:</p>
+<ul class="simple">
+<li>every branch weight is assumed to be 1 (i.e., every branch probability
+distribution is even) and</li>
+<li>loop scales are ignored.</li>
+</ul>
+<p>This reference frequency represents what the block frequency would be in an
+unbiased graph.</p>
+<p>The bias is the ratio of the block frequency to this reference block frequency.</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="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/BranchWeightMetadata.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/BranchWeightMetadata.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/BranchWeightMetadata.html (added)
+++ www-releases/trunk/3.9.0/docs/BranchWeightMetadata.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,228 @@
+
+<!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.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="LLVM bugpoint tool: design and usage" href="Bugpoint.html" />
+ <link rel="prev" title="LLVM Block Frequency Terminology" href="BlockFrequencyTerminology.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="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ 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>
+<li><a class="reference internal" href="#function-entry-counts" id="id11">Function Entry Counts</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
+(see <a class="reference internal" href="BlockFrequencyTerminology.html"><em>LLVM Block Frequency Terminology</em></a>). 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
+operands for the true and the false branch.</p>
+<div class="highlight-llvm"><div class="highlight"><pre>!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <TRUE_BRANCH_WEIGHT>,
+ i32 <FALSE_BRANCH_WEIGHT>
+}
+</pre></div>
+</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"><div class="highlight"><pre>!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <DEFAULT_BRANCH_WEIGHT>
+ [ , i32 <CASE_BRANCH_WEIGHT> ... ]
+}
+</pre></div>
+</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"><div class="highlight"><pre>!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <LABEL_BRANCH_WEIGHT>
+ [ , i32 <LABEL_BRANCH_WEIGHT> ... ]
+}
+</pre></div>
+</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 incorrect branch prediction information.</p>
+</div>
+<div class="section" id="function-entry-counts">
+<h2><a class="toc-backref" href="#id11">Function Entry Counts</a><a class="headerlink" href="#function-entry-counts" title="Permalink to this headline">¶</a></h2>
+<p>To allow comparing different functions during inter-procedural analysis and
+optimization, <tt class="docutils literal"><span class="pre">MD_prof</span></tt> nodes can also be assigned to a function definition.
+The first operand is a string indicating the name of the associated counter.</p>
+<p>Currently, one counter is supported: “function_entry_count”. This is a 64-bit
+counter that indicates the number of times that this function was invoked (in
+the case of instrumentation-based profiles). In the case of sampling-based
+profiles, this counter is an approximation of how many times the function was
+invoked.</p>
+<p>For example, in the code below, the instrumentation for function foo()
+indicates that it was called 2,590 times at runtime.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="k">i32</span> <span class="vg">@foo</span><span class="p">()</span> <span class="nv">!prof</span> <span class="nv-Anonymous">!1</span> <span class="p">{</span>
+ <span class="k">ret</span> <span class="k">i32</span> <span class="m">0</span>
+<span class="p">}</span>
+<span class="nv-Anonymous">!1</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"function_entry_count"</span><span class="p">,</span> <span class="k">i64</span> <span class="m">2590</span><span class="p">}</span>
+</pre></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="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/Bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/Bugpoint.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/Bugpoint.html (added)
+++ www-releases/trunk/3.9.0/docs/Bugpoint.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,294 @@
+
+<!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.9 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.9',
+ 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.9 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 internal" href="HowToSubmitABug.html"><em>How to submit an LLVM bug report</em></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 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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CMake.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CMake.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CMake.html (added)
+++ www-releases/trunk/3.9.0/docs/CMake.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,714 @@
+
+<!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.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="CMake Primer" href="CMakePrimer.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="CMakePrimer.html" title="CMake Primer"
+ 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="#cmake-caches" id="id11">CMake Caches</a></li>
+<li><a class="reference internal" href="#executing-the-test-suite" id="id12">Executing the test suite</a></li>
+<li><a class="reference internal" href="#cross-compiling" id="id13">Cross compiling</a></li>
+<li><a class="reference internal" href="#embedding-llvm-in-your-project" id="id14">Embedding LLVM in your project</a><ul>
+<li><a class="reference internal" href="#developing-llvm-passes-out-of-source" id="id15">Developing LLVM passes out of source</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#compiler-platform-specific-topics" id="id16">Compiler/Platform-specific topics</a><ul>
+<li><a class="reference internal" href="#microsoft-visual-c" id="id17">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 <strong>you are a new contributor</strong>, please start with the <a class="reference internal" href="GettingStarted.html"><em>Getting Started with the LLVM System</em></a>
+page. This page is geared for existing contributors moving from the
+legacy configure/make system.</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 with <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> section 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>
+<p>This page is geared towards users of the LLVM CMake build. If you’re looking for
+information about modifying the LLVM CMake build system you may want to see the
+<a class="reference internal" href="CMakePrimer.html"><em>CMake Primer</em></a> page. It has a basic overview of the CMake language.</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 3.4.3 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 build directory. Building LLVM in the source
+directory is not supported. 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 in 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 tests, 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
+a list of build parameters that you can modify.</p>
+<p>This can fail if CMake can’t detect your toolset, or if it thinks that the
+environment is not sane enough. In 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 your 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; for instructions, see the <a class="reference internal" href="#usage">Usage</a> section, below.</p>
+</li>
+<li><p class="first">After CMake has finished running, proceed to use IDE project files, or start
+the build from the build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake --build .
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">--build</span></tt> option tells <tt class="docutils literal"><span class="pre">cmake</span></tt> to invoke the underlying build
+tool (<tt class="docutils literal"><span class="pre">make</span></tt>, <tt class="docutils literal"><span class="pre">ninja</span></tt>, <tt class="docutils literal"><span class="pre">xcodebuild</span></tt>, <tt class="docutils literal"><span class="pre">msbuild</span></tt>, etc.)</p>
+<p>The underlying build tool can be invoked directly, of course, but
+the <tt class="docutils literal"><span class="pre">--build</span></tt> option is portable.</p>
+</li>
+<li><p class="first">After LLVM has finished building, install it from the build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake --build . --target install
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">--target</span></tt> option with <tt class="docutils literal"><span class="pre">install</span></tt> parameter in addition to
+the <tt class="docutils literal"><span class="pre">--build</span></tt> option tells <tt class="docutils literal"><span class="pre">cmake</span></tt> to build the <tt class="docutils literal"><span class="pre">install</span></tt> target.</p>
+<p>It is possible to set a different install prefix at installation time
+by invoking the <tt class="docutils literal"><span class="pre">cmake_install.cmake</span></tt> script generated in the
+build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -DCMAKE_INSTALL_PREFIX<span class="o">=</span>/tmp/llvm -P cmake_install.cmake
+</pre></div>
+</div>
+</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
+which you may need in your day-to-day usage.</p>
+<p>CMake comes with extensive documentation, in the form of html files, and as
+online help accessible via the <tt class="docutils literal"><span class="pre">cmake</span></tt> 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 allows you to specify a build tool (e.g., GNU make, Visual Studio,
+or Xcode). If not specified on the command line, CMake tries to guess which
+build tool to use, based on your environment. Once it has identified your
+build tool, CMake uses the corresponding <em>Generator</em> to create files for your
+build tool (e.g., Makefiles or Visual Studio or Xcode project files). 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>. To see a list of the available generators on your system, 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 names at the end of the help text.</p>
+<p>Generators’ names are case-sensitive, and may contain spaces. For this reason,
+you should enter them exactly as they are listed in the <tt class="docutils literal"><span class="pre">cmake</span> <span class="pre">--help</span></tt>
+output, in quotes. For example, to generate project files specifically for
+Visual Studio 12, you can execute:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -G <span class="s2">"Visual Studio 12"</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 most 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 to change 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 in the CMake cache. This is a file named <tt class="docutils literal"><span class="pre">CMakeCache.txt</span></tt>
+stored at the root of your build directory that is generated by <tt class="docutils literal"><span class="pre">cmake</span></tt>.
+Editing it yourself is not recommended.</p>
+<p>Variables are listed in the CMake cache and later in this document with
+the variable name and type separated by a colon. You can also specify the
+variable and 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 some of the CMake variables that are used often, along with a
+brief explanation and LLVM-specific notes. For full documentation, consult the
+CMake manual, 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. If you are using an IDE such as
+Visual Studio, you should use the IDE settings to set the build type.</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>
+</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 a tool separately by invoking its target. For
+example, you can build <em>llvm-as</em> with a Makefile-based system by executing <em>make
+llvm-as</em> at 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 this
+option to disable 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 this
+option to disable 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 using the
+targets defined under <em>unittests</em>, such as ADTTests, IRTests, SupportTests,
+etc. (Search for <tt class="docutils literal"><span class="pre">add_llvm_unittest</span></tt> in the subdirectories of <em>unittests</em>
+for a complete list of unit tests.) 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
+this option to disable 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_CXX1Y</strong>:BOOL</dt>
+<dd>Build in C++1y mode, if available. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_ASSERTIONS</strong>:BOOL</dt>
+<dd>Enables code assertions. Defaults to ON if and only if <tt class="docutils literal"><span class="pre">CMAKE_BUILD_TYPE</span></tt>
+is <em>Debug</em>.</dd>
+<dt><strong>LLVM_ENABLE_EH</strong>:BOOL</dt>
+<dd>Build LLVM with exception-handling support. This is necessary if you wish to
+link against LLVM libraries and make use of C++ exceptions in your own code
+that need to propagate through LLVM code. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_EXPENSIVE_CHECKS</strong>:BOOL</dt>
+<dd>Enable additional time/memory expensive checking. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_PIC</strong>:BOOL</dt>
+<dd>Add the <tt class="docutils literal"><span class="pre">-fPIC</span></tt> flag to 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_RTTI</strong>:BOOL</dt>
+<dd>Build LLVM with run-time type information. Defaults to OFF.</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 disables compiler-specific extensions, if
+possible. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_WERROR</strong>:BOOL</dt>
+<dd>Stop and fail the build, if a compiler warning is triggered. Defaults to OFF.</dd>
+<dt><strong>LLVM_ABI_BREAKING_CHECKS</strong>:STRING</dt>
+<dd>Used to decide if LLVM should be built with ABI breaking checks or
+not. Allowed values are <cite>WITH_ASSERTS</cite> (default), <cite>FORCE_ON</cite> and
+<cite>FORCE_OFF</cite>. <cite>WITH_ASSERTS</cite> turns on ABI breaking checks in an
+assertion enabled build. <cite>FORCE_ON</cite> (<cite>FORCE_OFF</cite>) turns them on
+(off) irrespective of whether normal (<cite>NDEBUG</cite>-based) assertions are
+enabled or not. A version of LLVM built with ABI breaking checks
+is not ABI compatible with a version built without it.</dd>
+<dt><strong>LLVM_BUILD_32_BITS</strong>:BOOL</dt>
+<dd>Build 32-bit executables and libraries on 64-bit systems. This option is
+available only on some 64-bit 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">llvm-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
+the empty string, in which case lit will look for tools needed for tests
+(e.g. <tt class="docutils literal"><span class="pre">grep</span></tt>, <tt class="docutils literal"><span class="pre">sort</span></tt>, etc.) in your %PATH%. If GnuWin32 is not in your
+%PATH%, then you can set this variable to the GnuWin32 directory so that
+lit can find tools needed for tests in that directory.</dd>
+<dt><strong>LLVM_ENABLE_FFI</strong>:BOOL</dt>
+<dd>Indicates whether the LLVM Interpreter will be linked with the Foreign Function
+Interface library (libffi) in order to enable calling external functions.
+If the library or its headers are installed in a custom
+location, you can also set the variables FFI_INCLUDE_DIR and
+FFI_LIBRARY_DIR to the directories where ffi.h and libffi.so can be found,
+respectively. Defaults to OFF.</dd>
+<dt><strong>LLVM_EXTERNAL_{CLANG,LLD,POLLY}_SOURCE_DIR</strong>:PATH</dt>
+<dd>These variables specify the path to the source directory for the external
+LLVM projects Clang, lld, and Polly, respectively, relative to the top-level
+source directory. If the in-tree subdirectory for an external project
+exists (e.g., llvm/tools/clang for Clang), then the corresponding variable
+will not be used. If the variable for an external project does not point
+to a valid path, then that project will not be built.</dd>
+<dt><strong>LLVM_EXTERNAL_PROJECTS</strong>:STRING</dt>
+<dd>Semicolon-separated list of additional external projects to build as part of
+llvm. For each project LLVM_EXTERNAL_<NAME>_SOURCE_DIR have to be specified
+with the path for the source code of the project. Example:
+<tt class="docutils literal"><span class="pre">-DLLVM_EXTERNAL_PROJECTS="Foo;Bar"</span>
+<span class="pre">-DLLVM_EXTERNAL_FOO_SOURCE_DIR=/src/foo</span>
+<span class="pre">-DLLVM_EXTERNAL_BAR_SOURCE_DIR=/src/bar</span></tt>.</dd>
+<dt><strong>LLVM_USE_OPROFILE</strong>:BOOL</dt>
+<dd>Enable building OProfile JIT support. Defaults to OFF.</dd>
+<dt><strong>LLVM_PROFDATA_FILE</strong>:PATH</dt>
+<dd>Path to a profdata file to pass into clang’s -fprofile-instr-use flag. This
+can only be specified if you’re building with clang.</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>Enable building 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>, <tt class="docutils literal"><span class="pre">MemoryWithOrigins</span></tt>, <tt class="docutils literal"><span class="pre">Undefined</span></tt>, <tt class="docutils literal"><span class="pre">Thread</span></tt>,
+and <tt class="docutils literal"><span class="pre">Address;Undefined</span></tt>. Defaults to empty string.</dd>
+<dt><strong>LLVM_ENABLE_LTO</strong>:STRING</dt>
+<dd>Add <tt class="docutils literal"><span class="pre">-flto</span></tt> or <tt class="docutils literal"><span class="pre">-flto=</span></tt> flags to the compile and link command
+lines, enabling link-time optimization. Possible values are <tt class="docutils literal"><span class="pre">Off</span></tt>,
+<tt class="docutils literal"><span class="pre">On</span></tt>, <tt class="docutils literal"><span class="pre">Thin</span></tt> and <tt class="docutils literal"><span class="pre">Full</span></tt>. Defaults to OFF.</dd>
+<dt><strong>LLVM_PARALLEL_COMPILE_JOBS</strong>:STRING</dt>
+<dd>Define the maximum number of concurrent compilation jobs.</dd>
+<dt><strong>LLVM_PARALLEL_LINK_JOBS</strong>:STRING</dt>
+<dd>Define the maximum number of concurrent link jobs.</dd>
+<dt><strong>LLVM_BUILD_DOCS</strong>:BOOL</dt>
+<dd>Adds all <em>enabled</em> documentation targets (i.e. Doxgyen and Sphinx targets) as
+dependencies of the default build targets. This results in all of the (enabled)
+documentation targets being as part of a normal build. If the <tt class="docutils literal"><span class="pre">install</span></tt>
+target is run then this also enables all built documentation targets to be
+installed. Defaults to OFF. To enable a particular documentation target, see
+see LLVM_ENABLE_SPHINX and LLVM_ENABLE_DOXYGEN.</dd>
+<dt><strong>LLVM_ENABLE_DOXYGEN</strong>:BOOL</dt>
+<dd>Enables the generation of browsable HTML documentation using doxygen.
+Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_DOXYGEN_QT_HELP</strong>:BOOL</dt>
+<dd>Enables the generation of a Qt Compressed Help file. Defaults to OFF.
+This affects the make target <tt class="docutils literal"><span class="pre">doxygen-llvm</span></tt>. When enabled, apart from
+the normal HTML output generated by doxygen, this will produce a QCH file
+named <tt class="docutils literal"><span class="pre">org.llvm.qch</span></tt>. You can then load this file into Qt Creator.
+This option is only useful in combination with <tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN=ON</span></tt>;
+otherwise this has no effect.</dd>
+<dt><strong>LLVM_DOXYGEN_QCH_FILENAME</strong>:STRING</dt>
+<dd>The filename of the Qt Compressed Help file that will be generated when
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN=ON</span></tt> and
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt> are given. Defaults to
+<tt class="docutils literal"><span class="pre">org.llvm.qch</span></tt>.
+This option is only useful in combination with
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>;
+otherwise it has no effect.</dd>
+<dt><strong>LLVM_DOXYGEN_QHP_NAMESPACE</strong>:STRING</dt>
+<dd>Namespace under which the intermediate Qt Help Project file lives. See <a class="reference external" href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters">Qt
+Help Project</a>
+for more information. Defaults to “org.llvm”. This option is only useful in
+combination with <tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>; otherwise
+it has no effect.</dd>
+<dt><strong>LLVM_DOXYGEN_QHP_CUST_FILTER_NAME</strong>:STRING</dt>
+<dd>See <a class="reference external" href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters">Qt Help Project</a> for
+more information. Defaults to the CMake variable <tt class="docutils literal"><span class="pre">${PACKAGE_STRING}</span></tt> which
+is a combination of the package name and version string. This filter can then
+be used in Qt Creator to select only documentation from LLVM when browsing
+through all the help files that you might have loaded. This option is only
+useful in combination with <tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>;
+otherwise it has no effect.</dd>
+</dl>
+<dl class="docutils">
+<dt><strong>LLVM_DOXYGEN_QHELPGENERATOR_PATH</strong>:STRING</dt>
+<dd>The path to the <tt class="docutils literal"><span class="pre">qhelpgenerator</span></tt> executable. Defaults to whatever CMake’s
+<tt class="docutils literal"><span class="pre">find_program()</span></tt> can find. This option is only useful in combination with
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>; otherwise it has no
+effect.</dd>
+<dt><strong>LLVM_DOXYGEN_SVG</strong>:BOOL</dt>
+<dd>Uses .svg files instead of .png files for graphs in the Doxygen output.
+Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_SPHINX</strong>:BOOL</dt>
+<dd>If specified, CMake will search for the <tt class="docutils literal"><span class="pre">sphinx-build</span></tt> executable and will make
+the <tt class="docutils literal"><span class="pre">SPHINX_OUTPUT_HTML</span></tt> and <tt class="docutils literal"><span class="pre">SPHINX_OUTPUT_MAN</span></tt> CMake options available.
+Defaults to OFF.</dd>
+<dt><strong>SPHINX_EXECUTABLE</strong>:STRING</dt>
+<dd>The path to the <tt class="docutils literal"><span class="pre">sphinx-build</span></tt> executable detected by CMake.</dd>
+<dt><strong>SPHINX_OUTPUT_HTML</strong>:BOOL</dt>
+<dd>If enabled (and <tt class="docutils literal"><span class="pre">LLVM_ENABLE_SPHINX</span></tt> is enabled) then the targets for
+building the documentation as html are added (but not built by default unless
+<tt class="docutils literal"><span class="pre">LLVM_BUILD_DOCS</span></tt> is enabled). There is a target for each project in the
+source tree that uses sphinx (e.g. <tt class="docutils literal"><span class="pre">docs-llvm-html</span></tt>, <tt class="docutils literal"><span class="pre">docs-clang-html</span></tt>
+and <tt class="docutils literal"><span class="pre">docs-lld-html</span></tt>). Defaults to ON.</dd>
+<dt><strong>SPHINX_OUTPUT_MAN</strong>:BOOL</dt>
+<dd>If enabled (and <tt class="docutils literal"><span class="pre">LLVM_ENABLE_SPHINX</span></tt> is enabled) the targets for building
+the man pages are added (but not built by default unless <tt class="docutils literal"><span class="pre">LLVM_BUILD_DOCS</span></tt>
+is enabled). Currently the only target added is <tt class="docutils literal"><span class="pre">docs-llvm-man</span></tt>. Defaults
+to ON.</dd>
+<dt><strong>SPHINX_WARNINGS_AS_ERRORS</strong>:BOOL</dt>
+<dd>If enabled then sphinx documentation warnings will be treated as
+errors. Defaults to ON.</dd>
+<dt><strong>LLVM_CREATE_XCODE_TOOLCHAIN</strong>:BOOL</dt>
+<dd>OS X Only: If enabled CMake will generate a target named
+‘install-xcode-toolchain’. This target will create a directory at
+$CMAKE_INSTALL_PREFIX/Toolchains containing an xctoolchain directory which can
+be used to override the default system tools.</dd>
+<dt><strong>LLVM_BUILD_LLVM_DYLIB</strong>:BOOL</dt>
+<dd>If enabled, the target for building the libLLVM shared library is added.
+This library contains all of LLVM’s components in a single shared library.
+Defaults to OFF. This cannot be used in conjunction with BUILD_SHARED_LIBS.
+Tools will only be linked to the libLLVM shared library if LLVM_LINK_LLVM_DYLIB
+is also ON.
+The components in the library can be customised by setting LLVM_DYLIB_COMPONENTS
+to a list of the desired components.</dd>
+<dt><strong>LLVM_LINK_LLVM_DYLIB</strong>:BOOL</dt>
+<dd>If enabled, tools will be linked with the libLLVM shared library. Defaults
+to OFF. Setting LLVM_LINK_LLVM_DYLIB to ON also sets LLVM_BUILD_LLVM_DYLIB
+to ON.</dd>
+<dt><strong>BUILD_SHARED_LIBS</strong>:BOOL</dt>
+<dd><p class="first">Flag indicating if each LLVM component (e.g. Support) is built as a shared
+library (ON) or as a static library (OFF). Its default value is OFF. On
+Windows, shared libraries may be used when building with MinGW, including
+mingw-w64, but not when building with the Microsoft toolchain.</p>
+<div class="last admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">BUILD_SHARED_LIBS is only recommended for use by LLVM developers.
+If you want to build LLVM as a shared library, you should use the
+<tt class="docutils literal"><span class="pre">LLVM_BUILD_LLVM_DYLIB</span></tt> option.</p>
+</div>
+</dd>
+<dt><strong>LLVM_OPTIMIZED_TABLEGEN</strong>:BOOL</dt>
+<dd>If enabled and building a debug or asserts build the CMake build system will
+generate a Release build tree to build a fully optimized tablegen for use
+during the build. Enabling this option can significantly speed up build times
+especially when building LLVM in Debug configurations.</dd>
+</dl>
+</div>
+</div>
+<div class="section" id="cmake-caches">
+<h2><a class="toc-backref" href="#id11">CMake Caches</a><a class="headerlink" href="#cmake-caches" title="Permalink to this headline">¶</a></h2>
+<p>Recently LLVM and Clang have been adding some more complicated build system
+features. Utilizing these new features often involves a complicated chain of
+CMake variables passed on the command line. Clang provides a collection of CMake
+cache scripts to make these features more approachable.</p>
+<p>CMake cache files are utilized using CMake’s -C flag:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -C <path to cache file> <path to sources>
+</pre></div>
+</div>
+<p>CMake cache scripts are processed in an isolated scope, only cached variables
+remain set when the main configuration runs. CMake cached variables do not reset
+variables that are already set unless the FORCE option is specified.</p>
+<p>A few notes about CMake Caches:</p>
+<ul class="simple">
+<li>Order of command line arguments is important<ul>
+<li>-D arguments specified before -C are set before the cache is processed and
+can be read inside the cache file</li>
+<li>-D arguments specified after -C are set after the cache is processed and
+are unset inside the cache file</li>
+</ul>
+</li>
+<li>All -D arguments will override cache file settings</li>
+<li>CMAKE_TOOLCHAIN_FILE is evaluated after both the cache file and the command
+line arguments</li>
+<li>It is recommended that all -D options should be specified <em>before</em> -C</li>
+</ul>
+<p>For more information about some of the advanced build configurations supported
+via Cache files see <a class="reference internal" href="AdvancedBuilds.html"><em>Advanced Build Configurations</em></a>.</p>
+</div>
+<div class="section" id="executing-the-test-suite">
+<h2><a class="toc-backref" href="#id12">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-all</em> target is built. For instance, if you are
+using Makefiles, execute this command in the root of your build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> make check-all
+</pre></div>
+</div>
+<p>On Visual Studio, you may run tests by building the project “check-all”.
+For more information about testing, see the <a class="reference internal" href="TestingGuide.html"><em>LLVM Testing Infrastructure Guide</em></a>.</p>
+</div>
+<div class="section" id="cross-compiling">
+<h2><a class="toc-backref" href="#id13">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="#id14">Embedding LLVM in your project</a><a class="headerlink" href="#embedding-llvm-in-your-project" title="Permalink to this headline">¶</a></h2>
+<p>From LLVM 3.5 onwards both the CMake and autoconf/Makefile build systems export
+LLVM libraries as importable CMake targets. This means that clients of LLVM can
+now reliably use CMake to develop their own LLVM-based projects against an
+installed version of LLVM regardless of how it was built.</p>
+<p>Here is a simple example of a CMakeLists.txt file that imports the LLVM libraries
+and uses them to build a simple application <tt class="docutils literal"><span class="pre">simple-tool</span></tt>.</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">cmake_minimum_required</span><span class="p">(</span><span class="s">VERSION</span> <span class="s">3.4.3</span><span class="p">)</span>
+<span class="nb">project</span><span class="p">(</span><span class="s">SimpleProject</span><span class="p">)</span>
+
+<span class="nb">find_package</span><span class="p">(</span><span class="s">LLVM</span> <span class="s">REQUIRED</span> <span class="s">CONFIG</span><span class="p">)</span>
+
+<span class="nb">message</span><span class="p">(</span><span class="s">STATUS</span> <span class="s2">"Found LLVM ${LLVM_PACKAGE_VERSION}"</span><span class="p">)</span>
+<span class="nb">message</span><span class="p">(</span><span class="s">STATUS</span> <span class="s2">"Using LLVMConfig.cmake in: ${LLVM_DIR}"</span><span class="p">)</span>
+
+<span class="c"># Set your project compile flags.</span>
+<span class="c"># E.g. if using the C++ header files</span>
+<span class="c"># you will need to enable C++11 support</span>
+<span class="c"># for your compiler.</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">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"># Now build our tools</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">simple-tool</span> <span class="s">tool.cpp</span><span class="p">)</span>
+
+<span class="c"># Find the libraries that correspond to the LLVM components</span>
+<span class="c"># that we wish to use</span>
+<span class="nb">llvm_map_components_to_libnames</span><span class="p">(</span><span class="s">llvm_libs</span> <span class="s">support</span> <span class="s">core</span> <span class="s">irreader</span><span class="p">)</span>
+
+<span class="c"># Link against LLVM libraries</span>
+<span class="nb">target_link_libraries</span><span class="p">(</span><span class="s">simple-tool</span> <span class="o">${</span><span class="nv">llvm_libs</span><span class="o">}</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">find_package(...)</span></tt> directive when used in CONFIG mode (as in the above
+example) will look for the <tt class="docutils literal"><span class="pre">LLVMConfig.cmake</span></tt> file in various locations (see
+cmake manual for details). It creates a <tt class="docutils literal"><span class="pre">LLVM_DIR</span></tt> cache entry to save the
+directory where <tt class="docutils literal"><span class="pre">LLVMConfig.cmake</span></tt> is found or allows the user to specify the
+directory (e.g. by passing <tt class="docutils literal"><span class="pre">-DLLVM_DIR=/usr/lib/cmake/llvm</span></tt> to
+the <tt class="docutils literal"><span class="pre">cmake</span></tt> command or by setting it directly in <tt class="docutils literal"><span class="pre">ccmake</span></tt> or <tt class="docutils literal"><span class="pre">cmake-gui</span></tt>).</p>
+<p>This file is available in two different locations.</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre"><INSTALL_PREFIX>/lib/cmake/llvm/LLVMConfig.cmake</span></tt> where
+<tt class="docutils literal"><span class="pre"><INSTALL_PREFIX></span></tt> is the install prefix of an installed version of LLVM.
+On Linux typically this is <tt class="docutils literal"><span class="pre">/usr/lib/cmake/llvm/LLVMConfig.cmake</span></tt>.</li>
+<li><tt class="docutils literal"><span class="pre"><LLVM_BUILD_ROOT>/lib/cmake/llvm/LLVMConfig.cmake</span></tt> where
+<tt class="docutils literal"><span class="pre"><LLVM_BUILD_ROOT></span></tt> is the root of the LLVM build tree. <strong>Note: this is only
+available when building LLVM with CMake.</strong></li>
+</ul>
+<p>If LLVM is installed in your operating system’s normal installation prefix (e.g.
+on Linux this is usually <tt class="docutils literal"><span class="pre">/usr/</span></tt>) <tt class="docutils literal"><span class="pre">find_package(LLVM</span> <span class="pre">...)</span></tt> will
+automatically find LLVM if it is installed correctly. If LLVM is not installed
+or you wish to build directly against the LLVM build tree you can use
+<tt class="docutils literal"><span class="pre">LLVM_DIR</span></tt> as previously mentioned.</p>
+<p>The <tt class="docutils literal"><span class="pre">LLVMConfig.cmake</span></tt> file sets various useful variables. Notable variables
+include</p>
+<dl class="docutils">
+<dt><tt class="docutils literal"><span class="pre">LLVM_CMAKE_DIR</span></tt></dt>
+<dd>The path to the LLVM CMake directory (i.e. the directory containing
+LLVMConfig.cmake).</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_DEFINITIONS</span></tt></dt>
+<dd>A list of preprocessor defines that should be used when building against LLVM.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_ENABLE_ASSERTIONS</span></tt></dt>
+<dd>This is set to ON if LLVM was built with assertions, otherwise OFF.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_ENABLE_EH</span></tt></dt>
+<dd>This is set to ON if LLVM was built with exception handling (EH) enabled,
+otherwise OFF.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_ENABLE_RTTI</span></tt></dt>
+<dd>This is set to ON if LLVM was built with run time type information (RTTI),
+otherwise OFF.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_INCLUDE_DIRS</span></tt></dt>
+<dd>A list of include paths to directories containing LLVM header files.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_PACKAGE_VERSION</span></tt></dt>
+<dd>The LLVM version. This string can be used with CMake conditionals, e.g., <tt class="docutils literal"><span class="pre">if</span>
+<span class="pre">(${LLVM_PACKAGE_VERSION}</span> <span class="pre">VERSION_LESS</span> <span class="pre">"3.5")</span></tt>.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_TOOLS_BINARY_DIR</span></tt></dt>
+<dd>The path to the directory containing the LLVM tools (e.g. <tt class="docutils literal"><span class="pre">llvm-as</span></tt>).</dd>
+</dl>
+<p>Notice that in the above example we link <tt class="docutils literal"><span class="pre">simple-tool</span></tt> against several LLVM
+libraries. The list of libraries is determined by using the
+<tt class="docutils literal"><span class="pre">llvm_map_components_to_libnames()</span></tt> CMake function. For a list of available
+components look at the output of running <tt class="docutils literal"><span class="pre">llvm-config</span> <span class="pre">--components</span></tt>.</p>
+<p>Note that for LLVM < 3.5 <tt class="docutils literal"><span class="pre">llvm_map_components_to_libraries()</span></tt> was
+used instead of <tt class="docutils literal"><span class="pre">llvm_map_components_to_libnames()</span></tt>. This is now deprecated
+and will be removed in a future version of LLVM.</p>
+<div class="section" id="developing-llvm-passes-out-of-source">
+<span id="cmake-out-of-source-pass"></span><h3><a class="toc-backref" href="#id15">Developing LLVM passes out of source</a><a class="headerlink" href="#developing-llvm-passes-out-of-source" title="Permalink to this headline">¶</a></h3>
+<p>It is possible to develop LLVM passes out of LLVM’s source tree (i.e. against an
+installed or built LLVM). An example of a project layout is 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="s">REQUIRED</span> <span class="s">CONFIG</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">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_library</span><span class="p">(</span><span class="s">LLVMPassname</span> <span class="s">MODULE</span> <span class="s">Pass.cpp</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>Note if you intend for this pass to be merged into the LLVM source tree at some
+point in the future it might make more sense to use LLVM’s internal
+<tt class="docutils literal"><span class="pre">add_llvm_loadable_module</span></tt> function instead by...</p>
+<p>Adding the following to <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/CMakeLists.txt</span></tt> (after
+<tt class="docutils literal"><span class="pre">find_package(LLVM</span> <span class="pre">...)</span></tt>)</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">list</span><span class="p">(</span><span class="s">APPEND</span> <span class="s">CMAKE_MODULE_PATH</span> <span class="s2">"${LLVM_CMAKE_DIR}"</span><span class="p">)</span>
+<span class="nb">include</span><span class="p">(</span><span class="s">AddLLVM</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>And then changing <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/<pass</span> <span class="pre">name>/CMakeLists.txt</span></tt> to</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 the 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="#id16">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="#id17">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 parallel 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="CMakePrimer.html" title="CMake Primer"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CMakePrimer.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CMakePrimer.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CMakePrimer.html (added)
+++ www-releases/trunk/3.9.0/docs/CMakePrimer.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,523 @@
+
+<!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>CMake Primer — LLVM 3.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="Advanced Build Configurations" href="AdvancedBuilds.html" />
+ <link rel="prev" title="Building LLVM with CMake" href="CMake.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="AdvancedBuilds.html" title="Advanced Build Configurations"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="CMake.html" title="Building LLVM with CMake"
+ 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="cmake-primer">
+<h1>CMake Primer<a class="headerlink" href="#cmake-primer" 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="#ft-view" id="id2">10,000 ft View</a></li>
+<li><a class="reference internal" href="#scripting-overview" id="id3">Scripting Overview</a></li>
+<li><a class="reference internal" href="#variables-types-and-scope" id="id4">Variables, Types, and Scope</a><ul>
+<li><a class="reference internal" href="#dereferencing" id="id5">Dereferencing</a></li>
+<li><a class="reference internal" href="#lists" id="id6">Lists</a></li>
+<li><a class="reference internal" href="#lists-of-lists" id="id7">Lists of Lists</a></li>
+<li><a class="reference internal" href="#other-types" id="id8">Other Types</a></li>
+<li><a class="reference internal" href="#scope" id="id9">Scope</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#control-flow" id="id10">Control Flow</a><ul>
+<li><a class="reference internal" href="#if-elseif-else" id="id11">If, ElseIf, Else</a></li>
+<li><a class="reference internal" href="#loops" id="id12">Loops</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#modules-functions-and-macros" id="id13">Modules, Functions and Macros</a><ul>
+<li><a class="reference internal" href="#modules" id="id14">Modules</a></li>
+<li><a class="reference internal" href="#argument-handling" id="id15">Argument Handling</a></li>
+<li><a class="reference internal" href="#functions-vs-macros" id="id16">Functions Vs Macros</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#llvm-project-wrappers" id="id17">LLVM Project Wrappers</a></li>
+<li><a class="reference internal" href="#useful-built-in-commands" id="id18">Useful Built-in Commands</a></li>
+</ul>
+</div>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">Disclaimer: This documentation is written by LLVM project contributors <cite>not</cite>
+anyone affiliated with the CMake project. This document may contain
+inaccurate terminology, phrasing, or technical details. It is provided with
+the best intentions.</p>
+</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>The LLVM project and many of the core projects built on LLVM build using CMake.
+This document aims to provide a brief overview of CMake for developers modifying
+LLVM projects or building their own projects on top of LLVM.</p>
+<p>The official CMake language references is available in the cmake-language
+manpage and <a class="reference external" href="https://cmake.org/cmake/help/v3.4/manual/cmake-language.7.html">cmake-language online documentation</a>.</p>
+</div>
+<div class="section" id="ft-view">
+<h2><a class="toc-backref" href="#id2">10,000 ft View</a><a class="headerlink" href="#ft-view" title="Permalink to this headline">¶</a></h2>
+<p>CMake is a tool that reads script files in its own language that describe how a
+software project builds. As CMake evaluates the scripts it constructs an
+internal representation of the software project. Once the scripts have been
+fully processed, if there are no errors, CMake will generate build files to
+actually build the project. CMake supports generating build files for a variety
+of command line build tools as well as for popular IDEs.</p>
+<p>When a user runs CMake it performs a variety of checks similar to how autoconf
+worked historically. During the checks and the evaluation of the build
+description scripts CMake caches values into the CMakeCache. This is useful
+because it allows the build system to skip long-running checks during
+incremental development. CMake caching also has some drawbacks, but that will be
+discussed later.</p>
+</div>
+<div class="section" id="scripting-overview">
+<h2><a class="toc-backref" href="#id3">Scripting Overview</a><a class="headerlink" href="#scripting-overview" title="Permalink to this headline">¶</a></h2>
+<p>CMake’s scripting language has a very simple grammar. Every language construct
+is a command that matches the pattern _name_(_args_). Commands come in three
+primary types: language-defined (commands implemented in C++ in CMake), defined
+functions, and defined macros. The CMake distribution also contains a suite of
+CMake modules that contain definitions for useful functionality.</p>
+<p>The example below is the full CMake build for building a C++ “Hello World”
+program. The example uses only CMake language-defined functions.</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">cmake_minimum_required</span><span class="p">(</span><span class="s">VERSION</span> <span class="s">3.2</span><span class="p">)</span>
+<span class="nb">project</span><span class="p">(</span><span class="s">HelloWorld</span><span class="p">)</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">HelloWorld.cpp</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>The CMake language provides control flow constructs in the form of foreach loops
+and if blocks. To make the example above more complicated you could add an if
+block to define “APPLE” when targeting Apple platforms:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">cmake_minimum_required</span><span class="p">(</span><span class="s">VERSION</span> <span class="s">3.2</span><span class="p">)</span>
+<span class="nb">project</span><span class="p">(</span><span class="s">HelloWorld</span><span class="p">)</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">HelloWorld.cpp</span><span class="p">)</span>
+<span class="nb">if</span><span class="p">(</span><span class="s">APPLE</span><span class="p">)</span>
+ <span class="nb">target_compile_definitions</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">PUBLIC</span> <span class="s">APPLE</span><span class="p">)</span>
+<span class="nb">endif</span><span class="p">()</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="variables-types-and-scope">
+<h2><a class="toc-backref" href="#id4">Variables, Types, and Scope</a><a class="headerlink" href="#variables-types-and-scope" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="dereferencing">
+<h3><a class="toc-backref" href="#id5">Dereferencing</a><a class="headerlink" href="#dereferencing" title="Permalink to this headline">¶</a></h3>
+<p>In CMake variables are “stringly” typed. All variables are represented as
+strings throughout evaluation. Wrapping a variable in <tt class="docutils literal"><span class="pre">${}</span></tt> dereferences it
+and results in a literal substitution of the name for the value. CMake refers to
+this as “variable evaluation” in their documentation. Dereferences are performed
+<em>before</em> the command being called receives the arguments. This means
+dereferencing a list results in multiple separate arguments being passed to the
+command.</p>
+<p>Variable dereferences can be nested and be used to model complex data. For
+example:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">set</span><span class="p">(</span><span class="s">var_name</span> <span class="s">var1</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="o">${</span><span class="nv">var_name</span><span class="o">}</span> <span class="s">foo</span><span class="p">)</span> <span class="c"># same as "set(var1 foo)"</span>
+<span class="nb">set</span><span class="p">(</span><span class="o">${</span><span class="nv">${var_name</span><span class="o">}</span><span class="s">}_var</span> <span class="s">bar</span><span class="p">)</span> <span class="c"># same as "set(foo_var bar)"</span>
+</pre></div>
+</div>
+<p>Dereferencing an unset variable results in an empty expansion. It is a common
+pattern in CMake to conditionally set variables knowing that it will be used in
+code paths that the variable isn’t set. There are examples of this throughout
+the LLVM CMake build system.</p>
+<p>An example of variable empty expansion is:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">if</span><span class="p">(</span><span class="s">APPLE</span><span class="p">)</span>
+ <span class="nb">set</span><span class="p">(</span><span class="s">extra_sources</span> <span class="s">Apple.cpp</span><span class="p">)</span>
+<span class="nb">endif</span><span class="p">()</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">HelloWorld.cpp</span> <span class="o">${</span><span class="nv">extra_sources</span><span class="o">}</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>In this example the <tt class="docutils literal"><span class="pre">extra_sources</span></tt> variable is only defined if you’re
+targeting an Apple platform. For all other targets the <tt class="docutils literal"><span class="pre">extra_sources</span></tt> will be
+evaluated as empty before add_executable is given its arguments.</p>
+<p>One big “Gotcha” with variable dereferencing is that <tt class="docutils literal"><span class="pre">if</span></tt> commands implicitly
+dereference values. This has some unexpected results. For example:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">if</span><span class="p">(</span><span class="s2">"${SOME_VAR}"</span> <span class="s">STREQUAL</span> <span class="s2">"MSVC"</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>In this code sample MSVC will be implicitly dereferenced, which will result in
+the if command comparing the value of the dereferenced variables <tt class="docutils literal"><span class="pre">SOME_VAR</span></tt>
+and <tt class="docutils literal"><span class="pre">MSVC</span></tt>. A common workaround to this solution is to prepend strings being
+compared with an <tt class="docutils literal"><span class="pre">x</span></tt>.</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">if</span><span class="p">(</span><span class="s2">"x${SOME_VAR}"</span> <span class="s">STREQUAL</span> <span class="s2">"xMSVC"</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>This works because while <tt class="docutils literal"><span class="pre">MSVC</span></tt> is a defined variable, <tt class="docutils literal"><span class="pre">xMSVC</span></tt> is not. This
+pattern is uncommon, but it does occur in LLVM’s CMake scripts.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Once the LLVM project upgrades its minimum CMake version to 3.1 or later we
+can prevent this behavior by setting CMP0054 to new. For more information on
+CMake policies please see the cmake-policies manpage or the <a class="reference external" href="https://cmake.org/cmake/help/v3.4/manual/cmake-policies.7.html">cmake-policies
+online documentation</a>.</p>
+</div>
+</div>
+<div class="section" id="lists">
+<h3><a class="toc-backref" href="#id6">Lists</a><a class="headerlink" href="#lists" title="Permalink to this headline">¶</a></h3>
+<p>In CMake lists are semi-colon delimited strings, and it is strongly advised that
+you avoid using semi-colons in lists; it doesn’t go smoothly. A few examples of
+defining lists:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="c"># Creates a list with members a, b, c, and d</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">a</span> <span class="s">b</span> <span class="s">c</span> <span class="s">d</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s2">"a;b;c;d"</span><span class="p">)</span>
+
+<span class="c"># Creates a string "a b c d"</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_string</span> <span class="s2">"a b c d"</span><span class="p">)</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="lists-of-lists">
+<h3><a class="toc-backref" href="#id7">Lists of Lists</a><a class="headerlink" href="#lists-of-lists" title="Permalink to this headline">¶</a></h3>
+<p>One of the more complicated patterns in CMake is lists of lists. Because a list
+cannot contain an element with a semi-colon to construct a list of lists you
+make a list of variable names that refer to other lists. For example:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">set</span><span class="p">(</span><span class="s">list_of_lists</span> <span class="s">a</span> <span class="s">b</span> <span class="s">c</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">a</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">b</span> <span class="s">4</span> <span class="s">5</span> <span class="s">6</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">c</span> <span class="s">7</span> <span class="s">8</span> <span class="s">9</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>With this layout you can iterate through the list of lists printing each value
+with the following code:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">foreach</span><span class="p">(</span><span class="s">list_name</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">list_of_lists</span><span class="p">)</span>
+ <span class="nb">foreach</span><span class="p">(</span><span class="s">value</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="o">${</span><span class="nv">list_name</span><span class="o">}</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">value</span><span class="o">}</span><span class="p">)</span>
+ <span class="nb">endforeach</span><span class="p">()</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+</pre></div>
+</div>
+<p>You’ll notice that the inner foreach loop’s list is doubly dereferenced. This is
+because the first dereference turns <tt class="docutils literal"><span class="pre">list_name</span></tt> into the name of the sub-list
+(a, b, or c in the example), then the second dereference is to get the value of
+the list.</p>
+<p>This pattern is used throughout CMake, the most common example is the compiler
+flags options, which CMake refers to using the following variable expansions:
+CMAKE_${LANGUAGE}_FLAGS and CMAKE_${LANGUAGE}_FLAGS_${CMAKE_BUILD_TYPE}.</p>
+</div>
+<div class="section" id="other-types">
+<h3><a class="toc-backref" href="#id8">Other Types</a><a class="headerlink" href="#other-types" title="Permalink to this headline">¶</a></h3>
+<p>Variables that are cached or specified on the command line can have types
+associated with them. The variable’s type is used by CMake’s UI tool to display
+the right input field. The variable’s type generally doesn’t impact evaluation.
+One of the few examples is PATH variables, which CMake does have some special
+handling for. You can read more about the special handling in <a class="reference external" href="https://cmake.org/cmake/help/v3.5/command/set.html#set-cache-entry">CMake’s set
+documentation</a>.</p>
+</div>
+<div class="section" id="scope">
+<h3><a class="toc-backref" href="#id9">Scope</a><a class="headerlink" href="#scope" title="Permalink to this headline">¶</a></h3>
+<p>CMake inherently has a directory-based scoping. Setting a variable in a
+CMakeLists file, will set the variable for that file, and all subdirectories.
+Variables set in a CMake module that is included in a CMakeLists file will be
+set in the scope they are included from, and all subdirectories.</p>
+<p>When a variable that is already set is set again in a subdirectory it overrides
+the value in that scope and any deeper subdirectories.</p>
+<p>The CMake set command provides two scope-related options. PARENT_SCOPE sets a
+variable into the parent scope, and not the current scope. The CACHE option sets
+the variable in the CMakeCache, which results in it being set in all scopes. The
+CACHE option will not set a variable that already exists in the CACHE unless the
+FORCE option is specified.</p>
+<p>In addition to directory-based scope, CMake functions also have their own scope.
+This means variables set inside functions do not bleed into the parent scope.
+This is not true of macros, and it is for this reason LLVM prefers functions
+over macros whenever reasonable.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Unlike C-based languages, CMake’s loop and control flow blocks do not have
+their own scopes.</p>
+</div>
+</div>
+</div>
+<div class="section" id="control-flow">
+<h2><a class="toc-backref" href="#id10">Control Flow</a><a class="headerlink" href="#control-flow" title="Permalink to this headline">¶</a></h2>
+<p>CMake features the same basic control flow constructs you would expect in any
+scripting language, but there are a few quarks because, as with everything in
+CMake, control flow constructs are commands.</p>
+<div class="section" id="if-elseif-else">
+<h3><a class="toc-backref" href="#id11">If, ElseIf, Else</a><a class="headerlink" href="#if-elseif-else" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">For the full documentation on the CMake if command go
+<a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/if.html">here</a>. That resource is
+far more complete.</p>
+</div>
+<p>In general CMake if blocks work the way you’d expect:</p>
+<div class="highlight-cmake"><div class="highlight"><pre>if(<condition>)
+ .. do stuff
+elseif(<condition>)
+ .. do other stuff
+else()
+ .. do other other stuff
+endif()
+</pre></div>
+</div>
+<p>The single most important thing to know about CMake’s if blocks coming from a C
+background is that they do not have their own scope. Variables set inside
+conditional blocks persist after the <tt class="docutils literal"><span class="pre">endif()</span></tt>.</p>
+</div>
+<div class="section" id="loops">
+<h3><a class="toc-backref" href="#id12">Loops</a><a class="headerlink" href="#loops" title="Permalink to this headline">¶</a></h3>
+<p>The most common form of the CMake <tt class="docutils literal"><span class="pre">foreach</span></tt> block is:</p>
+<div class="highlight-cmake"><div class="highlight"><pre>foreach(var ...)
+ .. do stuff
+endforeach()
+</pre></div>
+</div>
+<p>The variable argument portion of the <tt class="docutils literal"><span class="pre">foreach</span></tt> block can contain dereferenced
+lists, values to iterate, or a mix of both:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">foo</span> <span class="s">bar</span> <span class="s">baz</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># foo</span>
+<span class="c"># bar</span>
+<span class="c"># baz</span>
+
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span><span class="p">)</span>
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="o">${</span><span class="nv">my_list</span><span class="o">}</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="o">${</span><span class="nv">my_list</span><span class="o">}</span> <span class="s">out_of_bounds</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+<span class="c"># out_of_bounds</span>
+</pre></div>
+</div>
+<p>There is also a more modern CMake foreach syntax. The code below is equivalent
+to the code above:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">ITEMS</span> <span class="s">foo</span> <span class="s">bar</span> <span class="s">baz</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># foo</span>
+<span class="c"># bar</span>
+<span class="c"># baz</span>
+
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span><span class="p">)</span>
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">my_list</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">my_list</span> <span class="s">ITEMS</span> <span class="s">out_of_bounds</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+<span class="c"># out_of_bounds</span>
+</pre></div>
+</div>
+<p>Similar to the conditional statements, these generally behave how you would
+expect, and they do not have their own scope.</p>
+<p>CMake also supports <tt class="docutils literal"><span class="pre">while</span></tt> loops, although they are not widely used in LLVM.</p>
+</div>
+</div>
+<div class="section" id="modules-functions-and-macros">
+<h2><a class="toc-backref" href="#id13">Modules, Functions and Macros</a><a class="headerlink" href="#modules-functions-and-macros" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="modules">
+<h3><a class="toc-backref" href="#id14">Modules</a><a class="headerlink" href="#modules" title="Permalink to this headline">¶</a></h3>
+<p>Modules are CMake’s vehicle for enabling code reuse. CMake modules are just
+CMake script files. They can contain code to execute on include as well as
+definitions for commands.</p>
+<p>In CMake macros and functions are universally referred to as commands, and they
+are the primary method of defining code that can be called multiple times.</p>
+<p>In LLVM we have several CMake modules that are included as part of our
+distribution for developers who don’t build our project from source. Those
+modules are the fundamental pieces needed to build LLVM-based projects with
+CMake. We also rely on modules as a way of organizing the build system’s
+functionality for maintainability and re-use within LLVM projects.</p>
+</div>
+<div class="section" id="argument-handling">
+<h3><a class="toc-backref" href="#id15">Argument Handling</a><a class="headerlink" href="#argument-handling" title="Permalink to this headline">¶</a></h3>
+<p>When defining a CMake command handling arguments is very useful. The examples
+in this section will all use the CMake <tt class="docutils literal"><span class="pre">function</span></tt> block, but this all applies
+to the <tt class="docutils literal"><span class="pre">macro</span></tt> block as well.</p>
+<p>CMake commands can have named arguments, but all commands are implicitly
+variable argument. If the command has named arguments they are required and must
+be specified at every call site. Below is a trivial example of providing a
+wrapper function for CMake’s built in function <tt class="docutils literal"><span class="pre">add_dependencies</span></tt>.</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">function</span><span class="p">(</span><span class="s">add_deps</span> <span class="s">target</span><span class="p">)</span>
+ <span class="nb">add_dependencies</span><span class="p">(</span><span class="o">${</span><span class="nv">target</span><span class="o">}</span> <span class="o">${</span><span class="nv">ARGV</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endfunction</span><span class="p">()</span>
+</pre></div>
+</div>
+<p>This example defines a new macro named <tt class="docutils literal"><span class="pre">add_deps</span></tt> which takes a required first
+argument, and just calls another function passing through the first argument and
+all trailing arguments. When variable arguments are present CMake defines them
+in a list named <tt class="docutils literal"><span class="pre">ARGV</span></tt>, and the count of the arguments is defined in <tt class="docutils literal"><span class="pre">ARGN</span></tt>.</p>
+<p>CMake provides a module <tt class="docutils literal"><span class="pre">CMakeParseArguments</span></tt> which provides an implementation
+of advanced argument parsing. We use this all over LLVM, and it is recommended
+for any function that has complex argument-based behaviors or optional
+arguments. CMake’s official documentation for the module is in the
+<tt class="docutils literal"><span class="pre">cmake-modules</span></tt> manpage, and is also available at the
+<a class="reference external" href="https://cmake.org/cmake/help/v3.4/module/CMakeParseArguments.html">cmake-modules online documentation</a>.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">As of CMake 3.5 the cmake_parse_arguments command has become a native command
+and the CMakeParseArguments module is empty and only left around for
+compatibility.</p>
+</div>
+</div>
+<div class="section" id="functions-vs-macros">
+<h3><a class="toc-backref" href="#id16">Functions Vs Macros</a><a class="headerlink" href="#functions-vs-macros" title="Permalink to this headline">¶</a></h3>
+<p>Functions and Macros look very similar in how they are used, but there is one
+fundamental difference between the two. Functions have their own scope, and
+macros don’t. This means variables set in macros will bleed out into the calling
+scope. That makes macros suitable for defining very small bits of functionality
+only.</p>
+<p>The other difference between CMake functions and macros is how arguments are
+passed. Arguments to macros are not set as variables, instead dereferences to
+the parameters are resolved across the macro before executing it. This can
+result in some unexpected behavior if using unreferenced variables. For example:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">macro</span><span class="p">(</span><span class="s">print_list</span> <span class="s">my_list</span><span class="p">)</span>
+ <span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">my_list</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="s2">"${var}"</span><span class="p">)</span>
+ <span class="nb">endforeach</span><span class="p">()</span>
+<span class="nb">endmacro</span><span class="p">()</span>
+
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">a</span> <span class="s">b</span> <span class="s">c</span> <span class="s">d</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list_of_numbers</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span> <span class="s">4</span><span class="p">)</span>
+<span class="nb">print_list</span><span class="p">(</span><span class="s">my_list_of_numbers</span><span class="p">)</span>
+<span class="c"># prints:</span>
+<span class="c"># a</span>
+<span class="c"># b</span>
+<span class="c"># c</span>
+<span class="c"># d</span>
+</pre></div>
+</div>
+<p>Generally speaking this issue is uncommon because it requires using
+non-dereferenced variables with names that overlap in the parent scope, but it
+is important to be aware of because it can lead to subtle bugs.</p>
+</div>
+</div>
+<div class="section" id="llvm-project-wrappers">
+<h2><a class="toc-backref" href="#id17">LLVM Project Wrappers</a><a class="headerlink" href="#llvm-project-wrappers" title="Permalink to this headline">¶</a></h2>
+<p>LLVM projects provide lots of wrappers around critical CMake built-in commands.
+We use these wrappers to provide consistent behaviors across LLVM components
+and to reduce code duplication.</p>
+<p>We generally (but not always) follow the convention that commands prefaced with
+<tt class="docutils literal"><span class="pre">llvm_</span></tt> are intended to be used only as building blocks for other commands.
+Wrapper commands that are intended for direct use are generally named following
+with the project in the middle of the command name (i.e. <tt class="docutils literal"><span class="pre">add_llvm_executable</span></tt>
+is the wrapper for <tt class="docutils literal"><span class="pre">add_executable</span></tt>). The LLVM <tt class="docutils literal"><span class="pre">add_*</span></tt> wrapper functions are
+all defined in <tt class="docutils literal"><span class="pre">AddLLVM.cmake</span></tt> which is installed as part of the LLVM
+distribution. It can be included and used by any LLVM sub-project that requires
+LLVM.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Not all LLVM projects require LLVM for all use cases. For example compiler-rt
+can be built without LLVM, and the compiler-rt sanitizer libraries are used
+with GCC.</p>
+</div>
+</div>
+<div class="section" id="useful-built-in-commands">
+<h2><a class="toc-backref" href="#id18">Useful Built-in Commands</a><a class="headerlink" href="#useful-built-in-commands" title="Permalink to this headline">¶</a></h2>
+<p>CMake has a bunch of useful built-in commands. This document isn’t going to
+go into details about them because The CMake project has excellent
+documentation. To highlight a few useful functions see:</p>
+<ul class="simple">
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/add_custom_command.html">add_custom_command</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/add_custom_target.html">add_custom_target</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/file.html">file</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/list.html">list</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/math.html">math</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/string.html">string</a></li>
+</ul>
+<p>The full documentation for CMake commands is in the <tt class="docutils literal"><span class="pre">cmake-commands</span></tt> manpage
+and available on <a class="reference external" href="https://cmake.org/cmake/help/v3.4/manual/cmake-commands.7.html">CMake’s website</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="AdvancedBuilds.html" title="Advanced Build Configurations"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="CMake.html" title="Building LLVM with CMake"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CodeGenerator.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CodeGenerator.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CodeGenerator.html (added)
+++ www-releases/trunk/3.9.0/docs/CodeGenerator.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,2580 @@
+
+<!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.9 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.9',
+ 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.9 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-targetframelowering-class" id="id18">The <tt class="docutils literal"><span class="pre">TargetFrameLowering</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>
+<li><a class="reference internal" href="#the-extended-berkeley-packet-filter-ebpf-backend" id="id94">The extended Berkeley Packet Filter (eBPF) backend</a><ul>
+<li><a class="reference internal" href="#instruction-encoding-arithmetic-and-jump" id="id95">Instruction encoding (arithmetic and jump)</a></li>
+<li><a class="reference internal" href="#instruction-encoding-load-store" id="id96">Instruction encoding (load, store)</a></li>
+<li><a class="reference internal" href="#packet-data-access-bpf-abs-bpf-ind" id="id97">Packet data access (BPF_ABS, BPF_IND)</a></li>
+<li><a class="reference internal" href="#ebpf-maps" id="id98">eBPF maps</a></li>
+<li><a class="reference internal" href="#function-calls" id="id99">Function calls</a></li>
+<li><a class="reference internal" href="#program-start" id="id100">Program start</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-amdgpu-backend" id="id101">The AMDGPU backend</a><ul>
+<li><a class="reference internal" href="#target-triples-supported" id="id102">Target triples supported</a></li>
+<li><a class="reference internal" href="#relocations" id="id103">Relocations</a></li>
+</ul>
+</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 at 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 internal" href="LangRef.html"><em>LLVM code representation</em></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="TableGen/index.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 internal" href="TableGen/index.html"><em>TableGen</em></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-targetframelowering-class">
+<h3><a class="toc-backref" href="#id18">The <tt class="docutils literal"><span class="pre">TargetFrameLowering</span></tt> class</a><a class="headerlink" href="#the-targetframelowering-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetFrameLowering</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 and insert it at the end of the given MachineBasicBlock.</span>
+<span class="k">const</span> <span class="n">TargetInstrInfo</span> <span class="o">&</span><span class="n">TII</span> <span class="o">=</span> <span class="p">...</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">DebugLoc</span> <span class="n">DL</span><span class="p">;</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">MBB</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</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="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">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</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="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">MBB</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">CMP32ri8</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">42</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">MBB</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</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="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">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</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="n">addMBB</span><span class="p">(</span><span class="o">&</span><span class="n">MBB</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>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">sdiv</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 might produce 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>:</p>
+<div class="highlight-text"><div class="highlight"><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>
+</div>
+<p>By the end of code generation, the register allocator would coalesce the
+registers and delete the resultant identity moves producing the following
+code:</p>
+<div class="highlight-text"><div class="highlight"><pre>;; X is in EAX, Y is in ECX
+mov %EAX, %EDX
+sar %EDX, 31
+idiv %ECX
+ret
+</pre></div>
+</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"><div class="highlight"><pre>--------------
+| Bundle | ---------
+-------------- \
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ |
+--------------
+| Bundle | --------
+-------------- \
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ...
+ |
+--------------
+| Bundle | --------
+-------------- \
+ |
+ ...
+</pre></div>
+</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 straightforward 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">.fnstart</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"><div class="highlight"><pre>foo:
+bar:
+ .byte 4
+</pre></div>
+</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/ISDOpcodes.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. However, after instruction selection, the
+machine nodes have their chain after the instruction’s operands, and
+may be followed by glue nodes.</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#viewing-graphs-while-debugging-code">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>
+<p>The option <tt class="docutils literal"><span class="pre">-filter-view-dags</span></tt> allows to select the name of the basic block
+that you are interested to visualize and filters all the previous
+<tt class="docutils literal"><span class="pre">view-*-dags</span></tt> options.</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-text"><div class="highlight"><pre>(fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
+</pre></div>
+</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"><div class="highlight"><pre>(FMADDS (FADDS W, X), Y, Z)
+</pre></div>
+</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"><div class="highlight"><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>
+</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"><div class="highlight"><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>
+</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>
+<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 being 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 registers. 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"><div class="highlight"><pre>%a = MOVE %b
+%a = ADD %a %c
+</pre></div>
+</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"><div class="highlight"><pre>%EBX = LOAD %mem_address
+%EAX = COPY %EBX
+</pre></div>
+</div>
+<p>can be safely substituted by the single instruction:</p>
+<div class="highlight-python"><div class="highlight"><pre>%EAX = LOAD %mem_address
+</pre></div>
+</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 a 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"><div class="highlight"><pre>def : MnemonicAlias<"cbw", "cbtw">;
+def : MnemonicAlias<"smovq", "movsq">;
+def : MnemonicAlias<"fldcww", "fldcw">;
+def : MnemonicAlias<"fucompi", "fucomip">;
+def : MnemonicAlias<"ud2a", "ud2">;
+</pre></div>
+</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"><div class="highlight"><pre>def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
+def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;
+</pre></div>
+</div>
+<p>In this example, the mnemonic gets mapped into a different 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"><div class="highlight"><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>
+</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"><div class="highlight"><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>
+</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"><div class="highlight"><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>
+</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 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"><th>eBPF</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"><td class="yes"></td> <!-- eBPF --></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"><td class="no"></td> <!-- eBPF --></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"><td class="yes"></td> <!-- eBPF --></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"><td class="no"></td> <!-- eBPF --></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"><td class="yes"></td> <!-- eBPF --></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"><td class="yes"></td> <!-- eBPF --></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"><td class="no"></td> <!-- eBPF --></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"><td class="no"></td> <!-- eBPF --></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">tail call section</a> for more details.</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"></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"><div class="highlight"><pre>SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32
+</pre></div>
+</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"><div class="highlight"><pre>Index: 0 | 1 2 3 4 5
+Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement Segment
+OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg
+</pre></div>
+</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, the FS-segment is represented by address space
+257, and the SS-segment is represented by address space 258. 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"><div class="highlight"><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>
+<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 class="section" id="the-extended-berkeley-packet-filter-ebpf-backend">
+<h3><a class="toc-backref" href="#id94">The extended Berkeley Packet Filter (eBPF) backend</a><a class="headerlink" href="#the-extended-berkeley-packet-filter-ebpf-backend" title="Permalink to this headline">¶</a></h3>
+<p>Extended BPF (or eBPF) is similar to the original (“classic”) BPF (cBPF) used
+to filter network packets. The
+<a class="reference external" href="http://man7.org/linux/man-pages/man2/bpf.2.html">bpf() system call</a>
+performs a range of operations related to eBPF. For both cBPF and eBPF
+programs, the Linux kernel statically analyzes the programs before loading
+them, in order to ensure that they cannot harm the running system. eBPF is
+a 64-bit RISC instruction set designed for one to one mapping to 64-bit CPUs.
+Opcodes are 8-bit encoded, and 87 instructions are defined. There are 10
+registers, grouped by function as outlined below.</p>
+<div class="highlight-python"><div class="highlight"><pre>R0 return value from in-kernel functions; exit value for eBPF program
+R1 - R5 function call arguments to in-kernel functions
+R6 - R9 callee-saved registers preserved by in-kernel functions
+R10 stack frame pointer (read only)
+</pre></div>
+</div>
+<div class="section" id="instruction-encoding-arithmetic-and-jump">
+<h4><a class="toc-backref" href="#id95">Instruction encoding (arithmetic and jump)</a><a class="headerlink" href="#instruction-encoding-arithmetic-and-jump" title="Permalink to this headline">¶</a></h4>
+<p>eBPF is reusing most of the opcode encoding from classic to simplify conversion
+of classic BPF to eBPF. For arithmetic and jump instructions the 8-bit ‘code’
+field is divided into three parts:</p>
+<div class="highlight-python"><div class="highlight"><pre>+----------------+--------+--------------------+
+| 4 bits | 1 bit | 3 bits |
+| operation code | source | instruction class |
++----------------+--------+--------------------+
+(MSB) (LSB)
+</pre></div>
+</div>
+<p>Three LSB bits store instruction class which is one of:</p>
+<div class="highlight-python"><div class="highlight"><pre>BPF_LD 0x0
+BPF_LDX 0x1
+BPF_ST 0x2
+BPF_STX 0x3
+BPF_ALU 0x4
+BPF_JMP 0x5
+(unused) 0x6
+BPF_ALU64 0x7
+</pre></div>
+</div>
+<p>When BPF_CLASS(code) == BPF_ALU or BPF_ALU64 or BPF_JMP,
+4th bit encodes source operand</p>
+<div class="highlight-python"><div class="highlight"><pre>BPF_X 0x0 use src_reg register as source operand
+BPF_K 0x1 use 32 bit immediate as source operand
+</pre></div>
+</div>
+<p>and four MSB bits store operation code</p>
+<div class="highlight-python"><div class="highlight"><pre>BPF_ADD 0x0 add
+BPF_SUB 0x1 subtract
+BPF_MUL 0x2 multiply
+BPF_DIV 0x3 divide
+BPF_OR 0x4 bitwise logical OR
+BPF_AND 0x5 bitwise logical AND
+BPF_LSH 0x6 left shift
+BPF_RSH 0x7 right shift (zero extended)
+BPF_NEG 0x8 arithmetic negation
+BPF_MOD 0x9 modulo
+BPF_XOR 0xa bitwise logical XOR
+BPF_MOV 0xb move register to register
+BPF_ARSH 0xc right shift (sign extended)
+BPF_END 0xd endianness conversion
+</pre></div>
+</div>
+<p>If BPF_CLASS(code) == BPF_JMP, BPF_OP(code) is one of</p>
+<div class="highlight-python"><div class="highlight"><pre>BPF_JA 0x0 unconditional jump
+BPF_JEQ 0x1 jump ==
+BPF_JGT 0x2 jump >
+BPF_JGE 0x3 jump >=
+BPF_JSET 0x4 jump if (DST & SRC)
+BPF_JNE 0x5 jump !=
+BPF_JSGT 0x6 jump signed >
+BPF_JSGE 0x7 jump signed >=
+BPF_CALL 0x8 function call
+BPF_EXIT 0x9 function return
+</pre></div>
+</div>
+</div>
+<div class="section" id="instruction-encoding-load-store">
+<h4><a class="toc-backref" href="#id96">Instruction encoding (load, store)</a><a class="headerlink" href="#instruction-encoding-load-store" title="Permalink to this headline">¶</a></h4>
+<p>For load and store instructions the 8-bit ‘code’ field is divided as:</p>
+<div class="highlight-python"><div class="highlight"><pre>+--------+--------+-------------------+
+| 3 bits | 2 bits | 3 bits |
+| mode | size | instruction class |
++--------+--------+-------------------+
+(MSB) (LSB)
+</pre></div>
+</div>
+<p>Size modifier is one of</p>
+<div class="highlight-python"><div class="highlight"><pre>BPF_W 0x0 word
+BPF_H 0x1 half word
+BPF_B 0x2 byte
+BPF_DW 0x3 double word
+</pre></div>
+</div>
+<p>Mode modifier is one of</p>
+<div class="highlight-python"><div class="highlight"><pre>BPF_IMM 0x0 immediate
+BPF_ABS 0x1 used to access packet data
+BPF_IND 0x2 used to access packet data
+BPF_MEM 0x3 memory
+(reserved) 0x4
+(reserved) 0x5
+BPF_XADD 0x6 exclusive add
+</pre></div>
+</div>
+</div>
+<div class="section" id="packet-data-access-bpf-abs-bpf-ind">
+<h4><a class="toc-backref" href="#id97">Packet data access (BPF_ABS, BPF_IND)</a><a class="headerlink" href="#packet-data-access-bpf-abs-bpf-ind" title="Permalink to this headline">¶</a></h4>
+<p>Two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and
+(BPF_IND | <size> | BPF_LD) which are used to access packet data.
+Register R6 is an implicit input that must contain pointer to sk_buff.
+Register R0 is an implicit output which contains the data fetched
+from the packet. Registers R1-R5 are scratch registers and must not
+be used to store the data across BPF_ABS | BPF_LD or BPF_IND | BPF_LD
+instructions. These instructions have implicit program exit condition
+as well. When eBPF program is trying to access the data beyond
+the packet boundary, the interpreter will abort the execution of the program.</p>
+<dl class="docutils">
+<dt>BPF_IND | BPF_W | BPF_LD is equivalent to:</dt>
+<dd>R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32))</dd>
+</dl>
+</div>
+<div class="section" id="ebpf-maps">
+<h4><a class="toc-backref" href="#id98">eBPF maps</a><a class="headerlink" href="#ebpf-maps" title="Permalink to this headline">¶</a></h4>
+<p>eBPF maps are provided for sharing data between kernel and user-space.
+Currently implemented types are hash and array, with potential extension to
+support bloom filters, radix trees, etc. A map is defined by its type,
+maximum number of elements, key size and value size in bytes. eBPF syscall
+supports create, update, find and delete functions on maps.</p>
+</div>
+<div class="section" id="function-calls">
+<h4><a class="toc-backref" href="#id99">Function calls</a><a class="headerlink" href="#function-calls" title="Permalink to this headline">¶</a></h4>
+<p>Function call arguments are passed using up to five registers (R1 - R5).
+The return value is passed in a dedicated register (R0). Four additional
+registers (R6 - R9) are callee-saved, and the values in these registers
+are preserved within kernel functions. R0 - R5 are scratch registers within
+kernel functions, and eBPF programs must therefor store/restore values in
+these registers if needed across function calls. The stack can be accessed
+using the read-only frame pointer R10. eBPF registers map 1:1 to hardware
+registers on x86_64 and other 64-bit architectures. For example, x86_64
+in-kernel JIT maps them as</p>
+<div class="highlight-python"><div class="highlight"><pre><span class="n">R0</span> <span class="o">-</span> <span class="n">rax</span>
+<span class="n">R1</span> <span class="o">-</span> <span class="n">rdi</span>
+<span class="n">R2</span> <span class="o">-</span> <span class="n">rsi</span>
+<span class="n">R3</span> <span class="o">-</span> <span class="n">rdx</span>
+<span class="n">R4</span> <span class="o">-</span> <span class="n">rcx</span>
+<span class="n">R5</span> <span class="o">-</span> <span class="n">r8</span>
+<span class="n">R6</span> <span class="o">-</span> <span class="n">rbx</span>
+<span class="n">R7</span> <span class="o">-</span> <span class="n">r13</span>
+<span class="n">R8</span> <span class="o">-</span> <span class="n">r14</span>
+<span class="n">R9</span> <span class="o">-</span> <span class="n">r15</span>
+<span class="n">R10</span> <span class="o">-</span> <span class="n">rbp</span>
+</pre></div>
+</div>
+<p>since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing
+and rbx, r12 - r15 are callee saved.</p>
+</div>
+<div class="section" id="program-start">
+<h4><a class="toc-backref" href="#id100">Program start</a><a class="headerlink" href="#program-start" title="Permalink to this headline">¶</a></h4>
+<p>An eBPF program receives a single argument and contains
+a single eBPF main routine; the program does not contain eBPF functions.
+Function calls are limited to a predefined set of kernel functions. The size
+of a program is limited to 4K instructions: this ensures fast termination and
+a limited number of kernel function calls. Prior to running an eBPF program,
+a verifier performs static analysis to prevent loops in the code and
+to ensure valid register usage and operand types.</p>
+</div>
+</div>
+<div class="section" id="the-amdgpu-backend">
+<h3><a class="toc-backref" href="#id101">The AMDGPU backend</a><a class="headerlink" href="#the-amdgpu-backend" title="Permalink to this headline">¶</a></h3>
+<p>The AMDGPU code generator lives in the lib/Target/AMDGPU directory, and is an
+open source native AMD GCN ISA code generator.</p>
+<div class="section" id="target-triples-supported">
+<h4><a class="toc-backref" href="#id102">Target triples supported</a><a class="headerlink" href="#target-triples-supported" title="Permalink to this headline">¶</a></h4>
+<p>The following are the known target triples that are supported by the AMDGPU
+backend.</p>
+<ul class="simple">
+<li><strong>amdgcn–</strong> — AMD GCN GPUs (AMDGPU.7.0.0+)</li>
+<li><strong>amdgcn–amdhsa</strong> — AMD GCN GPUs (AMDGPU.7.0.0+) with HSA support</li>
+<li><strong>r600–</strong> — AMD GPUs HD2XXX-HD6XXX</li>
+</ul>
+</div>
+<div class="section" id="relocations">
+<h4><a class="toc-backref" href="#id103">Relocations</a><a class="headerlink" href="#relocations" title="Permalink to this headline">¶</a></h4>
+<p>Supported relocatable fields are:</p>
+<ul class="simple">
+<li><strong>word32</strong> — This specifies a 32-bit field occupying 4 bytes with arbitrary
+byte alignment. These values use the same byte order as other word values in
+the AMD GPU architecture</li>
+<li><strong>word64</strong> — This specifies a 64-bit field occupying 8 bytes with arbitrary
+byte alignment. These values use the same byte order as other word values in
+the AMD GPU architecture</li>
+</ul>
+<p>Following notations are used for specifying relocation calculations:</p>
+<ul class="simple">
+<li><strong>A</strong> — Represents the addend used to compute the value of the relocatable
+field</li>
+<li><strong>G</strong> — Represents the offset into the global offset table at which the
+relocation entryâs symbol will reside during execution.</li>
+<li><strong>GOT</strong> — Represents the address of the global offset table.</li>
+<li><strong>P</strong> — Represents the place (section offset or address) of the storage unit
+being relocated (computed using <tt class="docutils literal"><span class="pre">r_offset</span></tt>)</li>
+<li><strong>S</strong> — Represents the value of the symbol whose index resides in the
+relocation entry</li>
+</ul>
+<p>AMDGPU Backend generates <em>Elf64_Rela</em> relocation records with the following
+supported relocation types:</p>
+<blockquote>
+<div><table border="1" class="docutils">
+<colgroup>
+<col width="38%" />
+<col width="9%" />
+<col width="18%" />
+<col width="36%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Relocation type</th>
+<th class="head">Value</th>
+<th class="head">Field</th>
+<th class="head">Calculation</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_NONE</span></tt></td>
+<td>0</td>
+<td><tt class="docutils literal"><span class="pre">none</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">none</span></tt></td>
+</tr>
+<tr class="row-odd"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_ABS32_LO</span></tt></td>
+<td>1</td>
+<td><tt class="docutils literal"><span class="pre">word32</span></tt></td>
+<td>(S + A) & 0xFFFFFFFF</td>
+</tr>
+<tr class="row-even"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_ABS32_HI</span></tt></td>
+<td>2</td>
+<td><tt class="docutils literal"><span class="pre">word32</span></tt></td>
+<td>(S + A) >> 32</td>
+</tr>
+<tr class="row-odd"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_ABS64</span></tt></td>
+<td>3</td>
+<td><tt class="docutils literal"><span class="pre">word64</span></tt></td>
+<td>S + A</td>
+</tr>
+<tr class="row-even"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_REL32</span></tt></td>
+<td>4</td>
+<td><tt class="docutils literal"><span class="pre">word32</span></tt></td>
+<td>S + A - P</td>
+</tr>
+<tr class="row-odd"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_REL64</span></tt></td>
+<td>5</td>
+<td><tt class="docutils literal"><span class="pre">word64</span></tt></td>
+<td>S + A - P</td>
+</tr>
+<tr class="row-even"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_ABS32</span></tt></td>
+<td>6</td>
+<td><tt class="docutils literal"><span class="pre">word32</span></tt></td>
+<td>S + A</td>
+</tr>
+<tr class="row-odd"><td><tt class="docutils literal"><span class="pre">R_AMDGPU_GOTPCREL</span></tt></td>
+<td>7</td>
+<td><tt class="docutils literal"><span class="pre">word32</span></tt></td>
+<td>G + GOT + A - P</td>
+</tr>
+</tbody>
+</table>
+</div></blockquote>
+</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="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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CodeOfConduct.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CodeOfConduct.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CodeOfConduct.html (added)
+++ www-releases/trunk/3.9.0/docs/CodeOfConduct.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,192 @@
+
+<!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 Community Code of Conduct — LLVM 3.9 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.9',
+ 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.9 documentation" href="index.html" />
+ <link rel="next" title="Compiling CUDA C/C++ with LLVM" href="CompileCudaWithLLVM.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="CompileCudaWithLLVM.html" title="Compiling CUDA C/C++ with LLVM"
+ 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-community-code-of-conduct">
+<h1>LLVM Community Code of Conduct<a class="headerlink" href="#llvm-community-code-of-conduct" title="Permalink to this headline">¶</a></h1>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This document is currently a <strong>DRAFT</strong> document while it is being discussed
+by the community.</p>
+</div>
+<p>The LLVM community has always worked to be a welcoming and respectful
+community, and we want to ensure that doesn’t change as we grow and evolve. To
+that end, we have a few ground rules that we ask people to adhere to:</p>
+<ul class="simple">
+<li><a class="reference internal" href="#be-friendly-and-patient">be friendly and patient</a>,</li>
+<li><a class="reference internal" href="#be-welcoming">be welcoming</a>,</li>
+<li><a class="reference internal" href="#be-considerate">be considerate</a>,</li>
+<li><a class="reference internal" href="#be-respectful">be respectful</a>,</li>
+<li><a class="reference internal" href="#be-careful-in-the-words-that-you-choose-and-be-kind-to-others">be careful in the words that you choose and be kind to others</a>, and</li>
+<li><a class="reference internal" href="#when-we-disagree-try-to-understand-why">when we disagree, try to understand why</a>.</li>
+</ul>
+<p>This isn’t an exhaustive list of things that you can’t do. Rather, take it in
+the spirit in which it’s intended - a guide to make it easier to communicate
+and participate in the community.</p>
+<p>This code of conduct applies to all spaces managed by the LLVM project or The
+LLVM Foundation. This includes IRC channels, mailing lists, bug trackers, LLVM
+events such as the developer meetings and socials, and any other forums created
+by the project that the community uses for communication. It applies to all of
+your communication and conduct in these spaces, including emails, chats, things
+you say, slides, videos, posters, signs, or even t-shirts you display in these
+spaces. In addition, violations of this code outside these spaces may, in rare
+cases, affect a person’s ability to participate within them, when the conduct
+amounts to an egregious violation of this code.</p>
+<p>If you believe someone is violating the code of conduct, we ask that you report
+it by emailing <a class="reference external" href="mailto:conduct%40llvm.org">conduct<span>@</span>llvm<span>.</span>org</a>. For more details please see our
+<a class="reference internal" href="ReportingGuide.html"><em>Reporting Guide</em></a>.</p>
+<ul class="simple" id="be-friendly-and-patient">
+<li><strong>Be friendly and patient.</strong></li>
+</ul>
+<ul class="simple" id="be-welcoming">
+<li><strong>Be welcoming.</strong> We strive to be a community that welcomes and supports
+people of all backgrounds and identities. This includes, but is not limited
+to members of any race, ethnicity, culture, national origin, colour,
+immigration status, social and economic class, educational level, sex, sexual
+orientation, gender identity and expression, age, size, family status,
+political belief, religion or lack thereof, and mental and physical ability.</li>
+</ul>
+<ul class="simple" id="be-considerate">
+<li><strong>Be considerate.</strong> Your work will be used by other people, and you in turn
+will depend on the work of others. Any decision you take will affect users
+and colleagues, and you should take those consequences into account. Remember
+that we’re a world-wide community, so you might not be communicating in
+someone else’s primary language.</li>
+</ul>
+<ul class="simple" id="be-respectful">
+<li><strong>Be respectful.</strong> Not all of us will agree all the time, but disagreement is
+no excuse for poor behavior and poor manners. We might all experience some
+frustration now and then, but we cannot allow that frustration to turn into
+a personal attack. It’s important to remember that a community where people
+feel uncomfortable or threatened is not a productive one. Members of the LLVM
+community should be respectful when dealing with other members as well as
+with people outside the LLVM community.</li>
+</ul>
+<ul id="be-careful-in-the-words-that-you-choose-and-be-kind-to-others">
+<li><p class="first"><strong>Be careful in the words that you choose and be kind to others.</strong> Do not
+insult or put down other participants. Harassment and other exclusionary
+behavior aren’t acceptable. This includes, but is not limited to:</p>
+<ul class="simple">
+<li>Violent threats or language directed against another person.</li>
+<li>Discriminatory jokes and language.</li>
+<li>Posting sexually explicit or violent material.</li>
+<li>Posting (or threatening to post) other people’s personally identifying
+information (“doxing”).</li>
+<li>Personal insults, especially those using racist or sexist terms.</li>
+<li>Unwelcome sexual attention.</li>
+<li>Advocating for, or encouraging, any of the above behavior.</li>
+</ul>
+<p>In general, if someone asks you to stop, then stop. Persisting in such
+behavior after being asked to stop is considered harassment.</p>
+</li>
+</ul>
+<ul class="simple" id="when-we-disagree-try-to-understand-why">
+<li><strong>When we disagree, try to understand why.</strong> Disagreements, both social and
+technical, happen all the time and LLVM is no exception. It is important that
+we resolve disagreements and differing views constructively. Remember that
+we’re different. The strength of LLVM comes from its varied community, people
+from a wide range of backgrounds. Different people have different
+perspectives on issues. Being unable to understand why someone holds
+a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to
+err and blaming each other doesn’t get us anywhere. Instead, focus on helping
+to resolve issues and learning from mistakes.</li>
+</ul>
+<div class="section" id="questions">
+<h2>Questions?<a class="headerlink" href="#questions" title="Permalink to this headline">¶</a></h2>
+<p>If you have questions, please feel free to contact the LLVM Foundation Code of
+Conduct Advisory Committee by emailing <a class="reference external" href="mailto:conduct%40llvm.org">conduct<span>@</span>llvm<span>.</span>org</a>.</p>
+<p>(This text is based on the <a class="reference external" href="https://www.djangoproject.com/conduct/">Django Project</a> Code of Conduct, which is in turn
+based on wording from the <a class="reference external" href="http://speakup.io/coc.html">Speak Up! project</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="CompileCudaWithLLVM.html" title="Compiling CUDA C/C++ with LLVM"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CodingStandards.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CodingStandards.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CodingStandards.html (added)
+++ www-releases/trunk/3.9.0/docs/CodingStandards.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,1550 @@
+
+<!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.9 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.9',
+ 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.9 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="#languages-libraries-and-standards" id="id2">Languages, Libraries, and Standards</a><ul>
+<li><a class="reference internal" href="#c-standard-versions" id="id3">C++ Standard Versions</a></li>
+<li><a class="reference internal" href="#c-standard-library" id="id4">C++ Standard Library</a></li>
+<li><a class="reference internal" href="#supported-c-11-language-and-library-features" id="id5">Supported C++11 Language and Library Features</a></li>
+<li><a class="reference internal" href="#other-languages" id="id6">Other Languages</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#mechanical-source-issues" id="id7">Mechanical Source Issues</a><ul>
+<li><a class="reference internal" href="#source-code-formatting" id="id8">Source Code Formatting</a><ul>
+<li><a class="reference internal" href="#commenting" id="id9">Commenting</a><ul>
+<li><a class="reference internal" href="#file-headers" id="id10">File Headers</a></li>
+<li><a class="reference internal" href="#class-overviews" id="id11">Class overviews</a></li>
+<li><a class="reference internal" href="#method-information" id="id12">Method information</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#comment-formatting" id="id13">Comment Formatting</a></li>
+<li><a class="reference internal" href="#doxygen-use-in-documentation-comments" id="id14">Doxygen Use in Documentation Comments</a></li>
+<li><a class="reference internal" href="#include-style" id="id15"><tt class="docutils literal"><span class="pre">#include</span></tt> Style</a></li>
+<li><a class="reference internal" href="#source-code-width" id="id16">Source Code Width</a></li>
+<li><a class="reference internal" href="#use-spaces-instead-of-tabs" id="id17">Use Spaces Instead of Tabs</a></li>
+<li><a class="reference internal" href="#indent-code-consistently" id="id18">Indent Code Consistently</a><ul>
+<li><a class="reference internal" href="#format-lambdas-like-blocks-of-code" id="id19">Format Lambdas Like Blocks Of Code</a></li>
+<li><a class="reference internal" href="#braced-initializer-lists" id="id20">Braced Initializer Lists</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#language-and-compiler-issues" id="id21">Language and Compiler Issues</a><ul>
+<li><a class="reference internal" href="#treat-compiler-warnings-like-errors" id="id22">Treat Compiler Warnings Like Errors</a></li>
+<li><a class="reference internal" href="#write-portable-code" id="id23">Write Portable Code</a></li>
+<li><a class="reference internal" href="#do-not-use-rtti-or-exceptions" id="id24">Do not use RTTI or Exceptions</a></li>
+<li><a class="reference internal" href="#do-not-use-static-constructors" id="id25">Do not use Static Constructors</a></li>
+<li><a class="reference internal" href="#use-of-class-and-struct-keywords" id="id26">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>
+<li><a class="reference internal" href="#do-not-use-braced-initializer-lists-to-call-a-constructor" id="id27">Do not use Braced Initializer Lists to Call a Constructor</a></li>
+<li><a class="reference internal" href="#use-auto-type-deduction-to-make-code-more-readable" id="id28">Use <tt class="docutils literal"><span class="pre">auto</span></tt> Type Deduction to Make Code More Readable</a></li>
+<li><a class="reference internal" href="#beware-unnecessary-copies-with-auto" id="id29">Beware unnecessary copies with <tt class="docutils literal"><span class="pre">auto</span></tt></a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#style-issues" id="id30">Style Issues</a><ul>
+<li><a class="reference internal" href="#the-high-level-issues" id="id31">The High-Level Issues</a><ul>
+<li><a class="reference internal" href="#a-public-header-file-is-a-module" id="id32">A Public Header File <strong>is</strong> a Module</a></li>
+<li><a class="reference internal" href="#include-as-little-as-possible" id="id33"><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="id34">Keep “Internal” Headers Private</a></li>
+<li><a class="reference internal" href="#use-early-exits-and-continue-to-simplify-code" id="id35">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="id36">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="id37">Turn Predicate Loops into Predicate Functions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-low-level-issues" id="id38">The Low-Level Issues</a><ul>
+<li><a class="reference internal" href="#name-types-functions-variables-and-enumerators-properly" id="id39">Name Types, Functions, Variables, and Enumerators Properly</a></li>
+<li><a class="reference internal" href="#assert-liberally" id="id40">Assert Liberally</a></li>
+<li><a class="reference internal" href="#do-not-use-using-namespace-std" id="id41">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="id42">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="id43">Don’t use default labels in fully covered switches over enumerations</a></li>
+<li><a class="reference internal" href="#don-t-evaluate-end-every-time-through-a-loop" id="id44">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="id45"><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="id46">Use <tt class="docutils literal"><span class="pre">raw_ostream</span></tt></a></li>
+<li><a class="reference internal" href="#avoid-std-endl" id="id47">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="id48">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="id49">Microscopic Details</a><ul>
+<li><a class="reference internal" href="#spaces-before-parentheses" id="id50">Spaces Before Parentheses</a></li>
+<li><a class="reference internal" href="#prefer-preincrement" id="id51">Prefer Preincrement</a></li>
+<li><a class="reference internal" href="#namespace-indentation" id="id52">Namespace Indentation</a></li>
+<li><a class="reference internal" href="#anonymous-namespaces" id="id53">Anonymous Namespaces</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#see-also" id="id54">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>While this document may provide guidance for some mechanical formatting issues,
+whitespace, or other “microscopic details”, these are not fixed standards.
+Always 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 LLVM-dev 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 to increase the 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="languages-libraries-and-standards">
+<h2><a class="toc-backref" href="#id2">Languages, Libraries, and Standards</a><a class="headerlink" href="#languages-libraries-and-standards" title="Permalink to this headline">¶</a></h2>
+<p>Most source code in LLVM and other LLVM projects using these coding standards
+is C++ code. There are some places where C code is used either due to
+environment restrictions, historical restrictions, or due to third-party source
+code imported into the tree. Generally, our preference is for standards
+conforming, modern, and portable C++ code as the implementation language of
+choice.</p>
+<div class="section" id="c-standard-versions">
+<h3><a class="toc-backref" href="#id3">C++ Standard Versions</a><a class="headerlink" href="#c-standard-versions" title="Permalink to this headline">¶</a></h3>
+<p>LLVM, Clang, and LLD are currently written using C++11 conforming code,
+although we restrict ourselves to features which are available in the major
+toolchains supported as host compilers. The LLDB project is even more
+aggressive in the set of host compilers supported and thus uses still more
+features. Regardless of the supported features, code is expected to (when
+reasonable) be standard, portable, and modern C++11 code. We avoid unnecessary
+vendor-specific extensions, etc.</p>
+</div>
+<div class="section" id="c-standard-library">
+<h3><a class="toc-backref" href="#id4">C++ Standard Library</a><a class="headerlink" href="#c-standard-library" title="Permalink to this headline">¶</a></h3>
+<p>Use the C++ standard library facilities whenever they are available for
+a particular task. LLVM and related projects emphasize and rely on the standard
+library facilities for as much as possible. Common support libraries providing
+functionality missing from the standard library for which there are standard
+interfaces or active work on adding standard interfaces will often be
+implemented in the LLVM namespace following the expected standard interface.</p>
+<p>There are some exceptions such as the standard I/O streams library which are
+avoided. Also, there is much more detailed information on these subjects in the
+<a class="reference internal" href="ProgrammersManual.html"><em>LLVM Programmer’s Manual</em></a>.</p>
+</div>
+<div class="section" id="supported-c-11-language-and-library-features">
+<h3><a class="toc-backref" href="#id5">Supported C++11 Language and Library Features</a><a class="headerlink" href="#supported-c-11-language-and-library-features" title="Permalink to this headline">¶</a></h3>
+<p>While LLVM, Clang, and LLD use C++11, not all features are available in all of
+the toolchains which we support. The set of features supported for use in LLVM
+is the intersection of those supported in MSVC 2013, GCC 4.7, and Clang 3.1.
+The ultimate definition of this set is what build bots with those respective
+toolchains accept. Don’t argue with the build bots. However, we have some
+guidance below to help you know what to expect.</p>
+<p>Each toolchain provides a good reference for what it accepts:</p>
+<ul class="simple">
+<li>Clang: <a class="reference external" href="http://clang.llvm.org/cxx_status.html">http://clang.llvm.org/cxx_status.html</a></li>
+<li>GCC: <a class="reference external" href="http://gcc.gnu.org/projects/cxx0x.html">http://gcc.gnu.org/projects/cxx0x.html</a></li>
+<li>MSVC: <a class="reference external" href="http://msdn.microsoft.com/en-us/library/hh567368.aspx">http://msdn.microsoft.com/en-us/library/hh567368.aspx</a></li>
+</ul>
+<p>In most cases, the MSVC list will be the dominating factor. Here is a summary
+of the features that are expected to work. Features not on this list are
+unlikely to be supported by our host compilers.</p>
+<ul class="simple">
+<li>Rvalue references: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html">N2118</a><ul>
+<li>But <em>not</em> Rvalue references for <tt class="docutils literal"><span class="pre">*this</span></tt> or member qualifiers (<a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm">N2439</a>)</li>
+</ul>
+</li>
+<li>Static assert: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html">N1720</a></li>
+<li><tt class="docutils literal"><span class="pre">auto</span></tt> type deduction: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf">N1984</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1737.pdf">N1737</a></li>
+<li>Trailing return types: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm">N2541</a></li>
+<li>Lambdas: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf">N2927</a><ul>
+<li>But <em>not</em> lambdas with default arguments.</li>
+</ul>
+</li>
+<li><tt class="docutils literal"><span class="pre">decltype</span></tt>: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf">N2343</a></li>
+<li>Nested closing right angle brackets: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html">N1757</a></li>
+<li>Extern templates: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm">N1987</a></li>
+<li><tt class="docutils literal"><span class="pre">nullptr</span></tt>: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a></li>
+<li>Strongly-typed and forward declarable enums: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf">N2764</a></li>
+<li>Local and unnamed types as template arguments: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm">N2657</a></li>
+<li>Range-based for-loop: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html">N2930</a><ul>
+<li>But <tt class="docutils literal"><span class="pre">{}</span></tt> are required around inner <tt class="docutils literal"><span class="pre">do</span> <span class="pre">{}</span> <span class="pre">while()</span></tt> loops. As a result,
+<tt class="docutils literal"><span class="pre">{}</span></tt> are required around function-like macros inside range-based for
+loops.</li>
+</ul>
+</li>
+<li><tt class="docutils literal"><span class="pre">override</span></tt> and <tt class="docutils literal"><span class="pre">final</span></tt>: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm">N2928</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm">N3206</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm">N3272</a></li>
+<li>Atomic operations and the C++11 memory model: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm">N2429</a></li>
+<li>Variadic templates: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf">N2242</a></li>
+<li>Explicit conversion operators: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf">N2437</a></li>
+<li>Defaulted and deleted functions: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm">N2346</a><ul>
+<li>But not defaulted move constructors or move assignment operators, MSVC 2013
+cannot synthesize them.</li>
+</ul>
+</li>
+<li>Initializer lists: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm">N2627</a></li>
+<li>Delegating constructors: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf">N1986</a></li>
+<li>Default member initializers (non-static data member initializers): <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm">N2756</a><ul>
+<li>Only use these for scalar members that would otherwise be left
+uninitialized. Non-scalar members generally have appropriate default
+constructors, and MSVC 2013 has problems when braced initializer lists are
+involved.</li>
+</ul>
+</li>
+</ul>
+<p>The supported features in the C++11 standard libraries are less well tracked,
+but also much greater. Most of the standard libraries implement most of C++11’s
+library. The most likely lowest common denominator is Linux support. For
+libc++, the support is just poorly tested and undocumented but expected to be
+largely complete. YMMV. For libstdc++, the support is documented in detail in
+<a class="reference external" href="http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/manual/status.html#status.iso.2011">the libstdc++ manual</a>. There are some very minor missing facilities that are
+unlikely to be common problems, and there are a few larger gaps that are worth
+being aware of:</p>
+<ul class="simple">
+<li>Not all of the type traits are implemented</li>
+<li>No regular expression library.</li>
+<li>While most of the atomics library is well implemented, the fences are
+missing. Fortunately, they are rarely needed.</li>
+<li>The locale support is incomplete.</li>
+</ul>
+<p>Other than these areas you should assume the standard library is available and
+working as expected until some build bot tells you otherwise. If you’re in an
+uncertain area of one of the above points, but you cannot test on a Linux
+system, your best approach is to minimize your use of these features, and watch
+the Linux build bots to find out if your usage triggered a bug. For example, if
+you hit a type trait which doesn’t work we can then add support to LLVM’s
+traits header to emulate it.</p>
+</div>
+<div class="section" id="other-languages">
+<h3><a class="toc-backref" href="#id6">Other Languages</a><a class="headerlink" href="#other-languages" title="Permalink to this headline">¶</a></h3>
+<p>Any code written in the Go programming language is not subject to the
+formatting rules below. Instead, we adopt the formatting rules enforced by
+the <a class="reference external" href="https://golang.org/cmd/gofmt/">gofmt</a> tool.</p>
+<p>Go code should strive to be idiomatic. Two good sets of guidelines for what
+this means are <a class="reference external" href="https://golang.org/doc/effective_go.html">Effective Go</a> and <a class="reference external" href="https://code.google.com/p/go-wiki/wiki/CodeReviewComments">Go Code Review Comments</a>.</p>
+</div>
+</div>
+<div class="section" id="mechanical-source-issues">
+<h2><a class="toc-backref" href="#id7">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="#id8">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="#id9">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="#id10">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">/// This file contains the declaration of the Instruction class, which is the</span>
+<span class="c1">/// 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 (identified by the <tt class="docutils literal"><span class="pre">///</span></tt> comment
+marker instead of the usual <tt class="docutils literal"><span class="pre">//</span></tt>) describing the purpose of the file. The
+first sentence or a passage beginning with <tt class="docutils literal"><span class="pre">\brief</span></tt> is used as an abstract.
+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="#id11">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="#id12">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="#id13">Comment Formatting</a><a class="headerlink" href="#comment-formatting" title="Permalink to this headline">¶</a></h4>
+<p>In general, prefer C++ style comments (<tt class="docutils literal"><span class="pre">//</span></tt> for normal comments, <tt class="docutils literal"><span class="pre">///</span></tt> for
+<tt class="docutils literal"><span class="pre">doxygen</span></tt> documentation 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="#id14">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 paragraphs for all public interfaces (public classes,
+member and non-member functions). Don’t just restate the information that can
+be inferred from the API name. The first sentence or a paragraph beginning
+with <tt class="docutils literal"><span class="pre">\brief</span></tt> is used as an abstract. 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">/// Sets the xyzzy property to \p Baz.</span>
+<span class="kt">void</span> <span class="nf">setXyzzy</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">/// 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">/// 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="#id15"><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="#id16">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="#id17">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="#id18">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. With the introduction of C++11, there are some new formatting
+challenges that merit some suggestions to help have consistent, maintainable,
+and tool-friendly formatting and indentation.</p>
+<div class="section" id="format-lambdas-like-blocks-of-code">
+<h5><a class="toc-backref" href="#id19">Format Lambdas Like Blocks Of Code</a><a class="headerlink" href="#format-lambdas-like-blocks-of-code" title="Permalink to this headline">¶</a></h5>
+<p>When formatting a multi-line lambda, format it like a block of code, that’s
+what it is. If there is only one multi-line lambda in a statement, and there
+are no expressions lexically after it in the statement, drop the indent to the
+standard two space indent for a block of code, as if it were an if-block opened
+by the preceding part of the statement:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">std</span><span class="o">::</span><span class="n">sort</span><span class="p">(</span><span class="n">foo</span><span class="p">.</span><span class="n">begin</span><span class="p">(),</span> <span class="n">foo</span><span class="p">.</span><span class="n">end</span><span class="p">(),</span> <span class="p">[</span><span class="o">&</span><span class="p">](</span><span class="n">Foo</span> <span class="n">a</span><span class="p">,</span> <span class="n">Foo</span> <span class="n">b</span><span class="p">)</span> <span class="o">-></span> <span class="kt">bool</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">blah</span> <span class="o"><</span> <span class="n">b</span><span class="p">.</span><span class="n">blah</span><span class="p">)</span>
+ <span class="k">return</span> <span class="nb">true</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">baz</span> <span class="o"><</span> <span class="n">b</span><span class="p">.</span><span class="n">baz</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="n">a</span><span class="p">.</span><span class="n">bam</span> <span class="o"><</span> <span class="n">b</span><span class="p">.</span><span class="n">bam</span><span class="p">;</span>
+<span class="p">});</span>
+</pre></div>
+</div>
+<p>To take best advantage of this formatting, if you are designing an API which
+accepts a continuation or single callable argument (be it a functor, or
+a <tt class="docutils literal"><span class="pre">std::function</span></tt>), it should be the last argument if at all possible.</p>
+<p>If there are multiple multi-line lambdas in a statement, or there is anything
+interesting after the lambda in the statement, indent the block two spaces from
+the indent of the <tt class="docutils literal"><span class="pre">[]</span></tt>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">dyn_switch</span><span class="p">(</span><span class="n">V</span><span class="o">-></span><span class="n">stripPointerCasts</span><span class="p">(),</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">PHINode</span> <span class="o">*</span><span class="n">PN</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process phis...</span>
+ <span class="p">},</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">SelectInst</span> <span class="o">*</span><span class="n">SI</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process selects...</span>
+ <span class="p">},</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">LoadInst</span> <span class="o">*</span><span class="n">LI</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process loads...</span>
+ <span class="p">},</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">AllocaInst</span> <span class="o">*</span><span class="n">AI</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process allocas...</span>
+ <span class="p">});</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="braced-initializer-lists">
+<h5><a class="toc-backref" href="#id20">Braced Initializer Lists</a><a class="headerlink" href="#braced-initializer-lists" title="Permalink to this headline">¶</a></h5>
+<p>With C++11, there are significantly more uses of braced lists to perform
+initialization. These allow you to easily construct aggregate temporaries in
+expressions among other niceness. They now have a natural way of ending up
+nested within each other and within function calls in order to build up
+aggregates (such as option structs) from local variables. To make matters
+worse, we also have many more uses of braces in an expression context that are
+<em>not</em> performing initialization.</p>
+<p>The historically common formatting of braced initialization of aggregate
+variables does not mix cleanly with deep nesting, general expression contexts,
+function arguments, and lambdas. We suggest new code use a simple rule for
+formatting braced initialization lists: act as-if the braces were parentheses
+in a function call. The formatting rules exactly match those already well
+understood for formatting nested function calls. Examples:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">foo</span><span class="p">({</span><span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">,</span> <span class="n">c</span><span class="p">},</span> <span class="p">{</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">});</span>
+
+<span class="n">llvm</span><span class="o">::</span><span class="n">Constant</span> <span class="o">*</span><span class="n">Mask</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">ConstantInt</span><span class="o">::</span><span class="n">get</span><span class="p">(</span><span class="n">llvm</span><span class="o">::</span><span class="n">Type</span><span class="o">::</span><span class="n">getInt32Ty</span><span class="p">(</span><span class="n">getLLVMContext</span><span class="p">()),</span> <span class="mi">0</span><span class="p">),</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">ConstantInt</span><span class="o">::</span><span class="n">get</span><span class="p">(</span><span class="n">llvm</span><span class="o">::</span><span class="n">Type</span><span class="o">::</span><span class="n">getInt32Ty</span><span class="p">(</span><span class="n">getLLVMContext</span><span class="p">()),</span> <span class="mi">1</span><span class="p">),</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">ConstantInt</span><span class="o">::</span><span class="n">get</span><span class="p">(</span><span class="n">llvm</span><span class="o">::</span><span class="n">Type</span><span class="o">::</span><span class="n">getInt32Ty</span><span class="p">(</span><span class="n">getLLVMContext</span><span class="p">()),</span> <span class="mi">2</span><span class="p">)};</span>
+</pre></div>
+</div>
+<p>This formatting scheme also makes it particularly easy to get predictable,
+consistent, and automatic formatting with tools like <a class="reference external" href="http://clang.llvm.org/docs/ClangFormat.html">Clang Format</a>.</p>
+</div>
+</div>
+</div>
+<div class="section" id="language-and-compiler-issues">
+<h3><a class="toc-backref" href="#id21">Language and Compiler Issues</a><a class="headerlink" href="#language-and-compiler-issues" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="treat-compiler-warnings-like-errors">
+<h4><a class="toc-backref" href="#id22">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="#id23">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="#id24">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 internal" href="ProgrammersManual.html#isa"><em>isa<>, cast<>, and dyn_cast<></em></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="#id25">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="#id26">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 (e.g., MSVC). This can lead to problems at link time.</p>
+<ul class="simple">
+<li>All declarations and definitions of a given <tt class="docutils literal"><span class="pre">class</span></tt> or <tt class="docutils literal"><span class="pre">struct</span></tt> must use
+the same keyword. For example:</li>
+</ul>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span><span class="p">;</span>
+
+<span class="c1">// Breaks mangling in MSVC.</span>
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span> <span class="kt">int</span> <span class="n">Data</span><span class="p">;</span> <span class="p">};</span>
+</pre></div>
+</div>
+<ul class="simple">
+<li>As a rule of thumb, <tt class="docutils literal"><span class="pre">struct</span></tt> should be kept to structures where <em>all</em>
+members are declared public.</li>
+</ul>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Foo feels like a class... this is strange.</span>
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span>
+<span class="nl">private:</span>
+ <span class="kt">int</span> <span class="n">Data</span><span class="p">;</span>
+<span class="nl">public:</span>
+ <span class="n">Foo</span><span class="p">()</span> <span class="o">:</span> <span class="n">Data</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="p">}</span>
+ <span class="kt">int</span> <span class="n">getData</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span> <span class="k">return</span> <span class="n">Data</span><span class="p">;</span> <span class="p">}</span>
+ <span class="kt">void</span> <span class="n">setData</span><span class="p">(</span><span class="kt">int</span> <span class="n">D</span><span class="p">)</span> <span class="p">{</span> <span class="n">Data</span> <span class="o">=</span> <span class="n">D</span><span class="p">;</span> <span class="p">}</span>
+<span class="p">};</span>
+
+<span class="c1">// Bar isn't POD, but it does look like a struct.</span>
+<span class="k">struct</span> <span class="n">Bar</span> <span class="p">{</span>
+ <span class="kt">int</span> <span class="n">Data</span><span class="p">;</span>
+ <span class="n">Bar</span><span class="p">()</span> <span class="o">:</span> <span class="n">Data</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="p">}</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="do-not-use-braced-initializer-lists-to-call-a-constructor">
+<h4><a class="toc-backref" href="#id27">Do not use Braced Initializer Lists to Call a Constructor</a><a class="headerlink" href="#do-not-use-braced-initializer-lists-to-call-a-constructor" title="Permalink to this headline">¶</a></h4>
+<p>In C++11 there is a “generalized initialization syntax” which allows calling
+constructors using braced initializer lists. Do not use these to call
+constructors with any interesting logic or if you care that you’re calling some
+<em>particular</em> constructor. Those should look like function calls using
+parentheses rather than like aggregate initialization. Similarly, if you need
+to explicitly name the type and call its constructor to create a temporary,
+don’t use a braced initializer list. Instead, use a braced initializer list
+(without any type for temporaries) when doing aggregate initialization or
+something notionally equivalent. Examples:</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="c1">// Construct a Foo by reading data from the disk in the whizbang format, ...</span>
+ <span class="n">Foo</span><span class="p">(</span><span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="n">filename</span><span class="p">);</span>
+
+ <span class="c1">// Construct a Foo by looking up the Nth element of some global data ...</span>
+ <span class="n">Foo</span><span class="p">(</span><span class="kt">int</span> <span class="n">N</span><span class="p">);</span>
+
+ <span class="c1">// ...</span>
+<span class="p">};</span>
+
+<span class="c1">// The Foo constructor call is very deliberate, no braces.</span>
+<span class="n">std</span><span class="o">::</span><span class="n">fill</span><span class="p">(</span><span class="n">foo</span><span class="p">.</span><span class="n">begin</span><span class="p">(),</span> <span class="n">foo</span><span class="p">.</span><span class="n">end</span><span class="p">(),</span> <span class="n">Foo</span><span class="p">(</span><span class="s">"name"</span><span class="p">));</span>
+
+<span class="c1">// The pair is just being constructed like an aggregate, use braces.</span>
+<span class="n">bar_map</span><span class="p">.</span><span class="n">insert</span><span class="p">({</span><span class="n">my_key</span><span class="p">,</span> <span class="n">my_value</span><span class="p">});</span>
+</pre></div>
+</div>
+<p>If you use a braced initializer list when initializing a variable, use an equals before the open curly brace:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">data</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span><span class="mi">0</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="use-auto-type-deduction-to-make-code-more-readable">
+<h4><a class="toc-backref" href="#id28">Use <tt class="docutils literal"><span class="pre">auto</span></tt> Type Deduction to Make Code More Readable</a><a class="headerlink" href="#use-auto-type-deduction-to-make-code-more-readable" title="Permalink to this headline">¶</a></h4>
+<p>Some are advocating a policy of “almost always <tt class="docutils literal"><span class="pre">auto</span></tt>” in C++11, however LLVM
+uses a more moderate stance. Use <tt class="docutils literal"><span class="pre">auto</span></tt> if and only if it makes the code more
+readable or easier to maintain. Don’t “almost always” use <tt class="docutils literal"><span class="pre">auto</span></tt>, but do use
+<tt class="docutils literal"><span class="pre">auto</span></tt> with initializers like <tt class="docutils literal"><span class="pre">cast<Foo>(...)</span></tt> or other places where the
+type is already obvious from the context. Another time when <tt class="docutils literal"><span class="pre">auto</span></tt> works well
+for these purposes is when the type would have been abstracted away anyways,
+often behind a container’s typedef such as <tt class="docutils literal"><span class="pre">std::vector<T>::iterator</span></tt>.</p>
+</div>
+<div class="section" id="beware-unnecessary-copies-with-auto">
+<h4><a class="toc-backref" href="#id29">Beware unnecessary copies with <tt class="docutils literal"><span class="pre">auto</span></tt></a><a class="headerlink" href="#beware-unnecessary-copies-with-auto" title="Permalink to this headline">¶</a></h4>
+<p>The convenience of <tt class="docutils literal"><span class="pre">auto</span></tt> makes it easy to forget that its default behavior
+is a copy. Particularly in range-based <tt class="docutils literal"><span class="pre">for</span></tt> loops, careless copies are
+expensive.</p>
+<p>As a rule of thumb, use <tt class="docutils literal"><span class="pre">auto</span> <span class="pre">&</span></tt> unless you need to copy the result, and use
+<tt class="docutils literal"><span class="pre">auto</span> <span class="pre">*</span></tt> when copying pointers.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Typically there's no reason to copy.</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">const</span> <span class="k">auto</span> <span class="o">&</span><span class="n">Val</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">observe</span><span class="p">(</span><span class="n">Val</span><span class="p">);</span> <span class="p">}</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="o">&</span><span class="n">Val</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">Val</span><span class="p">.</span><span class="n">change</span><span class="p">();</span> <span class="p">}</span>
+
+<span class="c1">// Remove the reference if you really want a new copy.</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="n">Val</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">Val</span><span class="p">.</span><span class="n">change</span><span class="p">();</span> <span class="n">saveSomewhere</span><span class="p">(</span><span class="n">Val</span><span class="p">);</span> <span class="p">}</span>
+
+<span class="c1">// Copy pointers, but make it clear that they're pointers.</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">const</span> <span class="k">auto</span> <span class="o">*</span><span class="n">Ptr</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">observe</span><span class="p">(</span><span class="o">*</span><span class="n">Ptr</span><span class="p">);</span> <span class="p">}</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="o">*</span><span class="n">Ptr</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">Ptr</span><span class="o">-></span><span class="n">change</span><span class="p">();</span> <span class="p">}</span>
+</pre></div>
+</div>
+</div>
+</div>
+</div>
+<div class="section" id="style-issues">
+<h2><a class="toc-backref" href="#id30">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="#id31">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="#id32">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="#id33"><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="#id34">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="#id35">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="#id36">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="#id37">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="#id38">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="#id39">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="#id40">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="#id41">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="#id42">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="#id43">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="don-t-evaluate-end-every-time-through-a-loop">
+<h4><a class="toc-backref" href="#id44">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="#id45"><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="#id46">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="#id47">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="#id48">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="#id49">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="#id50">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="#id51">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="#id52">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. To facilitate this and
+avoid some insanely deep nesting on occasion, don’t indent namespaces. If it
+helps readability, feel free to add a comment indicating what namespace is
+being closed by a <tt class="docutils literal"><span class="pre">}</span></tt>. 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>Feel free to skip the closing comment when the namespace being closed is
+obvious for any reason. For example, the outer-most namespace in a header file
+is rarely a source of confusion. But namespaces both anonymous and named in
+source files that are being closed half way through the file probably could use
+clarification.</p>
+</div>
+<div class="section" id="anonymous-namespaces">
+<span id="static"></span><h4><a class="toc-backref" href="#id53">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="#id54">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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CommandGuide/FileCheck.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CommandGuide/FileCheck.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CommandGuide/FileCheck.html (added)
+++ www-releases/trunk/3.9.0/docs/CommandGuide/FileCheck.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,531 @@
+
+<!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.9 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.9',
+ 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.9 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--check-prefixes">
+<tt class="descname">--check-prefixes</tt><tt class="descclassname"> prefix1,prefix2,...</tt><a class="headerlink" href="#cmdoption--check-prefixes" title="Permalink to this definition">¶</a></dt>
+<dd><p>An alias of <a class="reference internal" href="#cmdoption--check-prefix"><em class="xref std std-option">--check-prefix</em></a> that allows multiple prefixes to be
+specified as a comma separated list.</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--match-full-lines">
+<tt class="descname">--match-full-lines</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--match-full-lines" title="Permalink to this definition">¶</a></dt>
+<dd><p>By default, FileCheck allows matches of anywhere on a line. This
+option will require all positive matches to cover an entire
+line. Leading and trailing whitespace is ignored, unless
+<a class="reference internal" href="#cmdoption--strict-whitespace"><em class="xref std std-option">--strict-whitespace</em></a> is also specified. (Note: negative
+matches from <tt class="docutils literal"><span class="pre">CHECK-NOT</span></tt> are not affected by this option!)</p>
+<p>Passing this option is equivalent to inserting <tt class="docutils literal"><span class="pre">{{^</span> <span class="pre">*}}</span></tt> or
+<tt class="docutils literal"><span class="pre">{{^}}</span></tt> before, and <tt class="docutils literal"><span class="pre">{{</span> <span class="pre">*$}}</span></tt> or <tt class="docutils literal"><span class="pre">{{$}}</span></tt> after every positive
+check pattern.</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--implicit-check-not">
+<tt class="descname">--implicit-check-not</tt><tt class="descclassname"> check-pattern</tt><a class="headerlink" href="#cmdoption--implicit-check-not" title="Permalink to this definition">¶</a></dt>
+<dd><p>Adds implicit negative checks for the specified patterns between positive
+checks. The option allows writing stricter tests without stuffing them with
+<tt class="docutils literal"><span class="pre">CHECK-NOT</span></tt>s.</p>
+<p>For example, “<tt class="docutils literal"><span class="pre">--implicit-check-not</span> <span class="pre">warning:</span></tt>” can be useful when testing
+diagnostic messages from tools that don’t have an option similar to <tt class="docutils literal"><span class="pre">clang</span>
+<span class="pre">-verify</span></tt>. With this option FileCheck will verify that input does not contain
+warnings not covered by any <tt class="docutils literal"><span class="pre">CHECK:</span></tt> patterns.</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 <cite>-check-prefix</cite> 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-same-directive">
+<h3>The “CHECK-SAME:” directive<a class="headerlink" href="#the-check-same-directive" title="Permalink to this headline">¶</a></h3>
+<p>Sometimes you want to match lines and would like to verify that matches happen
+on the same line as the previous match. 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-SAME:</span></tt>” directives to specify this. If you specified a custom
+check prefix, just use “<tt class="docutils literal"><span class="pre"><PREFIX>-SAME:</span></tt>”.</p>
+<p>“<tt class="docutils literal"><span class="pre">CHECK-SAME:</span></tt>” is particularly powerful in conjunction with “<tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt>”
+(described below).</p>
+<p>For example, the following works like you’d expect:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="nv-Anonymous">!0</span> <span class="p">=</span> <span class="nv">!DILocation</span><span class="p">(</span><span class="nl">line:</span> <span class="m">5</span><span class="p">,</span> <span class="nl">scope:</span> <span class="nv-Anonymous">!1</span><span class="p">,</span> <span class="nl">inlinedAt:</span> <span class="nv-Anonymous">!2</span><span class="p">)</span>
+
+<span class="c">; CHECK: !DILocation(line: 5,</span>
+<span class="c">; CHECK-NOT: column:</span>
+<span class="c">; CHECK-SAME: scope: ![[SCOPE:[0-9]+]]</span>
+</pre></div>
+</div>
+<p>“<tt class="docutils literal"><span class="pre">CHECK-SAME:</span></tt>” directives reject the input if there are any newlines between
+it and the previous directive. A “<tt class="docutils literal"><span class="pre">CHECK-SAME:</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-text"><div class="highlight"><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>
+</div>
+<p>While this other code, will not:</p>
+<div class="highlight-text"><div class="highlight"><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>
+</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>All FileCheck directives 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 class="section" id="matching-newline-characters">
+<h3>Matching Newline Characters<a class="headerlink" href="#matching-newline-characters" title="Permalink to this headline">¶</a></h3>
+<p>To match newline characters in regular expressions the character class
+<tt class="docutils literal"><span class="pre">[[:space:]]</span></tt> can be used. For example, the following pattern:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// CHECK: DW_AT_location [DW_FORM_sec_offset] ([[DLOC:0x[0-9a-f]+]]){{[[:space:]].*}}"intd"</span>
+</pre></div>
+</div>
+<p>matches output of the form (from llvm-dwarfdump):</p>
+<div class="highlight-text"><div class="highlight"><pre>DW_AT_location [DW_FORM_sec_offset] (0x00000233)
+DW_AT_name [DW_FORM_strp] ( .debug_str[0x000000c9] = "intd")
+</pre></div>
+</div>
+<p>letting us set the <strong class="program">FileCheck</strong> variable <tt class="docutils literal"><span class="pre">DLOC</span></tt> to the desired value
+<tt class="docutils literal"><span class="pre">0x00000233</span></tt>, extracted from the line immediately preceding “<tt class="docutils literal"><span class="pre">intd</span></tt>”.</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="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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CommandGuide/bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CommandGuide/bugpoint.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CommandGuide/bugpoint.html (added)
+++ www-releases/trunk/3.9.0/docs/CommandGuide/bugpoint.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,265 @@
+
+<!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.9 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.9',
+ 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.9 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-dwarfdump - print contents of DWARF sections" href="llvm-dwarfdump.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-dwarfdump.html" title="llvm-dwarfdump - print contents of DWARF sections"
+ 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 <a class="reference internal" href="../Bugpoint.html"><em>LLVM bugpoint tool: design and usage</em></a> 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>–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. The command should exit with a
+failure exit code if the file is “interesting” and should exit with a
+success exit code (i.e. 0) otherwise (this is the same as if it crashed on
+“interesting” inputs).</p>
+<p>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>
+<p><strong>–verbose-errors</strong>=<em>{true,false}</em></p>
+<blockquote>
+<div>The default behavior of bugpoint is to print “<crash>” when it finds a reduced
+test that crashes compilation. This flag prints the output of the crashing
+program to stderr. This is useful to make sure it is the same error being
+tracked down and not a different error that happens to crash the compiler as
+well. Defaults to false.</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-dwarfdump.html" title="llvm-dwarfdump - print contents of DWARF sections"
+ >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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CommandGuide/index.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CommandGuide/index.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CommandGuide/index.html (added)
+++ www-releases/trunk/3.9.0/docs/CommandGuide/index.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,149 @@
+
+<!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.9 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.9',
+ 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.9 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-lib.html">llvm-lib - LLVM lib.exe compatible library tool</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-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-profdata.html">llvm-profdata - Profile data tool</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>
+<li class="toctree-l1"><a class="reference internal" href="llvm-dwarfdump.html">llvm-dwarfdump - print contents of DWARF sections</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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CommandGuide/lit.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CommandGuide/lit.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CommandGuide/lit.html (added)
+++ www-releases/trunk/3.9.0/docs/CommandGuide/lit.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,553 @@
+
+<!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.9 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.9',
+ 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.9 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">
+<span id="cmdoption--help"></span><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">
+<span id="cmdoption--threads"></span><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-D">
+<span id="cmdoption-D"></span><span id="cmdoption--param"></span><span id="cmdoption--param"></span><tt class="descname">-D</tt><tt class="descclassname"> NAME</tt><tt class="descclassname">, </tt><tt class="descname">-D</tt><tt class="descclassname"> NAME=VALUE</tt><tt class="descclassname">, </tt><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-D" 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">
+<span id="cmdoption--quiet"></span><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">
+<span id="cmdoption--succinct"></span><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">
+<span id="cmdoption--verbose"></span><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-a">
+<span id="cmdoption--show-all"></span><tt class="descname">-a</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--show-all</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-a" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show more information about all tests, for example the entire test
+commandline and output.</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>
+
+<dl class="option">
+<dt id="cmdoption--show-unsupported">
+<tt class="descname">--show-unsupported</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-unsupported" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the names of unsupported tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--show-xfail">
+<tt class="descname">--show-xfail</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-xfail" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the names of tests that were expected to fail.</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 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_config</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>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 directory
+— 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="pre-defined-substitutions">
+<h3>PRE-DEFINED SUBSTITUTIONS<a class="headerlink" href="#pre-defined-substitutions" title="Permalink to this headline">¶</a></h3>
+<p><strong class="program">lit</strong> provides various patterns that can be used with the RUN command.
+These are defined in TestRunner.py.</p>
+<blockquote>
+<div><table border="1" class="docutils">
+<colgroup>
+<col width="16%" />
+<col width="84%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Macro</th>
+<th class="head">Substitution</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>%s</td>
+<td>source path (path to the file currently being run)</td>
+</tr>
+<tr class="row-odd"><td>%S</td>
+<td>source dir (directory of the file currently being run)</td>
+</tr>
+<tr class="row-even"><td>%p</td>
+<td>same as %S</td>
+</tr>
+<tr class="row-odd"><td>%{pathsep}</td>
+<td>path separator</td>
+</tr>
+<tr class="row-even"><td>%t</td>
+<td>temporary file name unique to the test</td>
+</tr>
+<tr class="row-odd"><td>%T</td>
+<td>temporary directory unique to the test</td>
+</tr>
+<tr class="row-even"><td>%%</td>
+<td>%</td>
+</tr>
+<tr class="row-odd"><td>%/s</td>
+<td>same as %s but replace all / with \</td>
+</tr>
+<tr class="row-even"><td>%/S</td>
+<td>same as %S but replace all / with \</td>
+</tr>
+<tr class="row-odd"><td>%/p</td>
+<td>same as %p but replace all / with \</td>
+</tr>
+<tr class="row-even"><td>%/t</td>
+<td>same as %t but replace all / with \</td>
+</tr>
+<tr class="row-odd"><td>%/T</td>
+<td>same as %T but replace all / with \</td>
+</tr>
+</tbody>
+</table>
+</div></blockquote>
+<p>Further substitution patterns might be defined by each test module.
+See the modules <a class="reference internal" href="#local-configuration-files"><em>LOCAL CONFIGURATION FILES</em></a>.</p>
+<p>More information on the testing infrastucture can be found in the
+<a class="reference internal" href="../TestingGuide.html"><em>LLVM Testing Infrastructure Guide</em></a>.</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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CommandGuide/llc.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CommandGuide/llc.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CommandGuide/llc.html (added)
+++ www-releases/trunk/3.9.0/docs/CommandGuide/llc.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,315 @@
+
+<!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.9 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.9',
+ 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.9 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="lli.html#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">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--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="lli.html#cmdoption-march"><em class="xref std std-option">-march</em></a> option so that code can be generated for that target.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-meabi">
+<tt class="descname">-meabi</tt><tt class="descclassname">=[default|gnu|4|5]</tt><a class="headerlink" href="#cmdoption-meabi" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify which EABI version should conform to. Valid EABI versions are <em>gnu</em>,
+<em>4</em> and <em>5</em>. Default value (<em>default</em>) depends on the triple.</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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/3.9.0/docs/CommandGuide/lli.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.0/docs/CommandGuide/lli.html?rev=280493&view=auto
==============================================================================
--- www-releases/trunk/3.9.0/docs/CommandGuide/lli.html (added)
+++ www-releases/trunk/3.9.0/docs/CommandGuide/lli.html Fri Sep 2 10:56:46 2016
@@ -0,0 +1,353 @@
+
+<!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.9 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.9',
+ 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.9 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 class="program">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 class="program">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 or an
+interpreter.</p>
+<p><strong class="program">lli</strong> is <em>not</em> an emulator. It will not execute IR of different architectures
+and it can only interpret (or JIT-compile) for the host architecture.</p>
+<p>The JIT compiler takes the same arguments as other tools, like <strong class="program">llc</strong>,
+but they don’t necessarily work for the interpreter.</p>
+<p>If <cite>filename</cite> is not specified, then <strong class="program">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>
+<dl class="option">
+<dt id="cmdoption-fake-argv0">
+<tt class="descname">-fake-argv0</tt><tt class="descclassname">=executable</tt><a class="headerlink" href="#cmdoption-fake-argv0" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override the <tt class="docutils literal"><span class="pre">argv[0]</span></tt> value passed into the executing program.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-force-interpreter">
+<tt class="descname">-force-interpreter</tt><tt class="descclassname">={false,true}</tt><a class="headerlink" href="#cmdoption-force-interpreter" title="Permalink to this definition">¶</a></dt>
+<dd><p>If set to true, use the interpreter even if a just-in-time compiler is available
+for this architecture. Defaults to false.</p>
+</dd></dl>
+
+<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-load">
+<tt class="descname">-load</tt><tt class="descclassname">=pluginfilename</tt><a class="headerlink" href="#cmdoption-load" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">lli</strong> to load the plugin (shared object) named <em>pluginfilename</em> and use
+it for optimization.</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 from the code-generation passes. This is only meaningful for
+the just-in-time compiler, at present.</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 code-generation pass and print it to
+standard error.</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>Print out the version of <strong class="program">lli</strong> and exit without doing anything else.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="target-options">
+<h2>TARGET OPTIONS<a class="headerlink" href="#target-options" title="Permalink to this headline">¶</a></h2>
+<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 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.</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 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.</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:
+<strong>llvm-as < /dev/null | llc -march=xyz -mcpu=help</strong></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:
+<strong>llvm-as < /dev/null | llc -march=xyz -mattr=help</strong></p>
+</dd></dl>
+
+</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>
+<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 increase floating point precision.</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>Causes <strong class="program">lli</strong> to enable optimizations that may decrease floating point
+precision.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-soft-float">
+<tt class="descname">-soft-float</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-soft-float" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">lli</strong> to generate software floating point library calls instead of
+equivalent hardware instructions.</p>
+</dd></dl>
+
+</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>
+<dl class="option">
+<dt id="cmdoption-code-model">
+<tt class="descname">-code-model</tt><tt class="descclassname">=model</tt><a class="headerlink" href="#cmdoption-code-model" title="Permalink to this definition">¶</a></dt>
+<dd><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>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-disable-post-RA-scheduler">
+<tt class="descname">-disable-post-RA-scheduler</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-disable-post-RA-scheduler" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable scheduling after register allocation.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-disable-spill-fusing">
+<tt class="descname">-disable-spill-fusing</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-disable-spill-fusing" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable fusing of spill code into instructions.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-jit-enable-eh">
+<tt class="descname">-jit-enable-eh</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-jit-enable-eh" title="Permalink to this definition">¶</a></dt>
+<dd><p>Exception handling should be enabled in the just-in-time compiler.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-join-liveintervals">
+<tt class="descname">-join-liveintervals</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-join-liveintervals" title="Permalink to this definition">¶</a></dt>
+<dd><p>Coalesce copies (default=true).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-nozero-initialized-in-bss">
+<tt class="descname">-nozero-initialized-in-bss</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-nozero-initialized-in-bss" title="Permalink to this definition">¶</a></dt>
+<dd><p>Don’t place zero-initialized symbols into the BSS section.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-pre-RA-sched">
+<tt class="descname">-pre-RA-sched</tt><tt class="descclassname">=scheduler</tt><a class="headerlink" href="#cmdoption-pre-RA-sched" title="Permalink to this definition">¶</a></dt>
+<dd><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>
+</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>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>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-relocation-model">
+<tt class="descname">-relocation-model</tt><tt class="descclassname">=model</tt><a class="headerlink" href="#cmdoption-relocation-model" title="Permalink to this definition">¶</a></dt>
+<dd><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>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-spiller">
+<tt class="descname">-spiller</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-spiller" title="Permalink to this definition">¶</a></dt>
+<dd><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>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-x86-asm-syntax">
+<tt class="descname">-x86-asm-syntax</tt><tt class="descclassname">=syntax</tt><a class="headerlink" href="#cmdoption-x86-asm-syntax" title="Permalink to this definition">¶</a></dt>
+<dd><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>
+</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">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><strong class="program">llc</strong></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-2016, LLVM Project.
+ Last updated on 2016-08-31.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+ </div>
+ </body>
+</html>
\ No newline at end of file
More information about the llvm-commits
mailing list