[llvm-commits] [www-releases] r170845 [1/55] - in /www-releases/trunk/3.2/docs: ./ CommandGuide/ HistoricalNotes/ _static/ _templates/ _themes/ _themes/llvm-theme/ _themes/llvm-theme/static/ doxygen/ doxygen/html/ llvm-theme/ llvm-theme/static/ tutorial/

[Tanya Lattner]

Author: tbrethou
Date: Fri Dec 21 00:57:24 2012
New Revision: 170845

URL: http://llvm.org/viewvc/llvm-project?rev=170845&view=rev
Log:
Add 3.2 docs

Added:
    www-releases/trunk/3.2/docs/
    www-releases/trunk/3.2/docs/AliasAnalysis.rst
    www-releases/trunk/3.2/docs/Atomics.rst
    www-releases/trunk/3.2/docs/BitCodeFormat.rst
    www-releases/trunk/3.2/docs/BranchWeightMetadata.rst
    www-releases/trunk/3.2/docs/Bugpoint.rst
    www-releases/trunk/3.2/docs/CMake.rst
    www-releases/trunk/3.2/docs/CodeGenerator.rst
    www-releases/trunk/3.2/docs/CodingStandards.rst
    www-releases/trunk/3.2/docs/CommandGuide/
    www-releases/trunk/3.2/docs/CommandGuide/FileCheck.rst
    www-releases/trunk/3.2/docs/CommandGuide/bugpoint.rst
    www-releases/trunk/3.2/docs/CommandGuide/index.rst
    www-releases/trunk/3.2/docs/CommandGuide/lit.rst
    www-releases/trunk/3.2/docs/CommandGuide/llc.rst
    www-releases/trunk/3.2/docs/CommandGuide/lli.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-ar.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-as.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-bcanalyzer.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-build.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-config.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-cov.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-diff.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-dis.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-extract.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-link.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-nm.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-prof.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-ranlib.rst
    www-releases/trunk/3.2/docs/CommandGuide/llvm-stress.rst
    www-releases/trunk/3.2/docs/CommandGuide/opt.rst
    www-releases/trunk/3.2/docs/CommandGuide/tblgen.rst
    www-releases/trunk/3.2/docs/CommandLine.rst
    www-releases/trunk/3.2/docs/CompilerWriterInfo.rst
    www-releases/trunk/3.2/docs/DebuggingJITedCode.rst
    www-releases/trunk/3.2/docs/DeveloperPolicy.rst
    www-releases/trunk/3.2/docs/ExceptionHandling.rst
    www-releases/trunk/3.2/docs/ExtendedIntegerResults.txt
    www-releases/trunk/3.2/docs/ExtendingLLVM.rst
    www-releases/trunk/3.2/docs/FAQ.rst
    www-releases/trunk/3.2/docs/GCCFEBuildInstrs.html
    www-releases/trunk/3.2/docs/GarbageCollection.html
    www-releases/trunk/3.2/docs/GetElementPtr.rst
    www-releases/trunk/3.2/docs/GettingStarted.rst
    www-releases/trunk/3.2/docs/GettingStartedVS.rst
    www-releases/trunk/3.2/docs/GoldPlugin.rst
    www-releases/trunk/3.2/docs/HistoricalNotes/
    www-releases/trunk/3.2/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2000-12-06-EncodingIdea.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-01-31-UniversalIRIdea.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-06-TypeNotationDebate.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp1.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp2.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-09-AdveComments.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-13-Reference-Memory.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-05-18-ExceptionHandling.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-05-19-ExceptionResponse.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-06-01-GCCOptimizations.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-06-20-.NET-Differences.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-07-06-LoweringIRForCodeGen.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2002-05-12-InstListChange.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2002-06-25-MegaPatchInfo.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2003-01-23-CygwinNotes.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2003-06-25-Reoptimizer1.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2003-06-26-Reoptimizer2.txt
    www-releases/trunk/3.2/docs/HistoricalNotes/2007-OriginalClangReadme.txt
    www-releases/trunk/3.2/docs/HowToAddABuilder.rst
    www-releases/trunk/3.2/docs/HowToBuildOnARM.rst
    www-releases/trunk/3.2/docs/HowToReleaseLLVM.html
    www-releases/trunk/3.2/docs/HowToSetUpLLVMStyleRTTI.rst
    www-releases/trunk/3.2/docs/HowToSubmitABug.rst
    www-releases/trunk/3.2/docs/HowToUseInstrMappings.rst   (with props)
    www-releases/trunk/3.2/docs/LLVMBuild.html
    www-releases/trunk/3.2/docs/LLVMBuild.txt
    www-releases/trunk/3.2/docs/LangRef.html
    www-releases/trunk/3.2/docs/Lexicon.rst
    www-releases/trunk/3.2/docs/LinkTimeOptimization.rst
    www-releases/trunk/3.2/docs/Makefile
    www-releases/trunk/3.2/docs/Makefile.sphinx
    www-releases/trunk/3.2/docs/MakefileGuide.rst
    www-releases/trunk/3.2/docs/MarkedUpDisassembly.rst
    www-releases/trunk/3.2/docs/Packaging.rst
    www-releases/trunk/3.2/docs/Passes.html
    www-releases/trunk/3.2/docs/Phabricator.rst
    www-releases/trunk/3.2/docs/ProgrammersManual.html
    www-releases/trunk/3.2/docs/Projects.rst
    www-releases/trunk/3.2/docs/README.txt
    www-releases/trunk/3.2/docs/ReleaseNotes.html
    www-releases/trunk/3.2/docs/SegmentedStacks.rst
    www-releases/trunk/3.2/docs/SourceLevelDebugging.html
    www-releases/trunk/3.2/docs/SphinxQuickstartTemplate.rst
    www-releases/trunk/3.2/docs/SystemLibrary.html
    www-releases/trunk/3.2/docs/TableGenFundamentals.rst
    www-releases/trunk/3.2/docs/TestSuiteMakefileGuide.html
    www-releases/trunk/3.2/docs/TestingGuide.html
    www-releases/trunk/3.2/docs/WritingAnLLVMBackend.html
    www-releases/trunk/3.2/docs/WritingAnLLVMPass.html
    www-releases/trunk/3.2/docs/_static/
    www-releases/trunk/3.2/docs/_static/lines.gif   (with props)
    www-releases/trunk/3.2/docs/_static/llvm.css
    www-releases/trunk/3.2/docs/_templates/
    www-releases/trunk/3.2/docs/_templates/indexsidebar.html
    www-releases/trunk/3.2/docs/_templates/layout.html
    www-releases/trunk/3.2/docs/_themes/
    www-releases/trunk/3.2/docs/_themes/llvm-theme/
    www-releases/trunk/3.2/docs/_themes/llvm-theme/layout.html
    www-releases/trunk/3.2/docs/_themes/llvm-theme/static/
    www-releases/trunk/3.2/docs/_themes/llvm-theme/static/contents.png   (with props)
    www-releases/trunk/3.2/docs/_themes/llvm-theme/static/llvm-theme.css
    www-releases/trunk/3.2/docs/_themes/llvm-theme/static/logo.png   (with props)
    www-releases/trunk/3.2/docs/_themes/llvm-theme/static/navigation.png   (with props)
    www-releases/trunk/3.2/docs/_themes/llvm-theme/theme.conf
    www-releases/trunk/3.2/docs/conf.py
    www-releases/trunk/3.2/docs/design_and_overview.rst
    www-releases/trunk/3.2/docs/development_process.rst
    www-releases/trunk/3.2/docs/doxygen/
    www-releases/trunk/3.2/docs/doxygen.cfg
    www-releases/trunk/3.2/docs/doxygen.cfg.in
    www-releases/trunk/3.2/docs/doxygen.css
    www-releases/trunk/3.2/docs/doxygen.footer
    www-releases/trunk/3.2/docs/doxygen.header
    www-releases/trunk/3.2/docs/doxygen.intro
    www-releases/trunk/3.2/docs/doxygen/html/
    www-releases/trunk/3.2/docs/doxygen/html/APFloat_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/APFloat_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/APFloat_8d_source.html
    www-releases/trunk/3.2/docs/doxygen/html/APFloat_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/APFloat_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/APInt_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/APInt_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/APSInt_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMAddressingModes_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMAddressingModes_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMAddressingModes_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmBackend_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmBackend_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmLexer_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmLexer_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmPrinter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmPrinter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmPrinter_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmPrinter_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmPrinter_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMAsmPrinter_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMBaseInstrInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMBaseInstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMBaseInstrInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMBaseRegisterInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMBaseRegisterInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMCallingConv_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMCodeEmitter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMConstantIslandPass_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMConstantIslandPass_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMConstantPoolValue_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMDisassembler_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMELFObjectWriter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMFixupKinds_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMFrameLowering_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMFrameLowering_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMFrameLowering_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMHazardRecognizer_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMHazardRecognizer_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMISelDAGToDAG_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMISelDAGToDAG_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMISelLowering_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMISelLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstPrinter_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstrInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstrInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstrInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstrInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMInstrInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMJITInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMJITInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMJITInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCAsmInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCExpr_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCExpr_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCTargetDesc_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMMCTargetDesc_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMMachObjectWriter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMMachineFunctionInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMMachineFunctionInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMMachineFunctionInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMMachineFunctionInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMRegisterInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMRegisterInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMRegisterInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMRelocations_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMSelectionDAGInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMSubtarget_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetMachine_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetMachine_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetMachine_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetObjectFile_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetObjectFile_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetObjectFile_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetObjectFile_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetObjectFile_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARMTargetObjectFile_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ARM_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARM_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARM_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ARM_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ARM_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ARM_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AddrModeMatcher_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/AddrModeMatcher_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AddressSanitizer_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/AddressingMode_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/AddressingMode_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/AddressingMode_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/AddressingMode_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/AggressiveAntiDepBreaker_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/AggressiveAntiDepBreaker_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/AggressiveAntiDepBreaker_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AliasAnalysisCounter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AliasAnalysisEvaluator_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AliasAnalysis_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/AliasSetTracker_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/AliasSetTracker_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/AliasSetTracker_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/AlignOf_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/AllocationOrder_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Allocator_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Allocator_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Allocator_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ArchiveInternals_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ArchiveReader_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ArchiveWriter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Archive_2Archive_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ArgumentPromotion_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Argument_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Argument_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Argument_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Argument_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/AsmCond_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/AsmLexer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/AsmLexer_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/AsmLexer_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/AsmLexer_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/AsmParser_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/AsmParser_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/AsmParser_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AsmPrinterInlineAsm_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AsmPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/AsmPrinter_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/AsmWriter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/AsmWriter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/AsmWriter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Atomic_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Atomic_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Atomic_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Atomic_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/AttributesImpl_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Attributes_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Attributes_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Attributes_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/AutoUpgrade_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/AutoUpgrade_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BarrierNoopPass_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BasicAliasAnalysis_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/BasicAliasAnalysis_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BasicBlockUtils_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BasicBlock_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BasicBlock_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Binary_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Binary_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Binary_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Binary_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Binary_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Binary_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Binary_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BitReader_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BitReader_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BitReader_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BitReader_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BitReader_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BitVector_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BitVector_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BitVector_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BitWriter_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/BitWriter_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BitcodeReader_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/BitcodeReader_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BitcodeReader_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BitcodeWriterPass_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Bitcode_2Archive_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Bitcode_2Archive_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Bitcode_2Archive_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BitstreamReader_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BitstreamReader_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BitstreamReader_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BitstreamWriter_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BitstreamWriter_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BlackList_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BlackList_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BlockFrequencyImpl_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BlockFrequencyInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BlockFrequencyInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BlockFrequencyInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BlockFrequency_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/BranchFolding_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/BranchFolding_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BranchFolding_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BranchFolding_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BranchFolding_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BranchFolding_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BranchFolding_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbabilityInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbabilityInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbabilityInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbabilityInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbabilityInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbability_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbability_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbability_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbability_8d_source.html
    www-releases/trunk/3.2/docs/doxygen/html/BranchProbability_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Briggs_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BuildLibCalls_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BuildLibCalls_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BypassSlowDivision_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/BypassSlowDivision_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/BypassSlowDivision_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CFGPrinter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CFGPrinter_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CFGPrinter_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/COFFAsmParser_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/COFFObjectFile_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/COFFObjectFile_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CPPBackend_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CalcSpillWeights_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CalcSpillWeights_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CallGraphSCCPass_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CallGraphSCCPass_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CallGraphSCCPass_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CallGraph_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CallGraph_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CallGraph_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CallGraph_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CallGraph_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CallSite_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CallSite_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CallingConvLower_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CallingConvLower_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CallingConv_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Capacity_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CaptureTracking_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CaptureTracking_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CaptureTracking_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CaptureTracking_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CaptureTracking_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Casting_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Casting_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Casting_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Casting_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Casting_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CellSPUTargetInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CloneFunction_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CloneFunction_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CloneModule_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Cloning_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Cloning_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Cloning_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CmpInstAnalysis_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CmpInstAnalysis_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CmpInstAnalysis_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/CmpInstAnalysis_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CodeExtractor_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CodeGenPrepare_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CodeGen_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CodeGen_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CodeGen_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CodeGen_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/CodeMetrics_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CodeMetrics_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CodeMetrics_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CodePlacementOpt_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/CodePlacementOpt_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CommandFlags_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CommandLine_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CommandLine_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CommandLine_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CommandLine_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CommandLine_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ConstantFold_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ConstantFolder_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ConstantFolder_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ConstantFolding_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ConstantFolding_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ConstantFolding_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ConstantMerge_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ConstantProp_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ConstantRange_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ConstantRange_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ConstantRange_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Constant_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Constant_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Constant_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ConstantsContext_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ConstantsContext_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ConstantsContext_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ConstantsContext_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ConstantsContext_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ConstantsContext_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Core_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Core_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Core_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CppBackendTargetInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/CppBackendTargetInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/CrashRecoveryContext_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/CrashRecoveryContext_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/CrashRecoveryContext_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/CriticalAntiDepBreaker_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DAGDeltaAlgorithm_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DFAPacketizer_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DFAPacketizer_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DFAPacketizer_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DFAPacketizer_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DFAPacketizer_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DIBuilder_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DIBuilder_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DIBuilder_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DIContext_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/DIE_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DIE_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DOTGraphTraits_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DOTGraphTraits_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DOTGraphTraits_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DOTGraphTraits_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFAbbreviationDeclaration_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DWARFAbbreviationDeclaration_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DWARFAbbreviationDeclaration_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFAttribute_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DWARFAttribute_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFCompileUnit_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFCompileUnit_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DWARFContext_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFContext_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DWARFContext_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAbbrev_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAbbrev_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAbbrev_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAbbrev_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAranges_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAranges_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAranges_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAranges_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugAranges_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugInfoEntry_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugInfoEntry_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugInfoEntry_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugInfoEntry_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugLine_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugLine_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugLine_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugLine_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugLine_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugRangeList_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugRangeList_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugRangeList_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugRangeList_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFDebugRangeList_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFFormValue_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/DWARFFormValue_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DWARFFormValue_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DWARFFormValue_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DWARFFormValue_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DataExtractor_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DataExtractor_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DataFlow_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DataFlow_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DataFlow_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DataStream_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DataTypes_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DbgInfoPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/DbgInfoPrinter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DeadArgumentElimination_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DebugInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DefaultPasses_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DeltaAlgorithm_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DeltaAlgorithm_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DemoteRegToStack_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DemoteRegToStack_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DenseMapInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DenseMapInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DenseMapInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DenseMapInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DependenceAnalysis_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DependenceAnalysis_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DepthFirstIterator_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DepthFirstIterator_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DerivedTypes_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DomPrinter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DomPrinter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DomPrinter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DomPrinter_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DominanceFrontier_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DominanceFrontier_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DominanceFrontier_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DominanceFrontier_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DominatorInternals_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Dominators_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DwarfAccelTable_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DwarfCompileUnit_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DwarfDebug_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/DwarfDebug_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DwarfDebug_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/DwarfEHPrepare_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DwarfEHPrepare_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DwarfException_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DwarfException_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DwarfException_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DwarfException_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Dwarf_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Dwarf_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Dwarf_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Dwarf_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Dwarf_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/DynamicLibrary_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/DynamicLibrary_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/DynamicLibrary_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/DynamicLibrary_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/EDDisassembler_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/EDInst_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/EDMain_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/EDMain_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/EDMain_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/EDOperand_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/EDOperand_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/EDOperand_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/EDOperand_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/EDToken_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/EDToken_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ELFAsmParser_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ELFObjectFile_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ELFObjectWriter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/EarlyCSE_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/EarlyIfConversion_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/EarlyIfConversion_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/EdgeBundles_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/EdgeBundles_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/EdgeBundles_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Endian_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/EnhancedDisassembly_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/EnhancedDisassembly_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/EquivalenceClasses_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/EquivalenceClasses_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/EquivalenceClasses_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Errno_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ErrorHandling_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ErrorHandling_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ErrorHandling_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ErrorHandling_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ExecutionDepsFix_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ExecutionDepsFix_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ExecutionEngineBindings_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Execution_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Execution_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Execution_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ExpandISelPseudos_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ExternalFunctions_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ExternalFunctions_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ExternalFunctions_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FEnv_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/FEnv_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/FastISel_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/FastISel_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/FastISel_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/FileOutputBuffer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/FileOutputBuffer_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/FileOutputBuffer_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/FileUtilities_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/FileUtilities_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FileUtilities_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FindUsedTypes_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/FindUsedTypes_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/FindUsedTypes_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/FindUsedTypes_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/FindUsedTypes_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FoldingSet_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/FoldingSet_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/FoldingSet_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/FoldingSet_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/FoldingSet_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Format_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Format_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Format_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Format_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FormattedStream_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/FormattedStream_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/FormattedStream_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/FormattedStream_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FunctionAttrs_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FunctionLoweringInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/FunctionLoweringInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/FunctionLoweringInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/FunctionLoweringInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Function_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Function_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Function_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/GCMetadataPrinter_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GCMetadata_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/GCMetadata_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/GCMetadata_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/GCMetadata_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GCOV_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GCStrategy_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GCStrategy_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/GCStrategy_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/GVMaterializer_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/GVMaterializer_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/GVMaterializer_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/GenericValue_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GetElementPtrTypeIterator_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GlobalAlias_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GlobalOpt_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/GlobalValue_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/GlobalValue_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/GlobalVariable_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/GlobalVariable_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/GlobalVariable_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/GlobalVariable_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/GlobalsModRef_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GraphTraits_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/GraphWriter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/GraphWriter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/GraphWriter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/GraphWriter_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/GraphWriter_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Graph_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Hello_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Hello_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HeuristicBase_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HeuristicBase_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HeuristicSolver_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HeuristicSolver_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonAsmPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonAsmPrinter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonAsmPrinter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonAsmPrinter_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonAsmPrinter_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonAsmPrinter_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonAsmPrinter_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonCallingConvLower_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/HexagonCallingConvLower_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonCallingConvLower_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/HexagonCallingConvLower_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonExpandPredSpillCode_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonExpandPredSpillCode_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonExpandPredSpillCode_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/HexagonFrameLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonFrameLowering_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonFrameLowering_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonFrameLowering_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonFrameLowering_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonFrameLowering_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/HexagonISelLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonISelLowering_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstPrinter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstPrinter_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstrInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstrInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstrInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstrInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstrInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonInstrInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMCAsmInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMCAsmInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMCInstLower_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMCInst_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMCTargetDesc_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMCTargetDesc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMachineFunctionInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMachineFunctionInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMachineScheduler_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMachineScheduler_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMachineScheduler_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMachineScheduler_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonMachineScheduler_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonNewValueJump_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonPeephole_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/HexagonRegisterInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/HexagonSelectionDAGInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/HexagonSelectionDAGInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/HexagonSelectionDAGInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/HexagonSplitTFRCondSets_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/HexagonSplitTFRCondSets_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/HexagonTargetObjectFile_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/HexagonTargetObjectFile_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Hexagon_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Hexagon_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Hexagon_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Hexagon_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Hexagon_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Host_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Host_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Host_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IPA_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/IPA_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IPO_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IPO_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IPO_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/IRBuilder_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IRBuilder_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IRBuilder_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IRBuilder_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ISDOpcodes_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IVUsers_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/IVUsers_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IVUsers_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IVUsers_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IVUsers_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IfConversion_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/IfConversion_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IfConversion_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ImmutableIntervalMap_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ImmutableIntervalMap_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ImmutableList_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ImmutableSet_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ImmutableSet_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InMemoryStruct_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IncludeFile_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IncludeFile_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/IndVarSimplify_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IndexedMap_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IndexedMap_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IndexedMap_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Initialization_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Initialization_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InlineAlways_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InlineAlways_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InlineAlways_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InlineAlways_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InlineAsm_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InlineAsm_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/InlineAsm_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InlineCost_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InlineCost_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InlineCost_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InlineFunction_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/InlineSimple_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InlineSimple_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InlineSpiller_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InlineSpiller_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InlineSpiller_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InlineSpiller_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InlinerPass_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineAddSub_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineAddSub_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineAndOrXor_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineAndOrXor_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineAndOrXor_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineCalls_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineCasts_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineCompares_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineMulDivRem_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombinePHI_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InstCombinePHI_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineSelect_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineShifts_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineShifts_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineShifts_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineSimplifyDemanded_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineSimplifyDemanded_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstCombineWorklist_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombine_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/InstCombine_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstCombine_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstCount_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstCount_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstCount_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InstVisitor_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstVisitor_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstVisitor_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InstVisitor_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstVisitor_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstVisitor_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/InstrEmitter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InstrEmitter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InstrEmitter_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/InstrTypes_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/InstructionCombining_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/InstructionCombining_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InstructionSimplify_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InstructionSimplify_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Instruction_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Instrumentation_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/IntEqClasses_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IntEqClasses_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IntEqClasses_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/IntEqClasses_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntegerDivision_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntegerDivision_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IntegerDivision_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IntegerDivision_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/IntegersSubsetMapping_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/IntegersSubsetMapping_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IntegersSubset_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntelJITEventListener_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IntelJITEventListener_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IntelJITEventListener_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/IntelJITEventsWrapper_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/IntelJITEventsWrapper_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InterferenceCache_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InterferenceCache_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/InterferenceCache_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/InterferenceCache_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/InterferenceCache_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/InterferenceCache_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Internalize_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Internalize_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Interpreter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Interpreter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Interpreter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IntervalIterator_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntervalMap_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntervalMap_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntervalPartition_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IntervalPartition_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Interval_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Interval_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Interval_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Interval_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Interval_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicInst_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicInst_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicLowering_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicLowering_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicLowering_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicLowering_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicLowering_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IntrinsicLowering_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Intrinsics_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/IntrusiveRefCntPtr_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/IntrusiveRefCntPtr_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IntrusiveRefCntPtr_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/IntrusiveRefCntPtr_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/IsNAN_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/JITCodeEmitter_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/JITDwarfEmitter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/JITDwarfEmitter_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/JITMemoryManager_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/JITMemoryManager_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/JITMemoryManager_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/JIT_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/JumpThreading_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LCSSA_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LEB128_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LEB128_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LEB128_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LEB128_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LEB128_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LLLexer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LLLexer_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LLLexer_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LLLexer_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LLLexer_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LLLexer_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LLParser_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LLParser_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LLParser_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LLParser_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LLParser_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LLParser_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LLParser_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LLToken_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LLVMBitCodes_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LLVMContextImpl_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LLVMContextImpl_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LLVMContextImpl_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LLVMContext_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LLVMContext_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LLVMTargetMachine_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LLVMTargetMachine_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LLVMTargetMachine_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LatencyPriorityQueue_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LatencyPriorityQueue_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LatencyPriorityQueue_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LazyValueInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LazyValueInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LazyValueInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LazyValueInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LeakDetector_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LeakDetector_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LeakDetector_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LeakDetector_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LeaksContext_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LeaksContext_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LeaksContext_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LeaksContext_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LegalizeDAG_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LegalizeDAG_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LegalizeTypes_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LegalizeTypes_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LegalizeTypes_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LexicalScopes_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LexicalScopes_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LexicalScopes_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LexicalScopes_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LibCallAliasAnalysis_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LibCallAliasAnalysis_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LibCallSemantics_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LinkAllAsmWriterComponents_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LinkAllAsmWriterComponents_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LinkAllCodegenComponents_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LinkAllPasses_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LinkAllVMCore_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LinkAllVMCore_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LinkArchives_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LinkItems_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LinkModules_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Linker_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Lint_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LiveDebugVariables_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LiveDebugVariables_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LiveDebugVariables_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LiveDebugVariables_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LiveIntervalAnalysis_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LiveIntervalAnalysis_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LiveIntervalAnalysis_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LiveIntervalUnion_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LiveIntervalUnion_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LiveInterval_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LiveInterval_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LiveInterval_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LiveRangeCalc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LiveRangeCalc_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LiveRangeCalc_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LiveRangeCalc_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LiveRangeEdit_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LiveRegMatrix_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LiveStackAnalysis_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LiveVariables_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LiveVariables_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LiveVariables_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Loads_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Local_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LocaleGeneric_8inc__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LocaleGeneric_8inc__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LocaleGeneric_8inc__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LocaleGeneric_8inc__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Locale_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LockFileManager_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LockFileManager_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LockFileManager_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LoopExtractor_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LoopExtractor_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LoopInfoImpl_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LoopInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LoopInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LoopInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LoopInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LoopIterator_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LoopPass_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/LoopPass_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LoopRotation_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LoopSimplify_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LoopUnrollPass_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LoopUnrollPass_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LoopUnrollRuntime_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/LoopVectorize_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LowerAtomic_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LowerExpectIntrinsic_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/LowerExpectIntrinsic_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LowerExpectIntrinsic_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/LowerInvoke_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/LowerInvoke_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/LowerInvoke_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/LowerSwitch_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeAsmLexer_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeAsmParser_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeAsmParser_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeAsmPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeAsmPrinter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeBaseInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeDisassembler_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeDisassembler_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeDisassembler_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeELFObjectWriter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeFrameLowering_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeFrameLowering_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeISelDAGToDAG_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeISelDAGToDAG_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeISelDAGToDAG_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeISelLowering_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeISelLowering_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeISelLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeISelLowering_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeInstPrinter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeInstPrinter_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeInstPrinter_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeInstrInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeInstrInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeInstrInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeIntrinsicInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeIntrinsicInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeIntrinsicInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCAsmInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCCodeEmitter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCInstLower_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCInstLower_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCInstLower_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCTargetDesc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCTargetDesc_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMCTargetDesc_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMachineFunction_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeMachineFunction_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeRegisterInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeRegisterInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeRegisterInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeRelocations_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeSelectionDAGInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeSelectionDAGInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeSubtarget_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeSubtarget_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeSubtarget_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeSubtarget_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MBlazeTargetMachine_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MBlaze_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmBackend_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmBackend_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmBackend_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmInfoCOFF_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmInfoCOFF_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmInfoCOFF_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmInfoDarwin_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmLayout_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmLayout_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmLexer_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmLexer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmLexer_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmLexer_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmParserExtension_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmParserExtension_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmParser_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmParser_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmParser_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmParser_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCAsmStreamer_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MCAssembler_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCAtom_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCAtom_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCAtom_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeEmitter_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCCodeGenInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCContext_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCDisassembler_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCDisassembler_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCDwarf_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCDwarf_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCDwarf_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCDwarf_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCDwarf_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCDwarf_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCDwarf_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCELFObjectTargetWriter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCELFObjectTargetWriter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCELFObjectTargetWriter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCELF_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCExpr_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCFixedLenDisassembler_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCFixedLenDisassembler_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCFixup_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCInstPrinter_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCInst_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCInst_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCInst_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCInst_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrAnalysis_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrAnalysis_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrAnalysis_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrDesc_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrDesc_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrDesc_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrItineraries_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrItineraries_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCInstrItineraries_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCJIT_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCLabel_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCLabel_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCLabel_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCMachOStreamer_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCMachOSymbolFlags_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCMachObjectTargetWriter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCMachObjectTargetWriter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCMachObjectTargetWriter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCMachObjectWriter_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCModule_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCModule_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCModule_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCModule_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectFileInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectFileInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectFileInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectFileInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectFileInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectFileInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectStreamer_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectWriter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectWriter_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCObjectWriter_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCParsedAsmOperand_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCSchedule_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCSchedule_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCSchedule_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCSectionCOFF_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCSectionELF_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCSectionELF_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCSectionMachO_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCSectionMachO_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCSectionMachO_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCSectionMachO_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCSection_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCSection_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCStreamer_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCStreamer_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCStreamer_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCStreamer_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCSubtargetInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCSubtargetInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCSubtargetInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCSubtargetInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCSubtargetInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCSubtargetInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCSubtargetInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCSymbol_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCSymbol_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCSymbol_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCSymbol_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCTargetAsmLexer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCTargetAsmLexer_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCTargetAsmParser_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCTargetAsmParser_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCTargetAsmParser_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MCTargetAsmParser_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MCTargetAsmParser_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCValue_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCValue_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MCValue_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MCWin64EH_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MCWin64EH_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MCWinCOFFObjectWriter_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MC_2MCDisassembler_2Disassembler_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MDBuilder_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MDBuilder_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MSP430AsmPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430FrameLowering_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430FrameLowering_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430FrameLowering_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430FrameLowering_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MSP430FrameLowering_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MSP430ISelLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430ISelLowering_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MSP430InstPrinter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430InstPrinter_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MSP430InstPrinter_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430InstPrinter_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430InstrInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430InstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCAsmInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCAsmInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCAsmInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCAsmInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCAsmInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCInstLower_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCInstLower_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCInstLower_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCInstLower_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MCTargetDesc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MachineFunctionInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430MachineFunctionInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MSP430RegisterInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430RegisterInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MSP430SelectionDAGInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430Subtarget_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MSP430Subtarget_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430Subtarget_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MSP430Subtarget_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430TargetInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MSP430TargetMachine_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MSP430_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachOFormat_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachOFormat_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachOFormat_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachOObjectFile_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachOObject_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachORelocation_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachORelocation_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachObjectWriter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineBasicBlock_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineBasicBlock_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineBlockFrequencyInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineBlockFrequencyInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineBlockPlacement_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineBranchProbabilityInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineCSE_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineCodeEmitter_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineCodeInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineConstantPool_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineConstantPool_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineConstantPool_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineCopyPropagation_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineCopyPropagation_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineCopyPropagation_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineDominators_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineDominators_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineFrameInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineFrameInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineFrameInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineFrameInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineFunctionAnalysis_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineFunctionAnalysis_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineFunctionAnalysis_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineFunctionPass_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineFunctionPass_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineFunctionPrinterPass_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineFunction_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineInstrBuilder_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineInstrBuilder_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineInstrBuilder_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineInstrBuilder_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineInstrBundle_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineInstr_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineInstr_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineJumpTableInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineJumpTableInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineLICM_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineLICM_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineLICM_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineLocation_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineLocation_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineLoopInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineLoopInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineLoopInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineLoopRanges_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineLoopRanges_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineLoopRanges_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineLoopRanges_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineMemOperand_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineMemOperand_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineMemOperand_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfoImpls_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfoImpls_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfoImpls_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfoImpls_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfoImpls_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfoImpls_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineModuleInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineOperand_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachinePassRegistry_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachinePassRegistry_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachinePassRegistry_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachinePassRegistry_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachinePostDominators_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachinePostDominators_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineRegisterInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineRegisterInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineSSAUpdater_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MachineSSAUpdater_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineScheduler_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineSink_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineTraceMetrics_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MachineTraceMetrics_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MachineTraceMetrics_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MachineTraceMetrics_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MachineVerifier_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Main_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Main_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStatic_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStatic_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStatic_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStringPool_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStringPool_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStringPool_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStringPool_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ManagedStringPool_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Mangler_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Mangler_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Mangler_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MapVector_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MapVector_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MapVector_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Math_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Math_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MaximumSpanningTree_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MaximumSpanningTree_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MemCpyOptimizer_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MemCpyOptimizer_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MemCpyOptimizer_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MemDepPrinter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MemDepPrinter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MemDepPrinter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuffer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuffer_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuffer_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuiltins_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuiltins_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuiltins_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuiltins_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MemoryBuiltins_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MemoryDependenceAnalysis_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MemoryObject_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MemoryObject_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MemoryObject_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MemoryObject_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Memory_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Memory_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Memory_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Memory_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Memory_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MergeFunctions_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MetaRenamer_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Metadata_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Metadata_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Mips16FrameLowering_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Mips16FrameLowering_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Mips16InstrInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Mips16InstrInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Mips16RegisterInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Mips16RegisterInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Mips16RegisterInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Mips16RegisterInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsAnalyzeImmediate_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsAnalyzeImmediate_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsAsmBackend_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsAsmBackend_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsAsmBackend_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsAsmParser_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsAsmParser_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsAsmPrinter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsAsmPrinter_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsBaseInfo_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsBaseInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsBaseInfo_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsCodeEmitter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsDirectObjLower_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsDirectObjLower_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsDirectObjLower_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsDirectObjLower_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsDisassembler_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsELFObjectWriter_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsELFObjectWriter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsFixupKinds_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsISelDAGToDAG_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsISelDAGToDAG_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsISelLowering_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsISelLowering_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsISelLowering_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsISelLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsISelLowering_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsInstPrinter_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsJITInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsJITInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsLongBranch_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCCodeEmitter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCInstLower_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCInstLower_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCInstLower_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCInstLower_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCInstLower_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCInstLower_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCTargetDesc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsMCTargetDesc_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsMachineFunction_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsMachineFunction_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsMachineFunction_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsRegisterInfo_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsRegisterInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsRegisterInfo_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsRegisterInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsRelocations_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsRelocations_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsRelocations_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsSEInstrInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsSEInstrInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsSEInstrInfo_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsSERegisterInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsSERegisterInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsSERegisterInfo_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsSERegisterInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsSelectionDAGInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsSubtarget_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsSubtarget_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetMachine_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetMachine_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetObjectFile_8cpp__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetObjectFile_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetObjectFile_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetObjectFile_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetObjectFile_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MipsTargetObjectFile_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Mips_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ModuleUtils_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ModuleUtils_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ModuleUtils_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MutexGuard_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/MutexGuard_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MutexGuard_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MutexGuard_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/MutexGuard_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/MutexGuard_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/MutexGuard_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Mutex_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Mutex_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXAllocaHoisting_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXAllocaHoisting_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXAllocaHoisting_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXAsmPrinter_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXAsmPrinter_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXAsmPrinter_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXBaseInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXISelDAGToDAG_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXISelLowering_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXInstrInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXInstrInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXInstrInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXLowerAggrCopies_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXLowerAggrCopies_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXLowerAggrCopies_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXMCAsmInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXMCTargetDesc_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXNumRegisters_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXNumRegisters_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXRegisterInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXRegisterInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXSection_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXSplitBBatBar_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXSplitBBatBar_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXSubtarget_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXSubtarget_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXSubtarget_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXSubtarget_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXTargetInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXTargetMachine_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXTargetObjectFile_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXUtilities_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXUtilities_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NVPTX_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/NVPTXutil_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/NoFolder_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/NullablePtr_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/OProfileJITEventListener_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/OProfileWrapper_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/OProfileWrapper_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/OProfileWrapper_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ObjectBuffer_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ObjectBuffer_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ObjectFile_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ObjectFile_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ObjectImageCommon_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ObjectImage_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Archive_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Archive_8cpp__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Archive_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Archive_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Archive_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Archive_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Archive_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2COFF_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2ELF_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Error_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Object_2Error_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Object_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/OcamlGC_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/OcamlGC_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/OperandTraits_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/OperandTraits_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/OperandTraits_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/OptimalEdgeProfiling_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/OptimizePHIs_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Optional_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Optional_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/OutputBuffer_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PHIEliminationUtils_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PHIEliminationUtils_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PHITransAddr_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PHITransAddr_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PHITransAddr_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCAsmBackend_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCAsmPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCBaseInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCBaseInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCCodeEmitter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCCodeEmitter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCELFObjectWriter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCFixupKinds_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCFixupKinds_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCFrameLowering_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCHazardRecognizers_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCISelDAGToDAG_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCISelLowering_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCISelLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCISelLowering_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCISelLowering_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCInstPrinter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCInstPrinter_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCInstrInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCInstrInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCInstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCJITInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCJITInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCJITInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCMCAsmInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCMCAsmInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCMCCodeEmitter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCMCCodeEmitter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCMCInstLower_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCMCTargetDesc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCMCTargetDesc_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCMachineFunctionInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCMachineFunctionInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCMachineFunctionInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCMachineFunctionInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCPerfectShuffle_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCPredicates_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCRegisterInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCRelocations_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCRelocations_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCRelocations_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCSelectionDAGInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCSelectionDAGInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCSelectionDAGInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCSubtarget_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCSubtarget_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPCTargetMachine_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PPCTargetMachine_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PPCTargetMachine_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PPC_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PackedVector_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/PackedVector_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Parser_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Parser_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PartialInlining_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PassManagerBuilder_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PassManager_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PassManager_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PassManagers_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PassSupport_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PassSupport_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Pass_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Pass_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Passes_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PathNumbering_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PathProfileInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PathProfileInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PathProfileInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PathProfileVerifier_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PathProfileVerifier_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PathProfiling_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PathV1_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PathV2_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Path_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Path_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PatternMatch_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PatternMatch_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PeepholeOptimizer_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PluginLoader_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PluginLoader_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PluginLoader_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/PluginLoader_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PointerIntPair_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PointerIntPair_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PointerUnion_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PostDominators_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PostDominators_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PostOrderIterator_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PostRASchedulerList_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PostRASchedulerList_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PowerPCTargetInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PredIteratorCache_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PrettyStackTrace_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PrettyStackTrace_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PrintModulePass_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PrintModulePass_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PriorityQueue_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PriorityQueue_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PriorityQueue_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ProcessImplicitDefs_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ProcessImplicitDefs_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Process_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ProfileDataLoader_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ProfileEstimatorPass_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ProfileInfoLoader_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ProfileInfoTypes_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ProfileInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ProfileVerifierPass_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ProfileVerifierPass_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ProfilingUtils_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Program_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Program_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/PrologEpilogInserter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/PrologEpilogInserter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PrologEpilogInserter_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PrologEpilogInserter_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/PromoteMemToReg_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/PromoteMemToReg_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PromoteMemToReg_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PruneEH_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/PseudoSourceValue_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RWMutex_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Record_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Record_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Recycler_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocBase_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocBase_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocBase_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocBase_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocBasic_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocFast_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocGreedy_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocPBQP_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocPBQP_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegAllocRegistry_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Regex_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Regex_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/RegionIterator_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegionIterator_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegionPass_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegionPass_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegionPass_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/RegionPrinter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegisterClassInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegisterClassInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegisterCoalescer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegisterPressure_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/RegisterScavenging_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/RegisterScavenging_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RegisterScavenging_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/RelocVisitor_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ResourcePriorityQueue_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ResourcePriorityQueue_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RuntimeDyldELF_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/RuntimeDyldELF_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/RuntimeDyldImpl_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/RuntimeDyldImpl_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/RuntimeDyldMachO_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/RuntimeDyld_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/RuntimeDyld_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SCCP_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SPUAsmPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUHazardRecognizers_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUHazardRecognizers_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUISelLowering_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUInstrBuilder_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SPUInstrBuilder_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SPUInstrInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SPUInstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SPUMCAsmInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUMCAsmInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUMCAsmInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SPUMCTargetDesc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUMCTargetDesc_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SPUMachineFunction_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SPUSelectionDAGInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUSelectionDAGInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SPUSubtarget_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUSubtarget_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SPUSubtarget_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SPUTargetMachine_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SPU_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SSAUpdaterImpl_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SSAUpdaterImpl_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SSAUpdaterImpl_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SSAUpdater_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SSAUpdater_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SaveAndRestore_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionAliasAnalysis_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionExpander_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionExpander_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionExpressions_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionExpressions_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionExpressions_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionNormalization_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionNormalization_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolutionNormalization_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolution_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ScalarEvolution_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ScalarReplAggregates_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Scalar_2SimplifyLibCalls_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGILP_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGILP_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGInstrs_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGPrinter_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGPrinter_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGRRList_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGRRList_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGSDNodes_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ScheduleDAGSDNodes_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SchedulerRegistry_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SchedulerRegistry_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SchedulerRegistry_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScopedHashTable_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ScopedHashTable_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ScoreboardHazardRecognizer_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SearchForAddressOfSpecialSymbol_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGBuilder_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGBuilder_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGDumper_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGDumper_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGISel_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGISel_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGISel_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGISel_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAGNodes_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SelectionDAG_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SetOperations_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SetOperations_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SetVector_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ShadowStackGC_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Signals_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SimplifyCFGPass_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SimplifyCFGPass_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SimplifyCFG_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SimplifyIndVar_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SimplifyIndVar_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SimplifyIndVar_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SimplifyLibCalls_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SlotIndexes_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SlotIndexes_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SmallBitVector_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SmallPtrSet_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SmallSet_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SmallSet_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SmallString_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SmallVector_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Solution_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SourceMgr_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcAsmPrinter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcFrameLowering_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcFrameLowering_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcInstrInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcInstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcMCAsmInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcMCAsmInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcMCAsmInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcMCTargetDesc_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcMachineFunctionInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcRegisterInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcRegisterInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcRegisterInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcSelectionDAGInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparcSubtarget_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcSubtarget_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SparcTargetInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SparcTargetMachine_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Sparc_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Sparc_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SparseBitVector_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SparseBitVector_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SparsePropagation_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SparseSet_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SparseSet_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SpillPlacement_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/SpillPlacement_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SpillPlacement_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SplitKit_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SplitKit_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SplitKit_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/StackColoring_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StackSlotColoring_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/StackSlotColoring_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Statistic_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Statistic_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Statistic_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StreamableMemoryObject_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/StreamableMemoryObject_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/StreamableMemoryObject_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StringMap_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StringMap_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/StringMap_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StringMap_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/StringMatcher_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/StringPool_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/StringRef_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/StringRef_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/StringSet_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/StringSet_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StringSet_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/StringSwitch_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StripDeadPrototypes_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/StripSymbols_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/StrongPHIElimination_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SubtargetFeature_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SubtargetFeature_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Support_2COFF_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Support_2COFF_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Support_2COFF_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Support_2Disassembler_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Support_2MachO_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SwapByteOrder_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/SymbolTableListTraitsImpl_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/SymbolTableListTraitsImpl_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/SymbolTableListTraits_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/SystemUtils_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TGLexer_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TGParser_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TGParser_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TGParser_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TableGenBackend_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TableGenBackend_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TableGen_2Error_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TailDuplication_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TailRecursionElimination_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetCallingConv_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetCallingConv_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetFolder_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TargetFrameLoweringImpl_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetFrameLowering_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetInstrInfoImpl_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TargetIntrinsicInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetIntrinsicInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetIntrinsicInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetJITInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetJITInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetLibraryInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetLoweringObjectFileImpl_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetLoweringObjectFile_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetLoweringObjectFile_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TargetLowering_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TargetLowering_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TargetMachineC_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetMachine_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetRegisterInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetRegistry_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TargetSelect_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TargetSelect_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetSelectionDAGInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetSelectionDAGInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetSelectionDAGInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetSubtargetInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/TargetTransformImpl_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TargetTransformInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Target_2TargetMachine_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Target_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ThreadLocal_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/ThreadLocal_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ThreadSanitizer_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ThreadSanitizer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Threading_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Threading_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Thumb1InstrInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Thumb1InstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Thumb1InstrInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Thumb1RegisterInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Thumb2InstrInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Thumb2InstrInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Thumb2RegisterInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Thumb2RegisterInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Thumb2RegisterInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Thumb2SizeReduction_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TimeValue_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TimeValue_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Timer_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ToolOutputFile_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ToolOutputFile_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Trace_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Trace_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Transforms_2IPO_2PassManagerBuilder_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Transforms_2IPO_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Transforms_2IPO_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/Transforms_2IPO_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Transforms_2Vectorize_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Transforms_2Vectorize_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Triple_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Twine_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Twine_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/TwoAddressInstructionPass_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TypeBasedAliasAnalysis_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/TypeBuilder_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/TypeBuilder_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TypeFinder_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/TypeFinder_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/TypeFinder_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Type_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Type_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/UnifyFunctionExitNodes_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/UnifyFunctionExitNodes_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/UniqueVector_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/UniqueVector_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2Memory_8inc_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2Mutex_8inc_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2Process_8inc_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2Program_8inc.html
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2Program_8inc__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2Program_8inc__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2TimeValue_8inc.html
    www-releases/trunk/3.2/docs/doxygen/html/Unix_2system__error_8inc__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Unix_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Use_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/Use_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Utils_2SimplifyLibCalls_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/Utils_2SimplifyLibCalls_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Valgrind_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/ValueHandle_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ValueSymbolTable_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/ValueSymbolTable_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/ValueTypes_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ValueTypes_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ValueTypes_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ValueTypes_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Value_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/Value_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Windows_2Host_8inc.html
    www-releases/trunk/3.2/docs/doxygen/html/Windows_2PathV2_8inc.html
    www-releases/trunk/3.2/docs/doxygen/html/Windows_2Program_8inc_source.html
    www-releases/trunk/3.2/docs/doxygen/html/Windows_2Signals_8inc.html
    www-releases/trunk/3.2/docs/doxygen/html/Windows_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/Writer_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/X86ATTInstPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86ATTInstPrinter_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86AsmParser_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86AsmPrinter_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86AsmPrinter_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/X86AsmPrinter_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86COFFMachineModuleInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86DisassemblerDecoderCommon_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86DisassemblerDecoderCommon_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86DisassemblerDecoderCommon_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/X86DisassemblerDecoder_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/X86Disassembler_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86Disassembler_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/X86Disassembler_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/X86Disassembler_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86Disassembler_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86FastISel_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86FixupKinds_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86FrameLowering_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86FrameLowering_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86ISelDAGToDAG_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86InstrBuilder_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/X86InstrBuilder_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86InstrInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86IntelInstPrinter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86IntelInstPrinter_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86JITInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86JITInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/X86JITInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86MCAsmInfo_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86MCAsmInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86MCAsmInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86MCInstLower_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86MCTargetDesc_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86MCTargetDesc_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86MachObjectWriter_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86MachineFunctionInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86RegisterInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86RegisterInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86RegisterInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86Relocations_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/X86Relocations_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/X86SelectionDAGInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/X86SelectionDAGInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86ShuffleDecode_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86Subtarget_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86Subtarget_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/X86Subtarget_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/X86TargetMachine_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86TargetMachine_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/X86TargetObjectFile_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/X86TargetObjectFile_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/X86TargetObjectFile_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreISelDAGToDAG_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreISelDAGToDAG_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/XCoreISelLowering_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/XCoreISelLowering_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreISelLowering_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/XCoreISelLowering_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/XCoreInstrInfo_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMCAsmInfo_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMCAsmInfo_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMCAsmInfo_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMCAsmInfo_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMCTargetDesc_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMCTargetDesc_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMachineFunctionInfo_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/XCoreMachineFunctionInfo_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/XCoreSelectionDAGInfo_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/XCoreSubtarget_8cpp_source.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreTargetInfo_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/XCoreTargetMachine_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/XCoreTargetObjectFile_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/XCoreTargetObjectFile_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/XCoreTargetObjectFile_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/XCore_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/YAMLParser_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/YAMLParser_8cpp__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/YAMLParser_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/c_2Analysis_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/c_2ExecutionEngine_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/c_2Linker_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/c_2Linker_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/c_2Linker_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/c_2Linker_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/c_2TargetMachine_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/c_2Transforms_2IPO_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/c_2Transforms_2IPO_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/c_2Transforms_2IPO_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/c_2Transforms_2PassManagerBuilder_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/c_2Transforms_2PassManagerBuilder_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/c_2Transforms_2Vectorize_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/cl__common__defines_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/cl__common__defines_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/cl__common__defines_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/classARMGenSubtargetInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classAllocaPartitioning_1_1BuilderBase__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classAllocaPartitioning_1_1BuilderBase__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classAllocaPartitioning_1_1UseBuilder-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classAllocaPartitioning_1_1UseBuilder__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classElf__Rel__Base__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classElf__Shdr__Base.html
    www-releases/trunk/3.2/docs/doxygen/html/classHexagonGenRegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classHexagonGenSubtargetInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classInstVisitor__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classLiveIntervals_1_1HMEditor.html
    www-releases/trunk/3.2/docs/doxygen/html/classMBlazeGenInstrInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classMBlazeGenRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classMBlazeGenSubtargetInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classMSP430GenRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classMipsGenInstrInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classMipsGenInstrInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classMipsGenRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classMipsGenRegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classMipsGenSubtargetInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classNVPTXGenRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1EdgeItrCompartor-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1Graph-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1Graph.html
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1HeuristicBase__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1HeuristicSolver-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1Heuristics_1_1Briggs__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1Heuristics_1_1Briggs__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1NodeItrComparator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classPBQP_1_1Vector.html
    www-releases/trunk/3.2/docs/doxygen/html/classPPCGenInstrInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classPredicate__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classSPUGenRegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classScopedHandle.html
    www-releases/trunk/3.2/docs/doxygen/html/classSparcGenSubtargetInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classX86GenRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classXCoreGenSubtargetInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classXCoreGenSubtargetInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classchar.html
    www-releases/trunk/3.2/docs/doxygen/html/classfalse_1_1PHIOrSelectSpeculator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classfalse_1_1PHIOrSelectSpeculator.html
    www-releases/trunk/3.2/docs/doxygen/html/classfalse_1_1PHIOrSelectSpeculator__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1APInt__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMAsmPrinter__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMBaseInstrInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMBaseTargetMachine-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMBaseTargetMachine__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMBaseTargetMachine__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMConstantPoolConstant__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMConstantPoolConstant__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMConstantPoolMBB-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMConstantPoolSymbol__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMConstantPoolValue__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMELFMCAsmInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMELFMCAsmInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMELFMCAsmInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMElfTargetObjectFile.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMElfTargetObjectFile__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMElfTargetObjectFile__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMFrameLowering-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMFrameLowering__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMFunctionInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMFunctionInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMHazardRecognizer.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMHazardRecognizer__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMInstrInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMInstrInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMSelectionDAGInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMSelectionDAGInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMSubtarget__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMSubtarget__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMTargetLowering__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ARMTargetMachine__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AShrOperator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AddOperator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AddressingModeMatcher-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AggressiveAntiDepBreaker__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AggressiveAntiDepState.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AliasAnalysis__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AliasSet-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AliasSetTracker.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AliasSet__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AllocaInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AllocationOrder.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AnalysisResolver.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AntiDepBreaker__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ArchiveMember.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ArchiveMember__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ArrayRef__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ArrayType__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AsmCond-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AsmCond.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AsmPrinter__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AssertingVH.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AssertingVH__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AtomicCmpXchgInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AtomicCmpXchgInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AtomicRMWInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AtomicSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AtomicSDNode__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1AttributesImpl__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BallLarusDag-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BallLarusEdge__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BasicBlockSDNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BasicBlock__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BinOpInit-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BinOpInit.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BinOpInit__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BinaryOperator__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BinaryOperator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BinarySDNode__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitCastInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitCastInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitInit.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitInit__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitVector.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitcodeReaderValueList-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitcodeReader__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitcodeReader__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitsInit__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BitsRecTy__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BlockAddress-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BlockAddressSDNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BlockAddress__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BlockFrequency-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BlockFrequency.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BlockFrequencyImpl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BlockFrequencyInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BranchInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1BranchInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CallGraph.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CallGraphNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CallGraphSCCPass__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CallSiteBase__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CallbackVH__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CastInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CmpInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CoalescerPair.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CodeExtractor-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CompareConstantExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CompositeType.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CompositeType__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CompositeType__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConcreteOperator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CondCodeSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstMIOperands__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstMIOperands__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantAggregateZero__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantAggregateZero__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantArray-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantArray__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantDataArray__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantDataSequential.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantDataVector.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantDataVector__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantFP.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantFPSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantFPSDNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantFPSDNode__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantInt__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantPointerNull__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantPoolSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantPoolSDNode__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantSDNode__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantStruct.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantStruct__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConstantVector__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Constant__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Constant__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ContextualFoldingSet-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ContextualFoldingSet__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConvergingVLIWScheduler-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ConvergingVLIWScheduler.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContext-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContextCleanup.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContextCleanupBase.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContextCleanupBase__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContextCleanupRegistrar-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContextCleanupRegistrar.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContextCleanup__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CrashRecoveryContextDestructorCleanup__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1CriticalAntiDepBreaker.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIArray-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIArray__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIBasicType__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIBasicType__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIBuilder.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DICompileUnit__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DICompositeType-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DICompositeType__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DICompositeType__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIContext-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIContext__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIDerivedType-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIDerivedType__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIDerivedType__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIDescriptor-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIE.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEAbbrevData-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEBlock__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEBlock__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEDelta__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEEntry__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEEntry__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEInteger.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEInteger__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIELabel-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEValue.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEValue__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEValue__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIE__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEnumerator__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIEnumerator__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DILexicalBlock-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DILexicalBlockFile-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DILexicalBlockFile__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DINameSpace-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIObjCProperty__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DISubprogram__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DISubprogram__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DITemplateTypeParameter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DITemplateValueParameter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIType__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DIVariable__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DWARFCompileUnit.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DWARFContextInMemory__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DWARFDebugAranges-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DWARFDebugLine-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DagInit__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DagRecTy-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DataLayout__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DataLayout__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DbgDeclareInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DbgValueInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DebugInfoFinder-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DefInit__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DefaultVLIWScheduler__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DefaultVLIWScheduler__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DenseMapBase-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DenseMapIterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DenseMap__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DenseSet_1_1Iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DenseSet_1_1Iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DenseSet__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DependenceAnalysis-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DependenceAnalysis__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Dependence__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DomTreeNodeBase-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DominanceFrontier.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DominanceFrontierBase.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DominanceFrontierBase__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DominatorTreeBase__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DominatorTree__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DominatorTree__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DwarfAccelTable.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DwarfCFIException__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1DwarfException.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1EHLabelSDNode__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1EquivalenceClasses-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1EquivalenceClasses_1_1member__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ExtractElementInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ExtractElementInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ExtractValueConstantExpr__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ExtractValueConstantExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ExtractValueInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ExtractValueInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FCmpInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FPToSIInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FPToUIInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FPToUIInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FPTruncInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FastFoldingSetNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FastFoldingSetNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FenceInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FenceInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FieldInit-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FileInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FileRemover-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FileRemover.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FilteredPassNameParser.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FilteredPassNameParser__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FixedStackPseudoSourceValue__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FixedStackPseudoSourceValue__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetBucketIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetBucketIteratorImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetBucketIteratorImpl__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetBucketIteratorImpl__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetNodeWrapper.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetNodeWrapper__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetVector-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FoldingSetVectorIterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FrameIndexSDNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FunctionPass-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FunctionPassManagerImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1FunctionType__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Function__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GCModuleInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GCModuleInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GCModuleInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GCOVFile.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GCOVFunction-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GCOVLines.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GetElementPtrConstantExpr.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GetElementPtrConstantExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GetElementPtrInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GlobalAddressSDNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GlobalAlias.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GlobalAlias__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GlobalValue__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GlobalValue__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1GlobalVariable__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HandleSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HandleSDNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HandleSDNode__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HandleSDNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonAsmPrinter.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonInstPrinter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonInstPrinter__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonInstrInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonInstrInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonMCAsmInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonMCInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonMCInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonMachineFunctionInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonTargetMachine-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1HexagonTargetMachine__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ICmpInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IRBuilder-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IRBuilder.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IRBuilderBase__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IVStrideUse.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IVStrideUse__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IVStrideUse__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IVUsers.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IVUsers__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableCallSite__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableListImpl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableListImpl__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableMapRef-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableMapRef_1_1iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableMap__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableMap__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutablePass__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableSetRef-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImmutableSetRef_1_1iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ImutAVLFactory-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InMemoryStruct-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IndexListEntry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IndirectBrInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Init__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InlineAsm.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InlineAsm__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InlineFunctionInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertElementConstantExpr.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertElementConstantExpr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertElementConstantExpr__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertElementInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertElementInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertElementInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertValueConstantExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InsertValueInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InstCombineIRInserter-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InstCombineIRInserter__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InstCombineWorklist.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InstCombiner.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Instruction-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Instruction__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntEqClasses-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntEqClasses.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntInit-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntItem.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntRange__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntRecTy__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntRecTy__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntToPtrInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntegerType.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntegersSubset-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntegersSubsetGeneric__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntegersSubset__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntelJITEventsWrapper-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InterferenceCache-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1InterferenceCache.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalMapImpl_1_1NodeBase-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalMapImpl_1_1NodeBase.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalMapImpl_1_1NodeBase__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalMapImpl_1_1NodeBase__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalMap_1_1const__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalMap_1_1const__iterator__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1IntervalMap_1_1const__iterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Interval__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1JITCodeEmitter-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1JITCodeEmitter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1JITMemoryManager__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1JIT__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LLParser.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LLVMContextImpl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LLVMTargetMachine-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LPPassManager__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LSBaseSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LShrOperator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LShrOperator__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LatencyPriorityQueue__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LatencyPriorityQueue__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LazyValueInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LexicalScope-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LibCallInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LibCallInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LibCallSimplifierImpl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveDebugVariables__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveIntervalUnion_1_1Array-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveIntervalUnion_1_1Query.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveRegMatrix.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveRegMatrix__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveStacks.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveStacks__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LiveVariables__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LoadSDNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LoopBlocksDFS-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LoopInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1LoopPass__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeDisassembler__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeFrameLowering__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeInstPrinter__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeInstrInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeIntrinsicInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeMCAsmInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeMCInstLower-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeMCInstLower.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeSelectionDAGInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeSubtarget__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeTargetMachine-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeTargetMachine__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MBlazeTargetObjectFile__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmBackend.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmBackend__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmInfoCOFF.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmInfoCOFF__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmInfoDarwin__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmInfoGNUCOFF__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmInfoMicrosoft__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmLexer__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmLexer__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmParser-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmParserExtension-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmParserExtension__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAsmParserSemaCallback-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAssembler.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCAtom-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCBinaryExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCBinaryExpr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCCFIInstruction.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCContext.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCDataFragment__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCDisassembler-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCDisassembler__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCDwarfCallFrameFragment__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCDwarfLineAddrFragment__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCGenDwarfInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstFragment.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstFragment__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstPrinter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstPrinter__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstrDesc.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstrDesc__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstrInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCInstrInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCJIT-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCJIT__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCLineEntry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCLineEntry__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCLineEntry__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCLineSection-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCObjectStreamer.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCObjectStreamer__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCObjectWriter.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCObjectWriter__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCRegAliasIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCRegAliasIterator__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCRegisterClass__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSchedModel.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSectionCOFF-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSectionCOFF.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSectionCOFF__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSectionCOFF__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSectionELF-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSectionELF__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSectionMachO__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSection__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSection__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCStreamer__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSubRegIterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSubRegIterator__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSubRegIterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSubtargetInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSuperRegIterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCSymbolRefExpr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCTargetAsmParser-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCTargetAsmParser.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCTargetAsmParser__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCTargetExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCTargetExpr.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCUnaryExpr__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCValue.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCWin64EHInstruction.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MCWinCOFFObjectTargetWriter.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MDBuilder-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MDNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MDNodeSDNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MDNode__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MDNode__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MDString__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MDString__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MIBundleOperands__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MIBundleOperands__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MIOperands__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MMIAddrLabelMapCallbackPtr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MMIAddrLabelMapCallbackPtr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MPPassManager__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430FrameLowering__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430InstrInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430MCAsmInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430MachineFunctionInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430MachineFunctionInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430MachineFunctionInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430SelectionDAGInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430SelectionDAGInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430Subtarget__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430TargetLowering.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MSP430TargetLowering__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachORelocation.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachObjectWriter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineBasicBlock.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineBasicBlock_1_1bundle__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineBranchProbabilityInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineBranchProbabilityInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineCodeEmitter.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineCodeEmitter__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineCodeEmitter__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineCodeInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineConstantPoolEntry__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineConstantPoolValue__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineDominatorTree-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineDominatorTree__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineFrameInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineFunction.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineFunctionPass__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineInstrBuilder-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineLoopInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineLoopInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineLoopRanges__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineLoop__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineLoop__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineMemOperand-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineModuleInfoELF__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineModuleInfoImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineModuleInfoImpl__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineModuleInfoMachO.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineModuleInfoMachO__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineModuleInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineMove.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineOperand-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineOperandIteratorBase__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachinePassRegistryListener-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineRelocation__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineSSAUpdater-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineSchedRegistry__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineTraceMetrics.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MachineTraceMetrics__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MallocAllocator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MallocAllocator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ManagedStatic-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ManagedStringPool-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MapVector-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MaximumSpanningTree-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MaximumSpanningTree.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MaximumSpanningTree__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemIntrinsic-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemIntrinsicSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemIntrinsic__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemIntrinsic__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemMoveInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemSetInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemSetInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemSetInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemSlab__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemTransferInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemoryDependenceAnalysis__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemoryObject.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MemoryObject__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Mips16FrameLowering-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Mips16FrameLowering__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Mips16FrameLowering__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Mips16InstrInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Mips16InstrInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Mips16RegisterInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsAnalyzeImmediate.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsFrameLowering.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsFunctionInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsFunctionInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsFunctionInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsInstPrinter-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsInstPrinter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsInstPrinter__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsJITInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsMCAsmInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsRegisterInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsSEFrameLowering.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsSERegisterInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsSERegisterInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsSelectionDAGInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsSelectionDAGInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsSubtarget-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsSubtarget__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsTargetMachine.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsTargetMachine__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipsebTargetMachine__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipselTargetMachine__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MipselTargetMachine__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Module.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ModulePass__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MutableArrayRef-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MutableArrayRef.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MutableArrayRef__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MutableArrayRef__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1MutexGuard-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXAllocaHoisting__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXAsmPrinter-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXAsmPrinter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXInstrInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXInstrInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXInstrInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXMCAsmInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXMCAsmInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXPassConfig-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXPassConfig__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXPassConfig__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXRegisterInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXRegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXSection-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXSection__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXSubtarget.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXTargetMachine32__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXTargetMachine64-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1NVPTXTargetMachine64__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1OProfileWrapper.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjRelocationInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjectBufferStream-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjectBufferStream.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjectImageCommon.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjectImage__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjectSizeOffsetEvaluator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjectSizeOffsetVisitor__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ObjectSizeOffsetVisitor__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1OpInit-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1OpInit__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Operator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1OwningArrayPtr.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PBQPBuilderWithCoalescing.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PBQPBuilder__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PBQPRAProblem-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PEI__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PHINode__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPC32TargetMachine.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPC32TargetMachine__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCFrameLowering__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCFrameLowering__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCFunctionInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCFunctionInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCHazardRecognizer970-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCLinuxMCAsmInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCLinuxMCAsmInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCMCAsmInfoDarwin__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCRegisterInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCRegisterInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCScoreboardHazardRecognizer__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCSubtarget__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCTargetLowering__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PPCTargetMachine-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PackedVector_1_1reference.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassArgFilter.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassConfigImpl__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassManager-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassManagerBase.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassManagerBuilder.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassManagerImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassManagerPrettyStackEntry__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassManagerPrettyStackEntry__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PassRegistry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Pass__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerIntPair.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerIntPair__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01Instruction_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01PointerIntPair_3_01PointerTy_00_01IntBits_00_01IntType_00_01PtrTraits_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01PointerIntPair_3_01PointerTy_00_01IntBits_00_01IntType_00_01PtrTraits_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01PointerUnion3_3_01PT1_00_01PT2_00_01PT3_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01PointerUnion4_3_01PT1_00_01PT2_00_01PT3_00_01PT4_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01PointerUnion_3_01PT1_00_01PT2_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01Value_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01const_01T_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerLikeTypeTraits_3_01const_01T_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerType-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerType.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerUnion-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerUnion4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PointerUnion__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PredIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PredIterator__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PrettyStackTraceEntry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PrettyStackTraceProgram__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PrettyStackTraceString.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PrintRegUnit.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PriorityQueue-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PriorityQueue.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ProfileInfoLoader.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ProfilePathEdge__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1PseudoSourceValue-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RGPassManager.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RGPassManager__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RNSuccIterator_3_01FlatIt_3_01NodeType_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RNSuccIterator_3_01FlatIt_3_01NodeType_01_4_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RNSuccIterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RTDyldMemoryManager-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RTDyldMemoryManager.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RTDyldMemoryManager__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ReadyQueue-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RecTy-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RecordVal.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Recycler.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegAllocBase__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegionInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegionInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Region_1_1block__iterator__wrapper-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Region_1_1block__iterator__wrapper__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Region__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterAGBase-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterAGBase__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterMaskSDNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterMaskSDNode__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterPassParser__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterRegAlloc-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterRegAlloc.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RegisterScheduler-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Registry_1_1iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Registry_1_1listener__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Registry_1_1node-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Registry_1_1node.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ResourcePriorityQueue-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ResourcePriorityQueue__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ReturnInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1RuntimeDyldELF__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEV.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVAddExpr.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVCastExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVCastExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVCommutativeExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVCommutativeExpr__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVConstant-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVConstant__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVNAryExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVSMaxExpr__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVSignExtendExpr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVSignExtendExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVTruncateExpr__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVUDivExpr.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVUDivExpr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVUDivExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVUMaxExpr__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVUnknown.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVZeroExtendExpr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVZeroExtendExpr.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEVZeroExtendExpr__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SCEV__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SDDbgInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SDDbgValue.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SDNodeIterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SDNode_1_1use__iterator__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SDUse.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SExtInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SIToFPInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SIToFPInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPUFrameLowering__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPUFunctionInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPULinuxMCAsmInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPURegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPUSubtarget-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPUTargetLowering.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPUTargetLowering__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SPUTargetMachine__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SSAUpdaterTraits_3_01MachineSSAUpdater_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SUnit-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SUnitIterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ScalarTargetTransformInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ScheduleDAGInstrs__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ScheduleDAGMutation.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ScheduleDAGSDNodes__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ScheduleHazardRecognizer__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ScopedHashTableIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SectionEntry__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SectionKind.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SelectConstantExpr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SelectInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SelectionDAGBuilder-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SelectionDAGBuilder__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SetVector__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ShlOperator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ShlOperator__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ShlOperator__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ShuffleVectorInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ShuffleVectorInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ShuffleVectorSDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ShuffleVectorSDNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SimplifyFortifiedLibCalls-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SlotIndex-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallBitVector-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallDenseMap__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallPtrSet.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallPtrSetImpl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallPtrSetImpl__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallPtrSetImpl__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallSetVector__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallSet_3_01PointeeType_01_5_00_01N_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallString.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallString__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallVectorBase.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallVectorImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallVectorImpl__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallVectorTemplateBase_3_01T_00_01true_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallVectorTemplateBase_3_01T_00_01true_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallVectorTemplateBase_3_01T_00_01true_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SmallVectorTemplateCommon__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcELFMCAsmInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcELFMCAsmInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcSelectionDAGInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcTargetLowering__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcTargetMachine.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcTargetMachine__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcV8TargetMachine__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcV8TargetMachine__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcV9TargetMachine-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparcV9TargetMachine__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparseBitVector-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparseSet__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparseSolver-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SparseSolver.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SrcValueSDNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StandardPass_1_1RegisterStandardPass.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StoreInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StoreInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StoreInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StoreSDNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StreamableMemoryObject-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StreamableMemoryObject__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StreamingMemoryObject.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringMapConstIterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringMapConstIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringMapImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringMapImpl__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringMapIterator__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringRecTy__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringRef-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StringSet__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StructLayout-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StructType.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1StructType__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SubtargetFeatures.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SuccIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SwitchInst_1_1CaseIt__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SwitchInst_1_1CaseIt__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SwitchInst_1_1CaseIteratorT__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SwitchInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1SymbolTableListTraits__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TGParser.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetIntrinsicInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetLibraryInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetLowering.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetLoweringObjectFileELF-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetLoweringObjectFileMachO__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetLowering_1_1ValueTypeActionImpl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetLowering__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetMachine__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetOptions.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetOptions__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetPassConfig__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetPassConfig__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetRegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetRegistry_1_1iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetRegistry_1_1iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetSchedModel-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetSubtargetInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetTransformInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetTransformInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TargetTransformInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TerminatorInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TernOpInit__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TernarySDNode__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Thumb2InstrInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Thumb2InstrInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TimeRecord-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TimerGroup-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Trace.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TrackingVH.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Traits.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Twine.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01PathProfilingFunctionTable_00_01xcompile_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01R_07A1_00_01A2_00_01A3_00_01A4_00_01A5_08_00_01cross_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01R_07A1_00_01A2_00_01A3_08_00_01cross_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01R_07A1_00_01A2_00_8_8_8_08_00_01cross_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01T[N]_00_01cross_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01T_01_5_00_01cross_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01const_01void_01_5_00_01false_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01double_00_01false_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01double_00_01false_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01float_00_01false_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01float_00_01true_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01types_1_1ppc__fp128_00_01cross_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01void_00_01cross_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01void_01_5_00_01false_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder_3_01void_01_5_00_01false_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeBuilder__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1TypeFinder-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UDivOperator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UDivOperator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UIToFPInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnOpInit__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnOpInit__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnaryInstruction__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnaryInstruction__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnarySDNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnarySDNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UniqueVector.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnreachableInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1UnsetInit__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Use-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1User_1_1value__op__iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1User_1_1value__op__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VACopyInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VAEndInst__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VAStartInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VAStartInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VAStartInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VLIWMachineScheduler__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VLIWPacketizerList.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VLIWPacketizerList__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VNInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VTSDNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VTSDNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VTSDNode__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueEnumerator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueHandleBase-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueHandleBase__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueMapCallbackVH__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueMapCallbackVH__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueMapIterator__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueMap__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ValueSymbolTable.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VarInit.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VectorTargetTransformImpl__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VectorTargetTransformInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VectorTargetTransformInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VectorType__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VectorType__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VirtRegMap__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1VirtRegMap__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1WeakVH__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1Win64Exception__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86AsmPrinter__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86AsmPrinter__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86COFFMachineModuleInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86Disassembler_1_1X86GenericDisassembler__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86ELFMCAsmInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86ELFMCAsmInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86FrameLowering.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86IntelInstPrinter__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86JITInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86LinuxTargetObjectFile.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86LinuxTargetObjectFile__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86MCAsmInfoDarwin.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86MCAsmInfoMicrosoft-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86MCAsmInfoMicrosoft__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86MachineFunctionInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86MachineFunctionInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86RegisterInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86RegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86SelectionDAGInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86Subtarget__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86Subtarget__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86TargetMachine__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86VectorTargetTransformInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86__32TargetMachine__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86__64MachoTargetObjectFile__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1X86__64TargetMachine__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1XCoreTargetLowering.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1XCoreTargetLowering__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1XCoreTargetMachine.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ZExtInst.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ZExtInst__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ZExtInst__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1__generic__error__category__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1__system__error__category.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1__system__error__category__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1Option__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1basic__parser-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1basic__parser.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1basic__parser__impl__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1bits__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1bits__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1bits__storage-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1bits__storage_3_01DataType_00_01bool_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1generic__parser__base-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1generic__parser__base_1_1GenericOptionInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1generic__parser__base__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1list__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1list__storage__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1opt-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1opt__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1opt__storage.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1opt__storage_3_01DataType_00_01false_00_01true_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_1_1OptionInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_1_1OptionInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_1_1OptionInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01boolOrDefault_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01boolOrDefault_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01bool_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01bool_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01char_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01double_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01float_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01int_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01std_1_1string_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01std_1_1string_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01unsigned_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser_3_01unsigned_01long_01long_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1cl_1_1parser__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1constant__iterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1df__iterator__storage.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1df__iterator__storage_3_01SetType_00_01true_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1df__iterator__storage__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1format__object3.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1format__object5-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1format__object5__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1format__object__base__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ilist__half__node__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1ilist__iterator__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1iplist.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1iplist__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1mapped__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1Archive-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1Archive_1_1Symbol-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1Archive_1_1child__iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1Archive_1_1child__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1Binary-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1COFFObjectFile-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1COFFObjectFile__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1COFFObjectFile__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1DynRefImpl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1ELFObjectFile_1_1ELFRelocationIterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1ELFObjectFile__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1MachOObject-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1MachOObjectFile-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1MachOObjectFile__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1ObjectFile.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1RelocVisitor-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1RelocationRef-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1SectionRef.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1content__iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1object_1_1content__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1po__iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1po__iterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1po__iterator__storage_3_01LoopBounds_00_01true_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1po__iterator__storage__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1raw__fd__ostream__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1raw__null__ostream__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1raw__null__ostream__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1raw__ostream.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1raw__string__ostream__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1support_1_1detail_1_1packed__endian__specific__integral_3_01value__type_00_01big_00_01aligned_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1support_1_1detail_1_1packed__endian__specific__integral_3_01value__type_00_01big_00_01unaligned_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1support_1_1detail_1_1packed__endian__specific__integral_3_01value__type_00_01little_00_01unaligned_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1PathWithStatus__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1PathWithStatus__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1RWMutexImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1SmartMutex.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1SmartMutex__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1SmartMutex__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1SmartScopedLock-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1TimeValue-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1fs_1_1file__status-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1sys_1_1fs_1_1recursive__directory__iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1types_1_1ppc__fp128.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1value__use__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1value__use__iterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1AliasNode-members.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1AliasNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1KeyValueNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1MappingNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1Node__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1NullNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1ScalarNode.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1ScalarNode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1ScalarNode__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1Scanner.html
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1basic__collection__iterator__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classllvm_1_1yaml_1_1basic__collection__iterator__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/classstd_1_1binary__function__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classstd_1_1iterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classstd_1_1priority__queue__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/classstd_1_1vector.html
    www-releases/trunk/3.2/docs/doxygen/html/config_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/config_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/deprecated.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000001_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000009_000077.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000011_000037.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000013_000037.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000016_000013.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000020_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000027_000026.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000028_000026.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000030_000026.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000032_000011.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000032_000017.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000038_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000039_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000047_000095.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000054_000011.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000062_000048.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000063_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000064_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000065_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000078_000082.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000079_000082.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000084_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000085_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000086_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000090_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000091_000093.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000093_000092.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000101_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000101_000102.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000102_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000103_000004.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_000108_000107.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_087f55dc86e2ef5d31e9c1b59168bd38_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_08c960a20b0db17f0764762d0e72de8b_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_09c12503c252eb886e96f43c24bde98c.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_09c12503c252eb886e96f43c24bde98c_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_0ab3e721b4862084a2819cf1ac46b201_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_0fde0067d6aa3912cdffe004d64d0f35.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_0fde0067d6aa3912cdffe004d64d0f35_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_1912a71006e2964f83e8e46c55b69813_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_22ea62e2015f6a823fddac4ac38ba517_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_281a58b14cc8f76e4a094a720e66e337.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_283ace9100a5361f8df0e2908a1f691c_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_2952cdb1f8e3c530719b1f63d541924c_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_2a15a6cf796d75cac59d407339e38772_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_33f9015af551a3c03ac5a968f2023d57_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_3927ff15cdce1d22d8dcb33a29894069_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_39d7140780b7378a71daf6d7e9dc9204_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_3ed122a3492a6ae370117fc5cbfc12b7_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_43253d775e33d5158290be54cbed80db_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_4bdad7b73fba090aa2c2769f8db7d564_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_4c6350ab3f31523f66058454f248b31d.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_59dd179f705c75b7b821c61754f4942c_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_5e5c02437cc343e696d4b23de5bc0c48_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_5f8f0bfb0fa844bddb949c179c0766c9_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_67e5f5b4ec08fa66f6c096161f4e9853.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_67e5f5b4ec08fa66f6c096161f4e9853_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_683cc5e4f32c1363954df77ec415d9a8_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_6acfa0788722cd7f252c15e33dfdaa52.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_73b33d7e294d2897b9ba5bc94354ca5e.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_73b33d7e294d2897b9ba5bc94354ca5e_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_74e9364f374e99e3aeab4fae4e196292_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_76240043685def425cc7c4f62ca4854c_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_7d983a2362450c6a8f8032b225457939_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_89bc987d46935ede7c2428756fc184ea.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_89c2f5c503471b453ec8dce126a8dc25_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_9b165319984ecf48a042298e7d2e4e33.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_9b165319984ecf48a042298e7d2e4e33_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_a032a7051e4aa81f3209ac18b486370c_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_b41d254693bea6e92988e5bb1ad97e02.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_c1d4e9c340a4a90e8f19d314936529b6_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_c26a45075aa7057f5e495d7b601b10be.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_c27e2935c3c48ccfc237774921d0ba31.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_c80305d8496a0ccafcdf1fe9f1ee1634.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_c80305d8496a0ccafcdf1fe9f1ee1634_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_c811caf98c2e04bafa07f21217373ed4_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_d204179283756f69f56333ace13c3627_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_d241d1e9c81a0d48fc40024e821b76f8_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_d31e09e4a950a07f76ddbad611322029.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_d31e09e4a950a07f76ddbad611322029_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_d7e2d487ef1c130831fd013dcc7a3310_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_dc746521347beef8199a9d678e2ad1c1.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_e08522379c609b1c2fc9a1e330341df1_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_e3d5046e0e1c12b3e0e191db409337bd.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_e3d5046e0e1c12b3e0e191db409337bd_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_e8044aeb54b6e433ec393b1e912b002a.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_e8044aeb54b6e433ec393b1e912b002a_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_edbd05defa7d897e6588eb3f84517e19_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_f8d2defef88098d0bc5331515603729f_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_f975b82d147a340f2ab6ec1753ee61b7_dep.dot
    www-releases/trunk/3.2/docs/doxygen/html/dir_f9f6b3947ab0a4f11149827305509097_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_fbe82809dcfbfeaed1a3b1e8f8ba016c.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_fd2d7b5ce83b1c1657cd6600d8cb39fa.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_fd2d7b5ce83b1c1657cd6600d8cb39fa_dep.md5
    www-releases/trunk/3.2/docs/doxygen/html/dir_ff89db33b3486973c60c3f7241231121.html
    www-releases/trunk/3.2/docs/doxygen/html/dir_ffba78af1c96061d0b263a636abedf02.html
    www-releases/trunk/3.2/docs/doxygen/html/edit__distance_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/edit__distance_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/edit__distance_8h__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/functions_0x68.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_0x6d.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_0x70.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_0x73.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_0x76.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_enum.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_eval_0x66.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_eval_0x69.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_eval_0x6b.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_eval_0x6e.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_eval_0x71.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_func.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_func_0x6e.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_func_0x71.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_func_0x74.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_func_0x77.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_rela_0x66.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_rela_0x69.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_rela_0x6e.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_rela_0x74.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_type_0x66.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_type_0x69.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_type_0x6b.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_type_0x6e.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_vars_0x6d.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_vars_0x70.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_vars_0x73.html
    www-releases/trunk/3.2/docs/doxygen/html/functions_vars_0x76.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_0x69.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_0x6e.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_0x71.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_0x74.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_0x77.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_defs_0x63.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_defs_0x66.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_defs_0x75.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_defs_0x78.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_eval_0x66.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_eval_0x69.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_eval_0x6b.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_eval_0x6e.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_eval_0x74.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_func_0x62.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_func_0x74.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_func_0x77.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_vars_0x6d.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_vars_0x70.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_vars_0x73.html
    www-releases/trunk/3.2/docs/doxygen/html/globals_vars_0x76.html
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCAnalysis.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCBitWriter.html
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCore.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreContext.html
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreMemoryBuffers.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCorePassManagers.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreTypeFloat.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreTypeFunction.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreTypeStruct.html
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreTypes.html
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreValueBasicBlock.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreValueConstantGlobals.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreValueFunction.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreValueInstructionPHINode.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreValueUser.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCCoreValues.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCDisassembler.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCEnhancedDisassembly.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCEnhancedDisassembly.html
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCExecutionEngine.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCInitialization.dot
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCLTO.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCTarget.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCTransforms.html
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCTransformsIPO.md5
    www-releases/trunk/3.2/docs/doxygen/html/group__LLVMCoreValueConstantGlobalVariable.html
    www-releases/trunk/3.2/docs/doxygen/html/ilist_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/include_2llvm-c_2Disassembler_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/include_2llvm-c_2Disassembler_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/include_2llvm_2ExecutionEngine_2MCJIT_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/include_2llvm_2Support_2Disassembler_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/include_2llvm_2Support_2Disassembler_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/include_2llvm_2Support_2Disassembler_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_10.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1000.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1004.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1006.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1009.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1014.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1018.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1019.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_102.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1021.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1022.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1026.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1028.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_103.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1031.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1034.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1036.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1043.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1044.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1048.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1049.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1051.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1053.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1056.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1058.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1061.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1065.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1066.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_107.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1073.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1074.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1078.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_108.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1081.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1083.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1087.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1088.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1090.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1091.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1095.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1096.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_110.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1102.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1103.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1107.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1108.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_111.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1110.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1115.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1117.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1120.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1124.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1125.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1129.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1132.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1133.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1137.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1139.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1140.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1142.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1145.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1147.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_115.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1150.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1154.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1155.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1159.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1162.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1164.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1167.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1169.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_117.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1172.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1176.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1177.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1180.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1184.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1186.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1189.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1192.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1194.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1198.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1199.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_120.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1201.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1204.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1206.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1213.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1214.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1218.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1219.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1221.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1223.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1226.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1228.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1231.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1235.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1236.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_124.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1243.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1248.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_125.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1251.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1253.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1257.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1258.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1260.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1261.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1265.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1266.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1270.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1273.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1275.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1278.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1282.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1283.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1287.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1288.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_129.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1290.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1291.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1295.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1297.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_13.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1302.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1303.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1307.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1309.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1310.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1312.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1317.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_132.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1320.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1324.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1325.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1329.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_133.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1332.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1334.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1337.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1339.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1341.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1342.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1346.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1347.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1350.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1354.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1356.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1359.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1362.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_1364.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_137.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_139.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_140.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_142.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_145.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_147.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_15.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_150.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_154.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_155.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_159.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_162.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_164.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_167.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_169.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_172.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_176.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_177.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_180.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_184.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_186.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_189.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_19.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_192.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_194.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_198.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_199.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_201.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_204.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_206.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_213.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_214.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_218.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_219.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_22.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_221.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_223.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_226.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_228.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_23.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_231.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_235.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_236.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_243.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_244.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_248.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_251.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_253.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_257.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_258.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_260.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_261.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_265.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_266.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_27.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_273.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_275.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_278.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_282.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_283.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_287.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_288.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_29.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_290.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_291.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_295.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_297.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_3.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_30.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_302.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_303.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_307.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_309.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_310.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_312.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_315.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_317.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_32.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_320.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_324.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_325.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_329.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_332.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_334.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_337.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_339.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_342.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_346.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_347.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_35.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_350.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_354.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_356.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_359.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_362.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_364.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_368.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_369.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_37.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_371.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_372.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_376.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_377.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_381.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_384.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_386.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_393.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_394.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_398.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_399.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_4.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_40.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_401.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_405.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_406.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_413.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_418.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_421.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_423.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_427.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_428.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_430.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_431.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_435.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_436.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_44.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_440.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_443.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_445.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_448.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_45.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_452.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_453.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_457.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_458.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_460.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_461.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_465.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_467.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_470.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_475.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_479.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_482.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_483.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_487.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_489.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_49.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_490.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_492.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_495.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_497.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_502.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_504.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_507.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_509.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_511.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_512.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_516.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_517.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_52.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_520.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_524.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_526.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_529.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_532.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_534.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_538.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_539.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_54.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_541.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_542.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_546.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_551.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_554.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_556.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_563.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_564.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_568.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_569.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_57.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_571.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_576.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_578.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_581.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_585.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_586.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_59.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_593.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_594.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_598.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_60.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_600.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_601.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_605.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_606.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_610.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_613.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_615.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_62.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_622.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_623.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_627.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_628.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_630.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_631.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_635.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_637.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_640.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_645.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_649.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_652.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_653.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_657.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_659.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_66.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_660.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_662.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_665.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_667.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_67.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_670.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_674.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_675.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_679.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_682.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_684.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_687.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_689.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_690.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_692.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_696.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_697.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_70.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_702.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_704.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_708.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_709.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_711.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_712.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_716.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_721.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_724.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_726.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_733.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_734.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_738.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_739.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_74.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_741.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_743.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_746.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_748.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_75.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_751.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_755.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_756.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_763.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_764.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_768.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_771.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_773.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_778.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_780.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_781.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_785.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_786.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_79.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_793.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_795.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_798.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_8.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_800.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_801.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_805.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_807.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_810.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_814.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_815.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_819.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_82.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_822.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_823.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_827.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_829.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_830.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_832.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_835.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_837.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_84.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_840.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_844.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_845.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_849.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_852.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_854.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_857.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_859.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_860.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_862.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_866.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_867.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_870.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_874.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_876.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_879.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_88.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_882.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_884.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_888.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_889.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_89.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_891.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_892.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_896.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_897.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_903.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_904.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_908.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_909.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_91.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_911.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_913.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_916.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_918.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_92.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_921.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_925.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_926.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_933.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_934.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_938.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_941.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_943.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_947.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_948.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_950.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_951.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_955.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_956.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_96.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_963.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_965.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_968.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_97.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_972.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_973.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_977.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_978.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_980.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_981.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_985.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_987.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_990.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_993.md5
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_995.dot
    www-releases/trunk/3.2/docs/doxygen/html/inherit_graph_999.md5
    www-releases/trunk/3.2/docs/doxygen/html/ittnotify__config_8h__dep__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/ittnotify__config_8h__dep__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/ittnotify__types_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/ittnotify__types_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/jitprofiling_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/lib_2ExecutionEngine_2JIT_2JIT_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/lib_2ExecutionEngine_2MCJIT_2MCJIT_8h__dep__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/lib_2MC_2MCDisassembler_2Disassembler_8h__dep__incl.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/lib_2MC_2MCDisassembler_2Disassembler_8h__incl.map
    www-releases/trunk/3.2/docs/doxygen/html/lib_2MC_2MCDisassembler_2Disassembler_8h__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/llvm-config_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacePBQP.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacegen-register-defs.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1ARM.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1ARM__AM.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1CodeGenOpt.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1FPOpFusion.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1GC.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1Hexagon.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1HexagonII.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1HexagonISD.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1ISD.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1LCOMM.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1MBlaze.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1MBlazeII.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1MCD.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1MCID.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1MSP430ISD.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1N86.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1NVPTXCC.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1PPCISD.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1PatternMatch.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1X86II.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1XCore.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1XCoreISD.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1hashing.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1jitprofiling.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1support.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1support_1_1detail.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacellvm_1_1sys_1_1path.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_0x62.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_0x65.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_0x68.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_0x6a.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_0x6d.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_0x70.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_eval_0x64.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_eval_0x76.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_func_0x64.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_func_0x67.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_func_0x6c.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacemembers_func_0x6f.html
    www-releases/trunk/3.2/docs/doxygen/html/namespaces.html
    www-releases/trunk/3.2/docs/doxygen/html/namespacestats.html
    www-releases/trunk/3.2/docs/doxygen/html/open.png   (with props)
    www-releases/trunk/3.2/docs/doxygen/html/raw__os__ostream_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/raw__ostream_8cpp__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/raw__ostream_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/regerror_8c.html
    www-releases/trunk/3.2/docs/doxygen/html/regex__impl_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/regex__impl_8h_source.html
    www-releases/trunk/3.2/docs/doxygen/html/regfree_8c__incl.md5
    www-releases/trunk/3.2/docs/doxygen/html/regstrlcpy_8c.html
    www-releases/trunk/3.2/docs/doxygen/html/regutils_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/regutils_8h__incl.dot
    www-releases/trunk/3.2/docs/doxygen/html/structAddSubFlagsOpcodePair-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structAllocaPartitioning_1_1BuilderBase_1_1OffsetUse__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structConsecutiveMemoryChainSorter-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structFindHandleTraits__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structFindHandleTraits__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structInstructionSpecifier__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structJobHandleTraits__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structLLVMOpInfoSymbol1-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structLLVMOpInfoSymbol1__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structMarkPendingLoopPredicate-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structMarkPendingLoopPredicate__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structOpcodeDecision.html
    www-releases/trunk/3.2/docs/doxygen/html/structOperandSpecifier__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structPBQP_1_1Heuristics_1_1Briggs_1_1NodeData__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structPathProfileHeader__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structRegisterOperands.html
    www-releases/trunk/3.2/docs/doxygen/html/structRegisterOperands__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structSpillPlacement_1_1Node__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structTripleMap__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structX86CostTblEntry.html
    www-releases/trunk/3.2/docs/doxygen/html/struct__LineNumberInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/struct______itt__global-members.html
    www-releases/trunk/3.2/docs/doxygen/html/struct______itt__group__list.html
    www-releases/trunk/3.2/docs/doxygen/html/struct______itt__thread__info__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/struct__iJIT__Method__Id.html
    www-releases/trunk/3.2/docs/doxygen/html/struct__iJIT__Method__Id__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/struct__iJIT__Method__Load__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structfalse_1_1SingleLoopExtractor__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1APInt_1_1ms.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ARMRegisterInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AliasAnalysis_1_1Location-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AliasAnalysis_1_1Location__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AlignmentCalcImpl.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AlignmentCalcImpl__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AnonStructTypeKeyInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AnonStructTypeKeyInfo_1_1KeyTy-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AnonStructTypeKeyInfo_1_1KeyTy__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AttributeWithIndex-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1AttributeWithIndex__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1BitstreamReader_1_1BlockInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1AuxiliaryFile.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1AuxiliaryFile__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1AuxiliarySectionDefinition__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1AuxiliaryWeakExternal__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1AuxiliarybfAndefSymbol-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1AuxiliarybfAndefSymbol__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1DOSHeader__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1DataDirectory__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1ImportHeader-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1ImportLookupTableEntry32__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1PEHeader-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1PEHeader.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1PEHeader__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1header-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1header.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1relocation.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1section-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1section.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1COFF_1_1symbol__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ClonedCodeInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1CodeMetrics__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ConstantCreator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ConstantCreator_3_01InlineAsm_00_01PointerType_00_01InlineAsmKeyType_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ConstantKeyData.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ConstantTraits_3_01std_1_1vector_3_01T_00_01Alloc_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ContextualFoldingSetTrait__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraitsPrinter.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraitsPrinter__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraitsViewer-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraitsViewer__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01DomTreeNode_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01DominatorTree_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01DominatorTree_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01RegionInfo_01_5_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01RegionNode_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01SelectionDAG_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01const_01Function_01_5_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01const_01Function_01_5_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01const_01MachineFunction_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01const_01MachineFunction_01_5_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DOTGraphTraits_3_01const_01MachineFunction_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugArangeSet_1_1Descriptor__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugAranges_1_1Range__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1DumpingState__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1DumpingState__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1LineTable__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1LineTable__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1Prologue.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1Sequence.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1Sequence__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugLine_1_1State__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugRangeList_1_1RangeListEntry.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFDebugRangeList_1_1RangeListEntry__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DWARFFormValue_1_1ValueType__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DefaultContextualFoldingSetTrait__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DefaultDOTGraphTraits.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DefaultFoldingSetTrait__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapAPFloatKeyInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapAPIntKeyInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapAPIntKeyInfo_1_1KeyTy-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapAPIntKeyInfo_1_1KeyTy__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapInfo_3_01CIEKey_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapInfo_3_01DivOpInfo_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapInfo_3_01ImmutableList_3_01T_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapInfo_3_01SDValue_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapInfo_3_01unsigned_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DenseMapInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1Dependence_1_1DVEntry.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DwarfAccelTable_1_1HashDataContents.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DwarfException_1_1ActionEntry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1DwarfException_1_1ActionEntry__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1EDDisassembler__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1EDInst-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1EDInst.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1EDInst__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1EDToken-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf32__Dyn-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf32__Dyn.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf32__Dyn__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf32__Ehdr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf32__Phdr__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf32__Rel__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf32__Sym-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf64__Dyn.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf64__Ehdr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf64__Phdr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ELF_1_1Elf64__Rela.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1EVT_1_1compareRawBits-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ExecutionEngineState_1_1AddressMapConfig__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ExprMapKeyType-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ExprMapKeyType.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ExtAddrMode.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1FoldingSetTrait_3_01MDNode_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1FoldingSetTrait_3_01MDNode_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1FoldingSetTrait_3_01SCEV_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1FoldingSetTrait_3_01SCEV_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1FoldingSetTrait_3_01SCEV_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1FoldingSetTrait_3_01T_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1FunctionTypeKeyInfo_1_1KeyTy__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01ArgumentGraphNode_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01ArgumentGraphNode_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01ArgumentGraph_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01CallGraphNode_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01CallGraph_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01CallGraph_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01DominatorTree_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Interval_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01BasicBlock_01_5_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01Function_01_5_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01Interval_01_5_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01MachineBasicBlock_01_5_01_4_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01MachineFunction_01_5_01_4_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01MachineFunction_01_5_01_4_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01BasicBlock_01_5_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01BasicBlock_01_5_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01Function_01_5_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01Function_01_5_01_4_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01MachineBasicBlock_01_5_01_4_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01MachineFunction_01_5_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01MachineFunction_01_5_01_4_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01MachineFunction_01_5_01_4_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01Inverse_3_01const_01User_01_5_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01MachineDomTreeNode_01_5_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01MachineFunction_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01MachineFunction_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01MachineFunction_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01PostDominatorTree_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01PostDominatorTree_01_5_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01PostDominatorTree_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01RegionInfo_01_5_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01ScheduleDAG_01_5_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01ScheduleDAG_01_5_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01CallGraph_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01CallGraph_01_5_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01Function_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01Function_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01Loop_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01Loop_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01MachineBasicBlock_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01MachineBasicBlock_01_5_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01MachineFunction_01_5_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1GraphTraits_3_01const_01MachineLoop_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1HexagonRegisterInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1HungoffOperandTraits.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ILPValue.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ILPValue__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ISD_1_1InputArg-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ISD_1_1InputArg__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ISD_1_1OutputArg-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ImutContainerInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ImutContainerInfo_3_01T_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ImutContainerInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ImutContainerInfo__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ImutProfileInteger.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1IncludeFile-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1IndirectSymbolData__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1InlineAsmKeyType__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1InlineAsm_1_1ConstraintInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1Inliner__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1InstrStage-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1InstrStage__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1IntegersSubsetMapping_1_1RangeEx-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1IntegersSubsetMapping_1_1RangeEx__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1JITEvent__EmittedFunctionDetails_1_1LineStart__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LandingPadInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LeakDetector.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LeakDetectorImpl__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LetRecord__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LibCallAliasAnalysis-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LibCallAliasAnalysis__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LibCallFunctionInfo_1_1LocationMRInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LibCallFunctionInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LibCallLocationInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LiveRangeEdit_1_1Remat-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LiveRangeEdit_1_1Remat.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LiveVariables_1_1VarInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1LiveVariables_1_1VarInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MBB2NumberFunctor-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MBB2NumberFunctor__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MBlazeRegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCDwarfFrameInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCFixupKindInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCFixupKindInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCFixupKindInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCReadAdvanceEntry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCRegisterDesc-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCRegisterDesc.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCRegisterInfo_1_1DwarfLLVMRegPair.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCWin64EHUnwindInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MCWin64EHUnwindInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MDBuilder_1_1TBAAStructField.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MSP430RegisterInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1dyld__info__command__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1dylib__command__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1dylib__module.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1dylib__module__64-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1dylib__module__64__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1dylib__module__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1dysymtab__command__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1encryption__info__command.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1fat__arch.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1fat__header__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1fvmfile__command-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1fvmfile__command__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1fvmlib__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1load__command-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1load__command__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1mach__header__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1nlist__64__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1nlist__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1prebind__cksum__command-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1prebind__cksum__command__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1routines__command-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1routines__command__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1section__64.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1section__64__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1segment__command__64-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1segment__command__64__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1segment__command__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1sub__client__command-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1sub__client__command__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1sub__framework__command.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1sub__library__command.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1symseg__command-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1symtab__command.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1twolevel__hint-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1twolevel__hints__command__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1uuid__command-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachO_1_1version__min__command__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachineInstrExpressionTrait.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachineOperandIteratorBase_1_1PhysRegInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachinePostDominatorTree.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachinePostDominatorTree__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MachineSchedContext.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1MipsAnalyzeImmediate_1_1Inst.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1Module_1_1ModuleFlagEntry.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1NVPTXSplitBBatBar__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01AtomicCmpXchgInst_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01AtomicRMWInst_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01BinaryOperator_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01BinaryOperator_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01BlockAddress_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01BlockAddress_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01BranchInst_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01CallInst_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01CompareConstantExpr_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ConstantArray_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ConstantExpr_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ConstantPlaceHolder_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ConstantPlaceHolder_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ConstantStruct_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ConstantVector_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ExtractElementInst_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ExtractElementInst_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01GetElementPtrConstantExpr_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01GetElementPtrInst_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01GlobalVariable_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01IndirectBrInst_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01InsertElementInst_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01InsertValueConstantExpr_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01InsertValueConstantExpr_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01InsertValueInst_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01InsertValueInst_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01InvokeInst_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01PHINode_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01PHINode_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ResumeInst_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ResumeInst_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ReturnInst_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ReturnInst_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01SelectInst_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01ShuffleVectorConstantExpr_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01StoreInst_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01StoreInst_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01SwitchInst_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01UnaryConstantExpr_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OperandTraits_3_01UnaryInstruction_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OptionalOperandTraits-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OptionalOperandTraits__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1OptionalOperandTraits__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ParseInstructionInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ParseInstructionInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ParseInstructionInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1BinOp2__match.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1CastClass__match.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1Exact__match__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1OneUse__match-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1OneUse__match.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1SelectClass__match-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1apint__match__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1bind__const__intval__ty__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1bind__ty-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1class__match.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1cst__pred__ty__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1cst__pred__ty__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1is__sign__bit-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1is__sign__bit.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1neg__match__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1not__match.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1smax__pred__ty-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1smax__pred__ty.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1smin__pred__ty-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PatternMatch_1_1specificval__ty__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PhysRegSUOper__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PointerAlignElem.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PointerUnionTypeSelectorReturn_3_01PointerUnionTypeSelector_3_01T1_00_01T2_00_01RET__EQ_00_01RET__NE_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PointerUnionTypeSelector_3_01T_00_01T_00_01RET__EQ_00_01RET__NE_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PostDominatorTree-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PostDominatorTree__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PressureElement__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1PrinterTrait.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RecyclerStruct__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ReferenceAdder_3_01T_01_6_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterMCAsmBackend-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterMCAsmBackend.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterMCAsmInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterMCAsmParser-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterMCInstrInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterMCInstrInfoFn-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterPass__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1RegisterPressure__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SCEVCouldNotCompute.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SaveOr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SmallVectorStorage.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SmallVectorStorage_3_01T_00_010_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SparcRegisterInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SparcRegisterInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SparcRegisterInfo__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SparseBitVectorElement-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SparseSetValFunctor__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SparseSetValTraits-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SparseSetValTraits.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SpillPlacement_1_1BlockConstraint.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SplitAnalysis_1_1BlockInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SplitAnalysis_1_1BlockInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SubMultiClassReference.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SubtargetInfoKV.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1SubtargetInfoKV__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1TargetLowering_1_1ArgListEntry.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1TargetLowering_1_1ArgListEntry__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1TargetLowering_1_1AsmOperandInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1TargetLowering_1_1DAGCombinerInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1TargetLowering_1_1IntrinsicInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1TargetLowering_1_1TargetLoweringOpt__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1TargetRegisterInfoDesc-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1Thumb1RegisterInfo__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1Thumb2RegisterInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1UnifyFunctionExitNodes.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1UnifyFunctionExitNodes__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ValueMapConfig.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ValueMapConfig_1_1ExtraData.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ValueMapConfig__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ValueMapConstIterator_1_1ValueTypeProxy.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ValueMapIterator_1_1ValueTypeProxy.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1VariadicFunction1-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1Win64EH_1_1RuntimeFunction-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1Win64EH_1_1UnwindInfo.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1X86AddressMode.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1X86AddressMode__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1X86__64MCAsmInfoDarwin__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1X86__64MCAsmInfoDarwin__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1XCoreRegisterInfo-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1XCoreRegisterInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cast__convert__val.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cast__convert__val_3_01To_00_01FromTy_00_01FromTy_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cast__convert__val_3_01To_00_01FromTy_00_01FromTy_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cast__retty__impl_3_01To_00_01From_01_5_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cast__retty__impl_3_01To_00_01const_01From_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cast__retty__wrap.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cast__retty__wrap_3_01To_00_01FromTy_00_01FromTy_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1OptionDiffPrinter-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1OptionDiffPrinter.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1OptionDiffPrinter_3_01DT_00_01DT_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1OptionDiffPrinter_3_01DT_00_01DT_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1OptionValueBase.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1OptionValueBase_3_01DataType_00_01false_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1OptionValueBase_3_01DataType_00_01false_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1applicator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1applicator_3_01NumOccurrencesFlag_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1applicator_3_01OptionHidden_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1applicator_3_01ValueExpected_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1applicator_3_01char[n]_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1applicator_3_01const_01char[n]_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1initializer.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1cl_1_1initializer__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1df__ext__iterator-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1enable__if.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1enable__if__c__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1enable__if__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1fltSemantics__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1greater__ptr-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1hash__combine__recursive__helper.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1hash__state__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1is__hashable__data-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1is__hashable__data_3_01std_1_1pair_3_01T_00_01U_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1is__hashable__data_3_01std_1_1pair_3_01T_00_01U_01_4_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1is__hashable__data_3_01std_1_1pair_3_01T_00_01U_01_4_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1is__hashable__data__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1hashing_1_1detail_1_1is__hashable__data__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1idf__iterator.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1idf__iterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__node__traits_3_01Token_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01Argument_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01BasicBlock_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01Function_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01GlobalAlias_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01GlobalVariable_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01GlobalVariable_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01IVStrideUse_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01IndexListEntry_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01Instruction_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01Instruction_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01MachineBasicBlock_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01MachineInstr_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01MachineInstr_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01NamedMDNode_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01SDNode_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01SparseBitVectorElement_3_01ElementSize_01_4_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01SparseBitVectorElement_3_01ElementSize_01_4_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01const_01Ty_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ilist__traits_3_01const_01Ty_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ipo__ext__iterator__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1ipo__iterator__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01AssertingVH_3_01T_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01AssertingVH_3_01T_01_4_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01CallValue_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01CallValue_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01LiveRange_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01MCOperand_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01PointerIntPair_3_01PointerTy_00_01IntBits_00_01IntType_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01PointerIntPair_3_01PointerTy_00_01IntBits_00_01IntType_01_4_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01SDValue_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01SDValue_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01SDValue_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01StringRef_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01std_1_1pair_3_01T_00_01U_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isPodLike_3_01std_1_1pair_3_01T_00_01U_01_4_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__code__enum_3_01object_1_1object__error_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__code__enum_3_01object_1_1object__error_1_1___01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__code__enum_3_01windows__error_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__code__enum_3_01windows__error_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__code__enum_3_01windows__error_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__code__enum_3_01windows__error_1_1___01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__code__enum__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__condition__enum_3_01errc_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__condition__enum_3_01errc_1_1___01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__error__condition__enum_3_01errc_1_1___01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01bool_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01char_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01int_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01long_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01short_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01unsigned_01int_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01unsigned_01long_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01unsigned_01long_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01unsigned_01long_01long_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01unsigned_01long_01long_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01unsigned_01short_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__integral__impl_3_01wchar__t_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__pointer-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__pointer_3_01T_01_5const_01_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__pointer_3_01T_01_5const_01_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__pointer_3_01T_01_5const_01_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__pointer_3_01T_01_5volatile_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__same_3_01T_00_01T_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1is__same__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl_3_01Argument_00_01Value_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl_3_01Constant_00_01Value_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl_3_01GlobalValue_00_01Value_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl_3_01GlobalVariable_00_01Value_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl_3_01InlineAsm_00_01Value_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl_3_01Instruction_00_01Value_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl__cl_3_01To_00_01const_01From_01_5_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl__cl_3_01To_00_01const_01From_01_5const_01_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl__wrap_3_01To_00_01FromTy_00_01FromTy_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1isa__impl__wrap_3_01To_00_01FromTy_00_01FromTy_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1latency__sort__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1less__ptr__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1ELFDataTypeTypedefHelper_3_01target__endianness_00_01false_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Dyn__Base_3_01target__endianness_00_01false_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Dyn__Base_3_01target__endianness_00_01true_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Dyn__Impl__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Phdr_3_01target__endianness_00_01false_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Phdr_3_01target__endianness_00_01true_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Phdr_3_01target__endianness_00_01true_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Base_3_01target__endianness_00_01false_00_01false_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Base_3_01target__endianness_00_01false_00_01false_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Base_3_01target__endianness_00_01false_00_01true_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Base_3_01target__endianness_00_01false_00_01true_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Base_3_01target__endianness_00_01false_00_01true_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Base_3_01target__endianness_00_01true_00_01false_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Base_3_01target__endianness_00_01true_00_01false_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Impl_3_01target__endianness_00_01false_00_01isRela_01_4__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Rel__Impl_3_01target__endianness_00_01true_00_01isRela_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Shdr__Base_3_01target__endianness_00_01false_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Shdr__Base_3_01target__endianness_00_01false_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Sym__Impl__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Verdaux__Impl__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Verdef__Impl__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Vernaux__Impl__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1Elf__Verneed__Impl-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1MachOObject_1_1LoadCommandInfo__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1RelocToApply.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1coff__relocation__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1coff__section.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1coff__symbol.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1coff__symbol_1_1StringTableOffset-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1coff__symbol_1_1StringTableOffset.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1coff__symbol__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1DysymtabLoadCommand-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1Header.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1Header64Ext__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1IndirectSymbolTableEntry__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1LoadCommand-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1LoadCommand__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1RelocationEntry.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1Section64-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1Section64.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1SegmentLoadCommand-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1Symbol64TableEntry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1Symbol64TableEntry.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1Symbol64TableEntry__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1SymbolTableEntry-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1object_1_1macho_1_1SymbolTableEntry__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1po__ext__iterator__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1remove__const.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1remove__const_3_01const_01T_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1remove__pointer_3_01T_01_5volatile_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1remove__pointer_3_01T_01_5volatile_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1resource__sort__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01AssertingVH_3_01Value_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01CallbackVH_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01CallbackVH_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01IntrusiveRefCntPtr_3_01T_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01TrackingVH_3_01Value_01_4_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01WeakVH_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01AssertingVH_3_01Value_01_4_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01CallbackVH_01_4__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01From_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01Optional_3_01T_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01SDUse_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01SDUse_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01TrackingVH_3_01Value_01_4_01_4-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01WeakVH_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01WeakVH_01_4__inherit__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1simplify__type_3_01const_01ilist__iterator_3_01NodeTy_01_4_01_4.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1support_1_1detail_1_1alignment__access__helper_3_01value__type_00_01aligned_01_4__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1sys_1_1fs_1_1detail_1_1DirIterState__inherit__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1sys_1_1fs_1_1detail_1_1RecDirIterState__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1sys_1_1fs_1_1file__magic.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1sys_1_1fs_1_1space__info-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1sys_1_1fs_1_1space__info__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm_1_1tier__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structllvm__regex-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structllvm__regex__coll__graph.md5
    www-releases/trunk/3.2/docs/doxygen/html/structparse-members.html
    www-releases/trunk/3.2/docs/doxygen/html/structre__guts.html
    www-releases/trunk/3.2/docs/doxygen/html/structre__guts__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/structrerr.html
    www-releases/trunk/3.2/docs/doxygen/html/structrerr__coll__graph.dot
    www-releases/trunk/3.2/docs/doxygen/html/system__error_8cpp.html
    www-releases/trunk/3.2/docs/doxygen/html/type__traits_8h.html
    www-releases/trunk/3.2/docs/doxygen/html/unionllvm_1_1AlignedCharArrayUnion.html
    www-releases/trunk/3.2/docs/doxygen/html/unionllvm_1_1COFF_1_1Auxiliary.html
    www-releases/trunk/3.2/docs/doxygen/html/unionllvm_1_1Win64EH_1_1UnwindCode.html
    www-releases/trunk/3.2/docs/html.tar.gz   (with props)
    www-releases/trunk/3.2/docs/index.rst
    www-releases/trunk/3.2/docs/llvm-theme/
    www-releases/trunk/3.2/docs/llvm-theme/static/
    www-releases/trunk/3.2/docs/mailing_lists.rst
    www-releases/trunk/3.2/docs/make.bat
    www-releases/trunk/3.2/docs/programming.rst
    www-releases/trunk/3.2/docs/re_format.7
    www-releases/trunk/3.2/docs/subsystems.rst
    www-releases/trunk/3.2/docs/tutorial/
    www-releases/trunk/3.2/docs/tutorial/LangImpl1.html
    www-releases/trunk/3.2/docs/tutorial/LangImpl2.html
    www-releases/trunk/3.2/docs/tutorial/LangImpl3.html
    www-releases/trunk/3.2/docs/tutorial/LangImpl4.html
    www-releases/trunk/3.2/docs/tutorial/LangImpl5-cfg.png   (with props)
    www-releases/trunk/3.2/docs/tutorial/LangImpl5.html
    www-releases/trunk/3.2/docs/tutorial/LangImpl6.html
    www-releases/trunk/3.2/docs/tutorial/LangImpl7.html
    www-releases/trunk/3.2/docs/tutorial/LangImpl8.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl1.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl2.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl3.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl4.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl5.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl6.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl7.html
    www-releases/trunk/3.2/docs/tutorial/OCamlLangImpl8.html
    www-releases/trunk/3.2/docs/tutorial/index.html
    www-releases/trunk/3.2/docs/userguides.rst
    www-releases/trunk/3.2/docs/yaml2obj.rst

Added: www-releases/trunk/3.2/docs/AliasAnalysis.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/AliasAnalysis.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/AliasAnalysis.rst (added)
+++ www-releases/trunk/3.2/docs/AliasAnalysis.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,702 @@
+.. _alias_analysis:
+
+==================================
+LLVM Alias Analysis Infrastructure
+==================================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+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 `Must, May, or No`_ 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.
+
+The LLVM `AliasAnalysis
+<http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html>`__ 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.
+
+This document contains information necessary to successfully implement this
+interface, use it, and to test both sides.  It also explains some of the finer
+points about what exactly results mean.  If you feel that something is unclear
+or should be added, please `let me know <mailto:sabre at nondot.org>`_.
+
+``AliasAnalysis`` Class Overview
+================================
+
+The `AliasAnalysis <http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html>`__
+class defines the interface that the various alias analysis implementations
+should support.  This class exports two important enums: ``AliasResult`` and
+``ModRefResult`` which represent the result of an alias query or a mod/ref
+query, respectively.
+
+The ``AliasAnalysis`` 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
+``call`` or ``invoke`` instructions that performs the call.  The
+``AliasAnalysis`` interface also exposes some helper methods which allow you to
+get mod/ref information for arbitrary instructions.
+
+All ``AliasAnalysis`` interfaces require that in queries involving multiple
+values, values which are not `constants <LangRef.html#constants>`_ are all
+defined within the same function.
+
+Representation of Pointers
+--------------------------
+
+Most importantly, the ``AliasAnalysis`` 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
+``Value*``) and a static size.
+
+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:
+
+.. code-block:: c++
+
+  int i;
+  char C[2];
+  char A[10]; 
+  /* ... */
+  for (i = 0; i != 10; ++i) {
+    C[0] = A[i];          /* One byte store */
+    C[1] = A[9-i];        /* One byte store */
+  }
+
+In this case, the ``basicaa`` pass will disambiguate the stores to ``C[0]`` and
+``C[1]`` 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:
+
+.. code-block:: c++
+
+  int i;
+  char C[2];
+  char A[10]; 
+  /* ... */
+  for (i = 0; i != 10; ++i) {
+    ((short*)C)[0] = A[i];  /* Two byte store! */
+    C[1] = A[9-i];          /* One byte store */
+  }
+
+In this case, the two stores to C do alias each other, because the access to the
+``&C[0]`` 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.
+
+.. _alias:
+
+The ``alias`` method
+--------------------
+  
+The ``alias`` 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.
+
+Like all ``AliasAnalysis`` interfaces, the ``alias`` method requires that either
+the two pointer values be defined within the same function, or at least one of
+the values is a `constant <LangRef.html#constants>`_.
+
+.. _Must, May, or No:
+
+Must, May, and No Alias Responses
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``NoAlias`` response may be used when there is never an immediate dependence
+between any memory reference *based* on one pointer and any memory reference
+*based* 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.
+
+As an exception to this is with the `noalias <LangRef.html#noalias>`_ keyword;
+the "irrelevant" dependencies are ignored.
+
+The ``MayAlias`` response is used whenever the two pointers might refer to the
+same object.
+
+The ``PartialAlias`` response is used when the two memory objects are known to
+be overlapping in some way, but do not start at the same address.
+
+The ``MustAlias`` response may only be returned if the two memory objects are
+guaranteed to always start at exactly the same location. A ``MustAlias``
+response implies that the pointers compare equal.
+
+The ``getModRefInfo`` methods
+-----------------------------
+
+The ``getModRefInfo`` 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 **might** read or write a location,
+``ModRef`` is returned.
+
+The ``AliasAnalysis`` class also provides a ``getModRefInfo`` method for testing
+dependencies between function calls.  This method takes two call sites (``CS1``
+& ``CS2``), returns ``NoModRef`` if neither call writes to memory read or
+written by the other, ``Ref`` if ``CS1`` reads memory written by ``CS2``,
+``Mod`` if ``CS1`` writes to memory read or written by ``CS2``, or ``ModRef`` if
+``CS1`` might read or write memory written to by ``CS2``.  Note that this
+relation is not commutative.
+
+Other useful ``AliasAnalysis`` methods
+--------------------------------------
+
+Several other tidbits of information are often collected by various alias
+analysis implementations and can be put to good use by various clients.
+
+The ``pointsToConstantMemory`` method
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``pointsToConstantMemory`` 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.
+
+.. _never access memory or only read memory:
+
+The ``doesNotAccessMemory`` and  ``onlyReadsMemory`` methods
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These methods are used to provide very simple mod/ref information for function
+calls.  The ``doesNotAccessMemory`` 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., ``sin`` and ``cos``) but many others do
+not (e.g., ``acos``, which modifies the ``errno`` variable).
+
+The ``onlyReadsMemory`` 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 ``doesNotAccessMemory`` method also satisfies ``onlyReadsMemory``.
+
+Writing a new ``AliasAnalysis`` Implementation
+==============================================
+
+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 `various alias analysis implementations`_ included with LLVM.
+
+Different Pass styles
+---------------------
+
+The first step to determining what type of `LLVM pass <WritingAnLLVMPass.html>`_
+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:
+
+#. If you require interprocedural analysis, it should be a ``Pass``.
+#. If you are a function-local analysis, subclass ``FunctionPass``.
+#. If you don't need to look at the program at all, subclass ``ImmutablePass``.
+
+In addition to the pass that you subclass, you should also inherit from the
+``AliasAnalysis`` interface, of course, and use the ``RegisterAnalysisGroup``
+template to register as an implementation of ``AliasAnalysis``.
+
+Required initialization calls
+-----------------------------
+
+Your subclass of ``AliasAnalysis`` is required to invoke two methods on the
+``AliasAnalysis`` base class: ``getAnalysisUsage`` and
+``InitializeAliasAnalysis``.  In particular, your implementation of
+``getAnalysisUsage`` should explicitly call into the
+``AliasAnalysis::getAnalysisUsage`` method in addition to doing any declaring
+any pass dependencies your pass has.  Thus you should have something like this:
+
+.. code-block:: c++
+
+  void getAnalysisUsage(AnalysisUsage &AU) const {
+    AliasAnalysis::getAnalysisUsage(AU);
+    // declare your dependencies here.
+  }
+
+Additionally, your must invoke the ``InitializeAliasAnalysis`` method from your
+analysis run method (``run`` for a ``Pass``, ``runOnFunction`` for a
+``FunctionPass``, or ``InitializePass`` for an ``ImmutablePass``).  For example
+(as part of a ``Pass``):
+
+.. code-block:: c++
+
+  bool run(Module &M) {
+    InitializeAliasAnalysis(this);
+    // Perform analysis here...
+    return false;
+  }
+
+Interfaces which may be specified
+---------------------------------
+
+All of the `AliasAnalysis
+<http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html>`__ virtual methods
+default to providing `chaining`_ 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.
+
+.. _chaining:
+.. _chain:
+
+``AliasAnalysis`` chaining behavior
+-----------------------------------
+
+With only one special exception (the `no-aa`_ pass) every alias analysis pass
+chains to another alias analysis implementation (for example, the user can
+specify "``-basicaa -ds-aa -licm``" 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:
+
+.. code-block:: c++
+
+  AliasAnalysis::AliasResult alias(const Value *V1, unsigned V1Size,
+                                   const Value *V2, unsigned V2Size) {
+    if (...)
+      return NoAlias;
+    ...
+
+    // Couldn't determine a must or no-alias result.
+    return AliasAnalysis::alias(V1, V1Size, V2, V2Size);
+  }
+
+In addition to analysis queries, you must make sure to unconditionally pass LLVM
+`update notification`_ methods to the superclass as well if you override them,
+which allows all alias analyses in a change to be updated.
+
+.. _update notification:
+
+Updating analysis results for transformations
+---------------------------------------------
+
+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.
+
+The ``AliasAnalysis`` 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.
+
+The ``deleteValue`` method
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``deleteValue`` 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.
+
+The ``copyValue`` method
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``copyValue`` 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.
+
+The ``replaceWithNewValue`` method
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+The ``addEscapingUse`` method
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``addEscapingUse`` 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.
+
+In general, any new use of a pointer value is considered an escaping use, and
+must be reported through this callback, *except* for the uses below:
+
+* A ``bitcast`` or ``getelementptr`` of the pointer
+* A ``store`` through the pointer (but not a ``store`` *of* the pointer)
+* A ``load`` through the pointer
+
+Efficiency Issues
+-----------------
+
+From the LLVM perspective, the only thing you need to do to provide an efficient
+alias analysis is to make sure that alias analysis **queries** 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).
+
+Limitations
+-----------
+
+The AliasAnalysis infrastructure has several limitations which make writing a
+new ``AliasAnalysis`` implementation difficult.
+
+There is no way to override the default alias analysis. It would be very useful
+to be able to do something like "``opt -my-aa -O2``" and have it use ``-my-aa``
+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.
+
+There is no way for transform passes to declare that they preserve
+``AliasAnalysis`` implementations. The ``AliasAnalysis`` interface includes
+``deleteValue`` and ``copyValue`` 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 ``getAnalysisUsage`` that it does so. Some passes attempt to use
+``AU.addPreserved<AliasAnalysis>``, however this doesn't actually have any
+effect.
+
+``AliasAnalysisCounter`` (``-count-aa``) and ``AliasDebugger`` (``-debug-aa``)
+are implemented as ``ModulePass`` classes, so if your alias analysis uses
+``FunctionPass``, 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
+``BasicAliasAnalysis`` instead.
+
+Similarly, the ``opt -p`` option introduces ``ModulePass`` passes between each
+pass, which prevents the use of ``FunctionPass`` alias analysis passes.
+
+The ``AliasAnalysis`` 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
+``AliasAnalysis`` implementations which can not be expressed.
+
+The ``AliasAnalysisDebugger`` utility seems to suggest that ``AliasAnalysis``
+implementations can expect that they will be informed of any relevant ``Value``
+before it appears in an alias query. However, popular clients such as ``GVN``
+don't support this, and are known to trigger errors when run with the
+``AliasAnalysisDebugger``.
+
+Due to several of the above limitations, the most obvious use for the
+``AliasAnalysisCounter`` utility, collecting stats on all alias queries in a
+compilation, doesn't work, even if the ``AliasAnalysis`` implementations don't
+use ``FunctionPass``.  There's no way to set a default, much less a default
+sequence, and there's no way to preserve it.
+
+The ``AliasSetTracker`` class (which is used by ``LICM``) makes a
+non-deterministic number of alias queries. This can cause stats collected by
+``AliasAnalysisCounter`` 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.
+
+Many alias queries can be reformulated in terms of other alias queries. When
+multiple ``AliasAnalysis`` 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.
+
+Using alias analysis results
+============================
+
+There are several different ways to use alias analysis results.  In order of
+preference, these are:
+
+Using the ``MemoryDependenceAnalysis`` Pass
+-------------------------------------------
+
+The ``memdep`` 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.
+
+.. _AliasSetTracker:
+
+Using the ``AliasSetTracker`` class
+-----------------------------------
+
+Many transformations need information about alias **sets** that are active in
+some scope, rather than information about pairwise aliasing.  The
+`AliasSetTracker <http://llvm.org/doxygen/classllvm_1_1AliasSetTracker.html>`__
+class is used to efficiently build these Alias Sets from the pairwise alias
+analysis information provided by the ``AliasAnalysis`` interface.
+
+First you initialize the AliasSetTracker by using the "``add``" 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 ``AliasSetTracker``
+``begin()``/``end()`` methods.
+
+The ``AliasSet``\s formed by the ``AliasSetTracker`` 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.
+
+As an example user of this, the `Loop Invariant Code Motion
+<doxygen/structLICM.html>`_ pass uses ``AliasSetTracker``\s to calculate alias
+sets for each loop nest.  If an ``AliasSet`` 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 **and** 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.
+
+The AliasSetTracker implementation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+The AliasSetTracker class must maintain a list of all of the LLVM ``Value*``\s
+that are in each AliasSet.  Since the hash table already has entries for each
+LLVM ``Value*`` 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).
+
+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.
+
+Using the ``AliasAnalysis`` interface directly
+----------------------------------------------
+
+If neither of these utility class are what your pass needs, you should use the
+interfaces exposed by the ``AliasAnalysis`` class directly.  Try to use the
+higher-level methods when possible (e.g., use mod/ref information instead of the
+`alias`_ method directly if possible) to get the best precision and efficiency.
+
+Existing alias analysis implementations and clients
+===================================================
+
+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 `the clients`_ that are useful for monitoring and evaluating different
+implementations.
+
+.. _various alias analysis implementations:
+
+Available ``AliasAnalysis`` implementations
+-------------------------------------------
+
+This section lists the various implementations of the ``AliasAnalysis``
+interface.  With the exception of the `-no-aa`_ implementation, all of these
+`chain`_ to other alias analysis implementations.
+
+.. _no-aa:
+.. _-no-aa:
+
+The ``-no-aa`` pass
+^^^^^^^^^^^^^^^^^^^
+
+The ``-no-aa`` 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.
+
+The ``-basicaa`` pass
+^^^^^^^^^^^^^^^^^^^^^
+
+The ``-basicaa`` pass is an aggressive local analysis that *knows* many
+important facts:
+
+* Distinct globals, stack allocations, and heap allocations can never alias.
+* Globals, stack allocations, and heap allocations never alias the null pointer.
+* Different fields of a structure do not alias.
+* Indexes into arrays with statically differing subscripts cannot alias.
+* Many common standard C library functions `never access memory or only read
+  memory`_.
+* Pointers that obviously point to constant globals "``pointToConstantMemory``".
+* 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).
+
+The ``-globalsmodref-aa`` pass
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+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.
+
+.. note::
+
+  This pass is somewhat limited in its scope (only support non-address taken
+  globals), but is very quick analysis.
+
+The ``-steens-aa`` pass
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``-steens-aa`` 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).
+
+The LLVM ``-steens-aa`` pass implements a "speculatively field-**sensitive**"
+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.
+
+.. note::
+
+  ``-steens-aa`` is available in the optional "poolalloc" module. It is not part
+  of the LLVM core.
+
+The ``-ds-aa`` pass
+^^^^^^^^^^^^^^^^^^^
+
+The ``-ds-aa`` pass implements the full Data Structure Analysis algorithm.  Data
+Structure Analysis is a modular unification-based, flow-insensitive,
+context-**sensitive**, and speculatively field-**sensitive** alias
+analysis that is also quite scalable, usually at ``O(n * log(n))``.
+
+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.
+
+.. note::
+
+  ``-ds-aa`` is available in the optional "poolalloc" module. It is not part of
+  the LLVM core.
+
+The ``-scev-aa`` pass
+^^^^^^^^^^^^^^^^^^^^^
+
+The ``-scev-aa`` pass implements AliasAnalysis queries by translating them into
+ScalarEvolution queries. This gives it a more complete understanding of
+``getelementptr`` instructions and loop induction variables than other alias
+analyses have.
+
+Alias analysis driven transformations
+-------------------------------------
+
+LLVM includes several alias-analysis driven transformations which can be used
+with any of the implementations above.
+
+The ``-adce`` pass
+^^^^^^^^^^^^^^^^^^
+
+The ``-adce`` pass, which implements Aggressive Dead Code Elimination uses the
+``AliasAnalysis`` interface to delete calls to functions that do not have
+side-effects and are not used.
+
+The ``-licm`` pass
+^^^^^^^^^^^^^^^^^^
+
+The ``-licm`` pass implements various Loop Invariant Code Motion related
+transformations.  It uses the ``AliasAnalysis`` interface for several different
+transformations:
+
+* 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.
+
+* It uses mod/ref information to hoist function calls out of loops that do not
+  write to memory and are loop-invariant.
+
+* If uses alias information to promote memory objects that are loaded and stored
+  to in loops to live in a register instead.  It can do this if there are no may
+  aliases to the loaded/stored memory location.
+
+The ``-argpromotion`` pass
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``-argpromotion`` 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.
+
+The ``-gvn``, ``-memcpyopt``, and ``-dse`` passes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These passes use AliasAnalysis information to reason about loads and stores.
+
+.. _the clients:
+
+Clients for debugging and evaluation of implementations
+-------------------------------------------------------
+
+These passes are useful for evaluating the various alias analysis
+implementations.  You can use them with commands like:
+
+.. code-block:: bash
+
+  % opt -ds-aa -aa-eval foo.bc -disable-output -stats
+
+The ``-print-alias-sets`` pass
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``-print-alias-sets`` pass is exposed as part of the ``opt`` tool to print
+out the Alias Sets formed by the `AliasSetTracker`_ class.  This is useful if
+you're using the ``AliasSetTracker`` class.  To use it, use something like:
+
+.. code-block:: bash
+
+  % opt -ds-aa -print-alias-sets -disable-output
+
+The ``-count-aa`` pass
+^^^^^^^^^^^^^^^^^^^^^^
+
+The ``-count-aa`` 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:
+
+.. code-block:: bash
+
+  % opt -basicaa -count-aa -ds-aa -count-aa -licm
+
+will print out how many queries (and what responses are returned) by the
+``-licm`` pass (of the ``-ds-aa`` pass) and how many queries are made of the
+``-basicaa`` pass by the ``-ds-aa`` pass.  This can be useful when debugging a
+transformation or an alias analysis implementation.
+
+The ``-aa-eval`` pass
+^^^^^^^^^^^^^^^^^^^^^
+
+The ``-aa-eval`` 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).
+
+Memory Dependence Analysis
+==========================
+
+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.

Added: www-releases/trunk/3.2/docs/Atomics.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/Atomics.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/Atomics.rst (added)
+++ www-releases/trunk/3.2/docs/Atomics.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,441 @@
+.. _atomics:
+
+==============================================
+LLVM Atomic Instructions and Concurrency Guide
+==============================================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+Historically, LLVM has not had very strong support for concurrency; some minimal
+intrinsics were provided, and ``volatile`` was used in some cases to achieve
+rough semantics in the presence of concurrency.  However, this is changing;
+there are now new instructions which are well-defined in the presence of threads
+and asynchronous signals, and the model for existing instructions has been
+clarified in the IR.
+
+The atomic instructions are designed specifically to provide readable IR and
+optimized code generation for the following:
+
+* The new C++0x ``<atomic>`` header.  (`C++0x draft available here
+  <http://www.open-std.org/jtc1/sc22/wg21/>`_.) (`C1x draft available here
+  <http://www.open-std.org/jtc1/sc22/wg14/>`_.)
+
+* Proper semantics for Java-style memory, for both ``volatile`` and regular
+  shared variables. (`Java Specification
+  <http://java.sun.com/docs/books/jls/third_edition/html/memory.html>`_)
+
+* gcc-compatible ``__sync_*`` builtins. (`Description
+  <http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html>`_)
+
+* Other scenarios with atomic semantics, including ``static`` variables with
+  non-trivial constructors in C++.
+
+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.
+
+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.
+
+.. _Optimization outside atomic:
+
+Optimization outside atomic
+===========================
+
+The basic ``'load'`` and ``'store'`` allow a variety of optimizations, but can
+lead to undefined results in a concurrent environment; see `NotAtomic`_. 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.
+
+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:
+
+.. code-block:: c
+
+ /* C code, for readability; run through clang -O2 -S -emit-llvm to get
+     equivalent IR */
+  int x;
+  void f(int* a) {
+    for (int i = 0; i < 100; i++) {
+      if (a[i])
+        x += 1;
+    }
+  }
+
+The following is equivalent in non-concurrent situations:
+
+.. code-block:: c
+
+  int x;
+  void f(int* a) {
+    int xtemp = x;
+    for (int i = 0; i < 100; i++) {
+      if (a[i])
+        xtemp += 1;
+    }
+    x = xtemp;
+  }
+
+However, LLVM is not allowed to transform the former to the latter: it could
+indirectly introduce undefined behavior if another thread can access ``x`` at
+the same time. (This example is particularly of interest because before the
+concurrency model was implemented, LLVM would perform this transformation.)
+
+Note that speculative loads are allowed; a load which is part of a race returns
+``undef``, but does not have undefined behavior.
+
+Atomic instructions
+===================
+
+For cases where simple loads and stores are not sufficient, LLVM provides
+various atomic instructions. The exact guarantees provided depend on the
+ordering; see `Atomic orderings`_.
+
+``load atomic`` and ``store atomic`` provide the same basic functionality as
+non-atomic loads and stores, but provide additional guarantees in situations
+where threads and signals are involved.
+
+``cmpxchg`` and ``atomicrmw`` are essentially like an atomic load followed by an
+atomic store (where the store is conditional for ``cmpxchg``), but no other
+memory operation can happen on any thread between the load and store.  Note that
+LLVM's cmpxchg does not provide quite as many options as the C++0x version.
+
+A ``fence`` 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.
+
+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.
+
+.. _Atomic orderings:
+
+Atomic orderings
+================
+
+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 `LangRef Ordering <LangRef.html#ordering>`_.)
+
+.. _NotAtomic:
+
+NotAtomic
+---------
+
+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.
+
+Relevant standard
+  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 `LangRef Memory Model <LangRef.html#memmodel>`_.)
+
+Notes for frontends
+  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.)
+
+Notes for optimizers
+  Introducing loads to shared variables along a codepath where they would not
+  otherwise exist is allowed; introducing stores to shared variables is not. See
+  `Optimization outside atomic`_.
+
+Notes for code generation
+  The one interesting restriction here is that it is not allowed to write to
+  bytes outside of the bytes relevant to a store.  This is mostly relevant to
+  unaligned stores: it is not allowed in general to convert an unaligned store
+  into two aligned stores of the same width as the unaligned store. Backends are
+  also expected to generate an i8 store as an i8 store, and not an instruction
+  which writes to surrounding bytes.  (If you are writing a backend for an
+  architecture which cannot satisfy these restrictions and cares about
+  concurrency, please send an email to llvmdev.)
+
+Unordered
+---------
+
+Unordered is the lowest level of atomicity. It essentially guarantees that races
+produce somewhat sane results instead of having undefined behavior.  It also
+guarantees the operation to be lock-free, so it do not depend on the data being
+part of a special atomic structure or depend on a separate per-process global
+lock.  Note that code generation will fail for unsupported atomic operations; if
+you need such an operation, use explicit locking.
+
+Relevant standard
+  This is intended to match the Java memory model for shared variables.
+
+Notes for frontends
+  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.)
+
+Notes for optimizers
+  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.
+
+Notes for code generation
+  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
+  ``LDRD`` on ARM).
+
+Monotonic
+---------
+
+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.
+
+Relevant standard
+  This corresponds to the C++0x/C1x ``memory_order_relaxed``; see those
+  standards for the exact definition.
+
+Notes for frontends
+  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 ``fence``.
+
+Notes for optimizers
+  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.
+
+Notes for code generation
+  Code generation is essentially the same as that for unordered for loads and
+  stores.  No fences are required.  ``cmpxchg`` and ``atomicrmw`` are required
+  to appear as a single operation.
+
+Acquire
+-------
+
+Acquire provides a barrier of the sort necessary to acquire a lock to access
+other memory with normal loads and stores.
+
+Relevant standard
+  This corresponds to the C++0x/C1x ``memory_order_acquire``. It should also be
+  used for C++0x/C1x ``memory_order_consume``.
+
+Notes for frontends
+  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.
+
+Notes for optimizers
+  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.
+
+Notes for code generation
+  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 (``dmb`` on ARM, ``sync`` on PowerPC, etc.).  Putting
+  such a fence after the equivalent Monotonic operation is sufficient to
+  maintain Acquire semantics for a memory operation.
+
+Release
+-------
+
+Release is similar to Acquire, but with a barrier of the sort necessary to
+release a lock.
+
+Relevant standard
+  This corresponds to the C++0x/C1x ``memory_order_release``.
+
+Notes for frontends
+  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.
+
+Notes for optimizers
+  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.
+
+Notes for code generation
+  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.
+
+AcquireRelease
+--------------
+
+AcquireRelease (``acq_rel`` in IR) provides both an Acquire and a Release
+barrier (for fences and operations which both read and write memory).
+
+Relevant standard
+  This corresponds to the C++0x/C1x ``memory_order_acq_rel``.
+
+Notes for frontends
+  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.
+
+Notes for optimizers
+  In general, optimizers should treat this like a nothrow call; the possible
+  optimizations are usually not interesting.
+
+Notes for code generation
+  This operation has Acquire and Release semantics; see the sections on Acquire
+  and Release.
+
+SequentiallyConsistent
+----------------------
+
+SequentiallyConsistent (``seq_cst`` in IR) provides Acquire semantics for loads
+and Release semantics for stores. Additionally, it guarantees that a total
+ordering exists between all SequentiallyConsistent operations.
+
+Relevant standard
+  This corresponds to the C++0x/C1x ``memory_order_seq_cst``, Java volatile, and
+  the gcc-compatible ``__sync_*`` builtins which do not specify otherwise.
+
+Notes for frontends
+  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.
+
+Notes for optimizers
+  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.
+
+Notes for code generation
+  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.
+
+Atomics and IR optimization
+===========================
+
+Predicates for optimizer writers to query:
+
+* ``isSimple()``: A load or store which is not volatile or atomic.  This is
+  what, for example, memcpyopt would check for operations it might transform.
+
+* ``isUnordered()``: A load or store which is not volatile and at most
+  Unordered. This would be checked, for example, by LICM before hoisting an
+  operation.
+
+* ``mayReadFromMemory()``/``mayWriteToMemory()``: Existing predicate, but note
+  that they return true for any operation which is volatile or at least
+  Monotonic.
+
+* Alias analysis: Note that AA will return ModRef for anything Acquire or
+  Release, and for the address accessed by any Monotonic operation.
+
+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.
+
+Some examples of how optimizations interact with various kinds of atomic
+operations:
+
+* ``memcpyopt``: An atomic operation cannot be optimized into part of a
+  memcpy/memset, including unordered loads/stores.  It can pull operations
+  across some atomic operations.
+
+* 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.
+
+* 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.
+
+* Folding a load: Any atomic load from a constant global can be constant-folded,
+  because it cannot be observed.  Similar reasoning allows scalarrepl with
+  atomic loads and stores.
+
+Atomics and Codegen
+===================
+
+Atomic operations are represented in the SelectionDAG with ``ATOMIC_*`` opcodes.
+On architectures which use barrier instructions for all atomic ordering (like
+ARM), appropriate fences are split out as the DAG is built.
+
+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.
+
+Common architectures have some way of representing at least a pointer-sized
+lock-free ``cmpxchg``; such an operation can be used to implement all the other
+atomic operations which can be represented in IR up to that size.  Backends are
+expected to implement all those operations, but not operations which cannot be
+implemented in a lock-free manner.  It is expected that backends will give an
+error when given an operation which cannot be implemented.  (The LLVM code
+generator is not very helpful here at the moment, but hopefully that will
+change.)
+
+The implementation of atomics on LL/SC architectures (like ARM) is currently a
+bit of a mess; there is a lot of copy-pasted code across targets, and the
+representation is relatively unsuited to optimization (it would be nice to be
+able to optimize loops involving cmpxchg etc.).
+
+On x86, all atomic loads generate a ``MOV``. SequentiallyConsistent stores
+generate an ``XCHG``, other stores generate a ``MOV``. SequentiallyConsistent
+fences generate an ``MFENCE``, other fences do not cause any code to be
+generated.  cmpxchg uses the ``LOCK CMPXCHG`` instruction.  ``atomicrmw xchg``
+uses ``XCHG``, ``atomicrmw add`` and ``atomicrmw sub`` use ``XADD``, and all
+other ``atomicrmw`` operations generate a loop with ``LOCK CMPXCHG``.  Depending
+on the users of the result, some ``atomicrmw`` operations can be translated into
+operations like ``LOCK AND``, but that does not work in general.
+
+On ARM, MIPS, and many other RISC architectures, Acquire, Release, and
+SequentiallyConsistent semantics require barrier instructions for every such
+operation. Loads and stores generate normal instructions.  ``cmpxchg`` and
+``atomicrmw`` can be represented using a loop with LL/SC-style instructions
+which take some sort of exclusive lock on a cache line (``LDREX`` and ``STREX``
+on ARM, etc.). At the moment, the IR does not provide any way to represent a
+weak ``cmpxchg`` which would not require a loop.

Added: www-releases/trunk/3.2/docs/BitCodeFormat.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/BitCodeFormat.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/BitCodeFormat.rst (added)
+++ www-releases/trunk/3.2/docs/BitCodeFormat.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,1092 @@
+.. _bitcode_format:
+
+.. role:: raw-html(raw)
+   :format: html
+
+========================
+LLVM Bitcode File Format
+========================
+
+.. contents::
+   :local:
+
+Abstract
+========
+
+This document describes the LLVM bitstream file format and the encoding of the
+LLVM IR into it.
+
+Overview
+========
+
+What is commonly known as the LLVM bitcode file format (also, sometimes
+anachronistically known as bytecode) is actually two things: a `bitstream
+container format`_ and an `encoding of LLVM IR`_ into the container format.
+
+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.
+
+LLVM IR files may be optionally embedded into a `wrapper`_ structure that makes
+it easy to embed extra data along with LLVM IR files.
+
+This document first describes the LLVM bitstream format, describes the wrapper
+format, then describes the record structure used by LLVM IR files.
+
+.. _bitstream container format:
+
+Bitstream Format
+================
+
+The bitstream format is literally a stream of bits, with a very simple
+structure.  This structure consists of the following concepts:
+
+* A "`magic number`_" that identifies the contents of the stream.
+
+* Encoding `primitives`_ like variable bit-rate integers.
+
+* `Blocks`_, which define nested content.
+
+* `Data Records`_, which describe entities within the file.
+
+* Abbreviations, which specify compression optimizations for the file.
+
+Note that the `llvm-bcanalyzer <CommandGuide/html/llvm-bcanalyzer.html>`_ tool
+can be used to dump and inspect arbitrary bitstreams, which is very useful for
+understanding the encoding.
+
+.. _magic number:
+
+Magic Numbers
+-------------
+
+The first two bytes of a bitcode file are 'BC' (``0x42``, ``0x43``).  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.
+
+.. _primitives:
+
+Primitives
+----------
+
+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 `Fixed Width Integers`_ or as
+`Variable Width Integers`_.
+
+.. _Fixed Width Integers:
+.. _fixed-width value:
+
+Fixed Width Integers
+^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+.. _Variable Width Integers:
+.. _Variable Width Integer:
+.. _variable-width value:
+
+Variable Width Integers
+^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+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.
+
+.. _char6-encoded value:
+
+6-bit characters
+^^^^^^^^^^^^^^^^
+
+6-bit characters encode common characters into a fixed 6-bit field.  They
+represent the following characters with the following 6-bit values:
+
+::
+
+  'a' .. 'z' ---  0 .. 25
+  'A' .. 'Z' --- 26 .. 51
+  '0' .. '9' --- 52 .. 61
+         '.' --- 62
+         '_' --- 63
+
+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.
+
+Word Alignment
+^^^^^^^^^^^^^^
+
+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.
+
+Abbreviation IDs
+----------------
+
+A bitstream is a sequential series of `Blocks`_ and `Data Records`_.  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.
+
+The set of builtin abbrev IDs is:
+
+* 0 - `END_BLOCK`_ --- This abbrev ID marks the end of the current block.
+
+* 1 - `ENTER_SUBBLOCK`_ --- This abbrev ID marks the beginning of a new
+  block.
+
+* 2 - `DEFINE_ABBREV`_ --- This defines a new abbreviation.
+
+* 3 - `UNABBREV_RECORD`_ --- This ID specifies the definition of an
+  unabbreviated record.
+
+Abbreviation IDs 4 and above are defined by the stream itself, and specify an
+`abbreviated record encoding`_.
+
+.. _Blocks:
+
+Blocks
+------
+
+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 `standard blocks`_ 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.
+
+When reading and encoding the stream, several properties are maintained for the
+block.  In particular, each block maintains:
+
+#. 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.
+
+#. 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 `BLOCKINFO`_ block, in which case they are defined in all blocks
+   that match the ID that the ``BLOCKINFO`` block is describing.
+
+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.
+
+.. _ENTER_SUBBLOCK:
+
+ENTER_SUBBLOCK Encoding
+^^^^^^^^^^^^^^^^^^^^^^^
+
+:raw-html:`<tt>`
+[ENTER_SUBBLOCK, blockid\ :sub:`vbr8`, newabbrevlen\ :sub:`vbr4`, <align32bits>, blocklen_32]
+:raw-html:`</tt>`
+
+The ``ENTER_SUBBLOCK`` abbreviation ID specifies the start of a new block
+record.  The ``blockid`` value is encoded as an 8-bit VBR identifier, and
+indicates the type of block being entered, which can be a `standard block`_ or
+an application-specific block.  The ``newabbrevlen`` value is a 4-bit VBR, which
+specifies the abbrev id width for the sub-block.  The ``blocklen`` 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.
+
+.. _END_BLOCK:
+
+END_BLOCK Encoding
+^^^^^^^^^^^^^^^^^^
+
+``[END_BLOCK, <align32bits>]``
+
+The ``END_BLOCK`` 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.
+
+.. _Data Records:
+
+Data Records
+------------
+
+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
+``MODULE_CODE_TRIPLE``, and the values of the record are the ASCII codes for the
+characters in the string.
+
+.. _UNABBREV_RECORD:
+
+UNABBREV_RECORD Encoding
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+:raw-html:`<tt>`
+[UNABBREV_RECORD, code\ :sub:`vbr6`, numops\ :sub:`vbr6`, op0\ :sub:`vbr6`, op1\ :sub:`vbr6`, ...]
+:raw-html:`</tt>`
+
+An ``UNABBREV_RECORD`` 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.
+
+For example, emitting an LLVM IR target triple as an unabbreviated record
+requires emitting the ``UNABBREV_RECORD`` abbrevid, a vbr6 for the
+``MODULE_CODE_TRIPLE`` 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.
+
+.. _abbreviated record encoding:
+
+Abbreviated Record Encoding
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[<abbrevid>, fields...]``
+
+An abbreviated record is a abbreviation id followed by a set of fields that are
+encoded according to the `abbreviation definition`_.  This allows records to be
+encoded significantly more densely than records encoded with the
+`UNABBREV_RECORD`_ 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.
+
+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).
+
+.. _abbreviation definition:
+
+Abbreviations
+-------------
+
+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.
+
+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.
+
+.. _DEFINE_ABBREV:
+
+DEFINE_ABBREV Encoding
+^^^^^^^^^^^^^^^^^^^^^^
+
+:raw-html:`<tt>`
+[DEFINE_ABBREV, numabbrevops\ :sub:`vbr5`, abbrevop0, abbrevop1, ...]
+:raw-html:`</tt>`
+
+A ``DEFINE_ABBREV`` 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
+``BLOCKINFO`` 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.
+
+An abbreviation definition consists of the ``DEFINE_ABBREV`` 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).
+
+#. Literal operands --- :raw-html:`<tt>` [1\ :sub:`1`, litvalue\
+   :sub:`vbr8`] :raw-html:`</tt>` --- 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.
+
+#. Encoding info without data --- :raw-html:`<tt>` [0\ :sub:`1`, encoding\
+   :sub:`3`] :raw-html:`</tt>` --- Operand encodings that do not have extra data
+   are just emitted as their code.
+
+#. Encoding info with data --- :raw-html:`<tt>` [0\ :sub:`1`, encoding\
+   :sub:`3`, value\ :sub:`vbr5`] :raw-html:`</tt>` --- Operand encodings that do
+   have extra data are emitted as their code, followed by the extra data.
+
+The possible operand encodings are:
+
+* Fixed (code 1): The field should be emitted as a `fixed-width value`_, whose
+  width is specified by the operand's extra data.
+
+* VBR (code 2): The field should be emitted as a `variable-width value`_, whose
+  width is specified by the operand's extra data.
+
+* 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).
+
+* Char6 (code 4): This field should be emitted as a `char6-encoded value`_.
+  This operand type takes no extra data. Char6 encoding is normally used as an
+  array element type.
+
+* 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.
+
+For example, target triples in LLVM modules are encoded as a record of the form
+``[TRIPLE, 'a', 'b', 'c', 'd']``.  Consider if the bitstream emitted the
+following abbrev entry:
+
+::
+
+  [0, Fixed, 4]
+  [0, Array]
+  [0, Char6]
+
+When emitting a record with this abbreviation, the above entry would be emitted
+as:
+
+:raw-html:`<tt><blockquote>`
+[4\ :sub:`abbrevwidth`, 2\ :sub:`4`, 4\ :sub:`vbr6`, 0\ :sub:`6`, 1\ :sub:`6`, 2\ :sub:`6`, 3\ :sub:`6`]
+:raw-html:`</blockquote></tt>`
+
+These values are:
+
+#. The first value, 4, is the abbreviation ID for this abbreviation.
+
+#. The second value, 2, is the record code for ``TRIPLE`` records within LLVM IR
+   file ``MODULE_BLOCK`` blocks.
+
+#. The third value, 4, is the length of the array.
+
+#. The rest of the values are the char6 encoded values for ``"abcd"``.
+
+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 ``TRIPLE`` value is
+not emitted as a literal in the abbreviation, the abbreviation can also be used
+for any other string value.
+
+.. _standard blocks:
+.. _standard block:
+
+Standard Blocks
+---------------
+
+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.
+
+.. _BLOCKINFO:
+
+#0 - BLOCKINFO Block
+^^^^^^^^^^^^^^^^^^^^
+
+The ``BLOCKINFO`` block allows the description of metadata for other blocks.
+The currently specified records are:
+
+::
+
+  [SETBID (#1), blockid]
+  [DEFINE_ABBREV, ...]
+  [BLOCKNAME, ...name...]
+  [SETRECORDNAME, RecordID, ...name...]
+
+The ``SETBID`` record (code 1) indicates which block ID is being described.
+``SETBID`` records can occur multiple times throughout the block to change which
+block ID is being described.  There must be a ``SETBID`` record prior to any
+other records.
+
+Standard ``DEFINE_ABBREV`` records can occur inside ``BLOCKINFO`` blocks, but
+unlike their occurrence in normal blocks, the abbreviation is defined for blocks
+matching the block ID we are describing, *not* the ``BLOCKINFO`` block
+itself.  The abbreviations defined in ``BLOCKINFO`` blocks receive abbreviation
+IDs as described in `DEFINE_ABBREV`_.
+
+The ``BLOCKNAME`` 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.
+
+The ``SETRECORDNAME`` 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.
+
+Note that although the data in ``BLOCKINFO`` 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.
+
+.. _wrapper:
+
+Bitcode Wrapper Format
+======================
+
+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:
+
+:raw-html:`<tt><blockquote>`
+[Magic\ :sub:`32`, Version\ :sub:`32`, Offset\ :sub:`32`, Size\ :sub:`32`, CPUType\ :sub:`32`]
+:raw-html:`</blockquote></tt>`
+
+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 ``0x0B17C0DE`` and
+the version is currently always ``0``.  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.
+
+.. _encoding of LLVM IR:
+
+LLVM IR Encoding
+================
+
+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.
+
+Basics
+------
+
+LLVM IR Magic Number
+^^^^^^^^^^^^^^^^^^^^
+
+The magic number for LLVM IR files is:
+
+:raw-html:`<tt><blockquote>`
+[0x0\ :sub:`4`, 0xC\ :sub:`4`, 0xE\ :sub:`4`, 0xD\ :sub:`4`]
+:raw-html:`</blockquote></tt>`
+
+When combined with the bitcode magic number and viewed as bytes, this is
+``"BC 0xC0DE"``.
+
+.. _Signed VBRs:
+
+Signed VBRs
+^^^^^^^^^^^
+
+`Variable Width Integer`_ 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.
+
+As such, signed VBR values of a specific width are emitted as follows:
+
+* Positive values are emitted as VBRs of the specified width, but with their
+  value shifted left by one.
+
+* 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.
+
+With this encoding, small positive and small negative values can both be emitted
+efficiently. Signed VBR encoding is used in ``CST_CODE_INTEGER`` and
+``CST_CODE_WIDE_INTEGER`` records within ``CONSTANTS_BLOCK`` blocks.
+It is also used for phi instruction operands in `MODULE_CODE_VERSION`_ 1.
+
+LLVM IR Blocks
+^^^^^^^^^^^^^^
+
+LLVM IR is defined with the following blocks:
+
+* 8 --- `MODULE_BLOCK`_ --- This is the top-level block that contains the entire
+  module, and describes a variety of per-module information.
+
+* 9 --- `PARAMATTR_BLOCK`_ --- This enumerates the parameter attributes.
+
+* 10 --- `TYPE_BLOCK`_ --- This describes all of the types in the module.
+
+* 11 --- `CONSTANTS_BLOCK`_ --- This describes constants for a module or
+  function.
+
+* 12 --- `FUNCTION_BLOCK`_ --- This describes a function body.
+
+* 13 --- `TYPE_SYMTAB_BLOCK`_ --- This describes the type symbol table.
+
+* 14 --- `VALUE_SYMTAB_BLOCK`_ --- This describes a value symbol table.
+
+* 15 --- `METADATA_BLOCK`_ --- This describes metadata items.
+
+* 16 --- `METADATA_ATTACHMENT`_ --- This contains records associating metadata
+  with function instruction values.
+
+.. _MODULE_BLOCK:
+
+MODULE_BLOCK Contents
+---------------------
+
+The ``MODULE_BLOCK`` 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 ``MODULE_BLOCK``
+block may contain the following sub-blocks:
+
+* `BLOCKINFO`_
+* `PARAMATTR_BLOCK`_
+* `TYPE_BLOCK`_
+* `TYPE_SYMTAB_BLOCK`_
+* `VALUE_SYMTAB_BLOCK`_
+* `CONSTANTS_BLOCK`_
+* `FUNCTION_BLOCK`_
+* `METADATA_BLOCK`_
+
+.. _MODULE_CODE_VERSION:
+
+MODULE_CODE_VERSION Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[VERSION, version#]``
+
+The ``VERSION`` 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 `FUNCTION_BLOCK`_.
+
+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
+``NumModuleValues`` 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.
+
+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.
+
+For example, instead of
+
+.. code-block:: llvm
+
+  #n = load #n-1
+  #n+1 = icmp eq #n, #const0
+  br #n+1, label #(bb1), label #(bb2)
+
+version 1 will encode the instructions as
+
+.. code-block:: llvm
+
+  #n = load #1
+  #n+1 = icmp eq #1, (#n+1)-#const0
+  br #1, label #(bb1), label #(bb2)
+
+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.
+
+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
+`Signed VBRs`_ to deal with forward references.
+
+
+MODULE_CODE_TRIPLE Record
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[TRIPLE, ...string...]``
+
+The ``TRIPLE`` record (code 2) contains a variable number of values representing
+the bytes of the ``target triple`` specification string.
+
+MODULE_CODE_DATALAYOUT Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[DATALAYOUT, ...string...]``
+
+The ``DATALAYOUT`` record (code 3) contains a variable number of values
+representing the bytes of the ``target datalayout`` specification string.
+
+MODULE_CODE_ASM Record
+^^^^^^^^^^^^^^^^^^^^^^
+
+``[ASM, ...string...]``
+
+The ``ASM`` record (code 4) contains a variable number of values representing
+the bytes of ``module asm`` strings, with individual assembly blocks separated
+by newline (ASCII 10) characters.
+
+.. _MODULE_CODE_SECTIONNAME:
+
+MODULE_CODE_SECTIONNAME Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[SECTIONNAME, ...string...]``
+
+The ``SECTIONNAME`` record (code 5) contains a variable number of values
+representing the bytes of a single section name string. There should be one
+``SECTIONNAME`` record for each section name referenced (e.g., in global
+variable or function ``section`` attributes) within the module. These records
+can be referenced by the 1-based index in the *section* fields of ``GLOBALVAR``
+or ``FUNCTION`` records.
+
+MODULE_CODE_DEPLIB Record
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[DEPLIB, ...string...]``
+
+The ``DEPLIB`` 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 ``deplibs`` declaration.  There should be one ``DEPLIB`` record
+for each library name referenced.
+
+MODULE_CODE_GLOBALVAR Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr]``
+
+The ``GLOBALVAR`` record (code 7) marks the declaration or definition of a
+global variable. The operand fields are:
+
+* *pointer type*: The type index of the pointer type used to point to this
+  global variable
+
+* *isconst*: Non-zero if the variable is treated as constant within the module,
+  or zero if it is not
+
+* *initid*: If non-zero, the value index of the initializer for this variable,
+  plus 1.
+
+.. _linkage type:
+
+* *linkage*: An encoding of the linkage type for this variable:
+  * ``external``: code 0
+  * ``weak``: code 1
+  * ``appending``: code 2
+  * ``internal``: code 3
+  * ``linkonce``: code 4
+  * ``dllimport``: code 5
+  * ``dllexport``: code 6
+  * ``extern_weak``: code 7
+  * ``common``: code 8
+  * ``private``: code 9
+  * ``weak_odr``: code 10
+  * ``linkonce_odr``: code 11
+  * ``available_externally``: code 12
+  * ``linker_private``: code 13
+
+* alignment*: The logarithm base 2 of the variable's requested alignment, plus 1
+
+* *section*: If non-zero, the 1-based section index in the table of
+  `MODULE_CODE_SECTIONNAME`_ entries.
+
+.. _visibility:
+
+* *visibility*: If present, an encoding of the visibility of this variable:
+  * ``default``: code 0
+  * ``hidden``: code 1
+  * ``protected``: code 2
+
+* *threadlocal*: If present, an encoding of the thread local storage mode of the
+  variable:
+  * ``not thread local``: code 0
+  * ``thread local; default TLS model``: code 1
+  * ``localdynamic``: code 2
+  * ``initialexec``: code 3
+  * ``localexec``: code 4
+
+* *unnamed_addr*: If present and non-zero, indicates that the variable has
+  ``unnamed_addr``
+
+.. _FUNCTION:
+
+MODULE_CODE_FUNCTION Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]``
+
+The ``FUNCTION`` record (code 8) marks the declaration or definition of a
+function. The operand fields are:
+
+* *type*: The type index of the function type describing this function
+
+* *callingconv*: The calling convention number:
+  * ``ccc``: code 0
+  * ``fastcc``: code 8
+  * ``coldcc``: code 9
+  * ``x86_stdcallcc``: code 64
+  * ``x86_fastcallcc``: code 65
+  * ``arm_apcscc``: code 66
+  * ``arm_aapcscc``: code 67
+  * ``arm_aapcs_vfpcc``: code 68
+
+* isproto*: Non-zero if this entry represents a declaration rather than a
+  definition
+
+* *linkage*: An encoding of the `linkage type`_ for this function
+
+* *paramattr*: If nonzero, the 1-based parameter attribute index into the table
+  of `PARAMATTR_CODE_ENTRY`_ entries.
+
+* *alignment*: The logarithm base 2 of the function's requested alignment, plus
+  1
+
+* *section*: If non-zero, the 1-based section index in the table of
+  `MODULE_CODE_SECTIONNAME`_ entries.
+
+* *visibility*: An encoding of the `visibility`_ of this function
+
+* *gc*: If present and nonzero, the 1-based garbage collector index in the table
+  of `MODULE_CODE_GCNAME`_ entries.
+
+* *unnamed_addr*: If present and non-zero, indicates that the function has
+  ``unnamed_addr``
+
+MODULE_CODE_ALIAS Record
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[ALIAS, alias type, aliasee val#, linkage, visibility]``
+
+The ``ALIAS`` record (code 9) marks the definition of an alias. The operand
+fields are
+
+* *alias type*: The type index of the alias
+
+* *aliasee val#*: The value index of the aliased value
+
+* *linkage*: An encoding of the `linkage type`_ for this alias
+
+* *visibility*: If present, an encoding of the `visibility`_ of the alias
+
+MODULE_CODE_PURGEVALS Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[PURGEVALS, numvals]``
+
+The ``PURGEVALS`` 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 ``GLOBALVAR``, ``FUNCTION``, and ``ALIAS`` records.  After a ``PURGEVALS``
+record is seen, new value indices will start from the given *numvals* value.
+
+.. _MODULE_CODE_GCNAME:
+
+MODULE_CODE_GCNAME Record
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[GCNAME, ...string...]``
+
+The ``GCNAME`` record (code 11) contains a variable number of values
+representing the bytes of a single garbage collector name string. There should
+be one ``GCNAME`` record for each garbage collector name referenced in function
+``gc`` attributes within the module. These records can be referenced by 1-based
+index in the *gc* fields of ``FUNCTION`` records.
+
+.. _PARAMATTR_BLOCK:
+
+PARAMATTR_BLOCK Contents
+------------------------
+
+The ``PARAMATTR_BLOCK`` block (id 9) contains a table of entries describing the
+attributes of function parameters. These entries are referenced by 1-based index
+in the *paramattr* field of module block `FUNCTION`_ records, or within the
+*attr* field of function block ``INST_INVOKE`` and ``INST_CALL`` records.
+
+Entries within ``PARAMATTR_BLOCK`` are constructed to ensure that each is unique
+(i.e., no two indicies represent equivalent attribute lists).
+
+.. _PARAMATTR_CODE_ENTRY:
+
+PARAMATTR_CODE_ENTRY Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[ENTRY, paramidx0, attr0, paramidx1, attr1...]``
+
+The ``ENTRY`` record (code 1) contains an even number of values describing a
+unique set of function parameter attributes. Each *paramidx* 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 *attr* value is a bitmap with the
+following interpretation:
+
+* bit 0: ``zeroext``
+* bit 1: ``signext``
+* bit 2: ``noreturn``
+* bit 3: ``inreg``
+* bit 4: ``sret``
+* bit 5: ``nounwind``
+* bit 6: ``noalias``
+* bit 7: ``byval``
+* bit 8: ``nest``
+* bit 9: ``readnone``
+* bit 10: ``readonly``
+* bit 11: ``noinline``
+* bit 12: ``alwaysinline``
+* bit 13: ``optsize``
+* bit 14: ``ssp``
+* bit 15: ``sspreq``
+* bits 16-31: ``align n``
+* bit 32: ``nocapture``
+* bit 33: ``noredzone``
+* bit 34: ``noimplicitfloat``
+* bit 35: ``naked``
+* bit 36: ``inlinehint``
+* bits 37-39: ``alignstack n``, represented as the logarithm
+  base 2 of the requested alignment, plus 1
+
+.. _TYPE_BLOCK:
+
+TYPE_BLOCK Contents
+-------------------
+
+The ``TYPE_BLOCK`` 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 `NUMENTRY`_) 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.
+
+Entries within ``TYPE_BLOCK`` are constructed to ensure that each entry is
+unique (i.e., no two indicies represent structurally equivalent types).
+
+.. _TYPE_CODE_NUMENTRY:
+.. _NUMENTRY:
+
+TYPE_CODE_NUMENTRY Record
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[NUMENTRY, numentries]``
+
+The ``NUMENTRY`` 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,
+``NUMENTRY`` should be the first record in the block.
+
+TYPE_CODE_VOID Record
+^^^^^^^^^^^^^^^^^^^^^
+
+``[VOID]``
+
+The ``VOID`` record (code 2) adds a ``void`` type to the type table.
+
+TYPE_CODE_HALF Record
+^^^^^^^^^^^^^^^^^^^^^
+
+``[HALF]``
+
+The ``HALF`` record (code 10) adds a ``half`` (16-bit floating point) type to
+the type table.
+
+TYPE_CODE_FLOAT Record
+^^^^^^^^^^^^^^^^^^^^^^
+
+``[FLOAT]``
+
+The ``FLOAT`` record (code 3) adds a ``float`` (32-bit floating point) type to
+the type table.
+
+TYPE_CODE_DOUBLE Record
+^^^^^^^^^^^^^^^^^^^^^^^
+
+``[DOUBLE]``
+
+The ``DOUBLE`` record (code 4) adds a ``double`` (64-bit floating point) type to
+the type table.
+
+TYPE_CODE_LABEL Record
+^^^^^^^^^^^^^^^^^^^^^^
+
+``[LABEL]``
+
+The ``LABEL`` record (code 5) adds a ``label`` type to the type table.
+
+TYPE_CODE_OPAQUE Record
+^^^^^^^^^^^^^^^^^^^^^^^
+
+``[OPAQUE]``
+
+The ``OPAQUE`` record (code 6) adds an ``opaque`` type to the type table. Note
+that distinct ``opaque`` types are not unified.
+
+TYPE_CODE_INTEGER Record
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[INTEGER, width]``
+
+The ``INTEGER`` record (code 7) adds an integer type to the type table. The
+single *width* field indicates the width of the integer type.
+
+TYPE_CODE_POINTER Record
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[POINTER, pointee type, address space]``
+
+The ``POINTER`` record (code 8) adds a pointer type to the type table. The
+operand fields are
+
+* *pointee type*: The type index of the pointed-to type
+
+* *address space*: If supplied, the target-specific numbered address space where
+  the pointed-to object resides. Otherwise, the default address space is zero.
+
+TYPE_CODE_FUNCTION Record
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[FUNCTION, vararg, ignored, retty, ...paramty... ]``
+
+The ``FUNCTION`` record (code 9) adds a function type to the type table. The
+operand fields are
+
+* *vararg*: Non-zero if the type represents a varargs function
+
+* *ignored*: This value field is present for backward compatibility only, and is
+  ignored
+
+* *retty*: The type index of the function's return type
+
+* *paramty*: Zero or more type indices representing the parameter types of the
+  function
+
+TYPE_CODE_STRUCT Record
+^^^^^^^^^^^^^^^^^^^^^^^
+
+``[STRUCT, ispacked, ...eltty...]``
+
+The ``STRUCT`` record (code 10) adds a struct type to the type table. The
+operand fields are
+
+* *ispacked*: Non-zero if the type represents a packed structure
+
+* *eltty*: Zero or more type indices representing the element types of the
+  structure
+
+TYPE_CODE_ARRAY Record
+^^^^^^^^^^^^^^^^^^^^^^
+
+``[ARRAY, numelts, eltty]``
+
+The ``ARRAY`` record (code 11) adds an array type to the type table.  The
+operand fields are
+
+* *numelts*: The number of elements in arrays of this type
+
+* *eltty*: The type index of the array element type
+
+TYPE_CODE_VECTOR Record
+^^^^^^^^^^^^^^^^^^^^^^^
+
+``[VECTOR, numelts, eltty]``
+
+The ``VECTOR`` record (code 12) adds a vector type to the type table.  The
+operand fields are
+
+* *numelts*: The number of elements in vectors of this type
+
+* *eltty*: The type index of the vector element type
+
+TYPE_CODE_X86_FP80 Record
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[X86_FP80]``
+
+The ``X86_FP80`` record (code 13) adds an ``x86_fp80`` (80-bit floating point)
+type to the type table.
+
+TYPE_CODE_FP128 Record
+^^^^^^^^^^^^^^^^^^^^^^
+
+``[FP128]``
+
+The ``FP128`` record (code 14) adds an ``fp128`` (128-bit floating point) type
+to the type table.
+
+TYPE_CODE_PPC_FP128 Record
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[PPC_FP128]``
+
+The ``PPC_FP128`` record (code 15) adds a ``ppc_fp128`` (128-bit floating point)
+type to the type table.
+
+TYPE_CODE_METADATA Record
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``[METADATA]``
+
+The ``METADATA`` record (code 16) adds a ``metadata`` type to the type table.
+
+.. _CONSTANTS_BLOCK:
+
+CONSTANTS_BLOCK Contents
+------------------------
+
+The ``CONSTANTS_BLOCK`` block (id 11) ...
+
+.. _FUNCTION_BLOCK:
+
+FUNCTION_BLOCK Contents
+-----------------------
+
+The ``FUNCTION_BLOCK`` block (id 12) ...
+
+In addition to the record types described below, a ``FUNCTION_BLOCK`` block may
+contain the following sub-blocks:
+
+* `CONSTANTS_BLOCK`_
+* `VALUE_SYMTAB_BLOCK`_
+* `METADATA_ATTACHMENT`_
+
+.. _TYPE_SYMTAB_BLOCK:
+
+TYPE_SYMTAB_BLOCK Contents
+--------------------------
+
+The ``TYPE_SYMTAB_BLOCK`` block (id 13) contains entries which map between
+module-level named types and their corresponding type indices.
+
+.. _TST_CODE_ENTRY:
+
+TST_CODE_ENTRY Record
+^^^^^^^^^^^^^^^^^^^^^
+
+``[ENTRY, typeid, ...string...]``
+
+The ``ENTRY`` 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.
+
+.. _VALUE_SYMTAB_BLOCK:
+
+VALUE_SYMTAB_BLOCK Contents
+---------------------------
+
+The ``VALUE_SYMTAB_BLOCK`` block (id 14) ... 
+
+.. _METADATA_BLOCK:
+
+METADATA_BLOCK Contents
+-----------------------
+
+The ``METADATA_BLOCK`` block (id 15) ...
+
+.. _METADATA_ATTACHMENT:
+
+METADATA_ATTACHMENT Contents
+----------------------------
+
+The ``METADATA_ATTACHMENT`` block (id 16) ...

Added: www-releases/trunk/3.2/docs/BranchWeightMetadata.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/BranchWeightMetadata.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/BranchWeightMetadata.rst (added)
+++ www-releases/trunk/3.2/docs/BranchWeightMetadata.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,118 @@
+.. _branch_weight:
+
+===========================
+LLVM Branch Weight Metadata
+===========================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+Branch Weight Metadata represents branch weights as its likeliness to be
+taken. Metadata is assigned to the ``TerminatorInst`` as a ``MDNode`` of the
+``MD_prof`` kind. The first operator is always a ``MDString`` node with the
+string "branch_weights". Number of operators depends on the terminator type.
+
+Branch weights might be fetch from the profiling file, or generated based on
+`__builtin_expect`_ instruction.
+
+All weights are represented as an unsigned 32-bit values, where higher value
+indicates greater chance to be taken.
+
+Supported Instructions
+======================
+
+``BranchInst``
+^^^^^^^^^^^^^^
+
+Metadata is only assign to the conditional branches. There are two extra
+operarands, for the true and the false branch.
+
+.. code-block:: llvm
+
+  !0 = metadata !{
+    metadata !"branch_weights",
+    i32 <TRUE_BRANCH_WEIGHT>,
+    i32 <FALSE_BRANCH_WEIGHT>
+  }
+
+``SwitchInst``
+^^^^^^^^^^^^^^
+
+Branch weights are assign to every case (including ``default`` case which is
+always case #0).
+
+.. code-block:: llvm
+
+  !0 = metadata !{
+    metadata !"branch_weights",
+    i32 <DEFAULT_BRANCH_WEIGHT>
+    [ , i32 <CASE_BRANCH_WEIGHT> ... ]
+  }
+
+``IndirectBrInst``
+^^^^^^^^^^^^^^^^^^
+
+Branch weights are assign to every destination.
+
+.. code-block:: llvm
+
+  !0 = metadata !{
+    metadata !"branch_weights",
+    i32 <LABEL_BRANCH_WEIGHT>
+    [ , i32 <LABEL_BRANCH_WEIGHT> ... ]
+  }
+
+Other
+^^^^^
+
+Other terminator instructions are not allowed to contain Branch Weight Metadata.
+
+.. _\__builtin_expect:
+
+Built-in ``expect`` Instructions
+================================
+
+``__builtin_expect(long exp, long c)`` instruction provides branch prediction
+information. The return value is the value of ``exp``.
+
+It is especially useful in conditional statements. Currently Clang supports two
+conditional statements:
+
+``if`` statement
+^^^^^^^^^^^^^^^^
+
+The ``exp`` parameter is the condition. The ``c`` 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:
+
+.. code-block:: c++
+
+  if (__builtin_expect(x > 0, 1)) {
+    // This block is likely to be taken.
+  }
+
+``switch`` statement
+^^^^^^^^^^^^^^^^^^^^
+
+The ``exp`` parameter is the value. The ``c`` parameter is the expected
+value. If the expected value doesn't show on the cases list, the ``default``
+case is assumed to be likely taken.
+
+.. code-block:: c++
+
+  switch (__builtin_expect(x, 5)) {
+  default: break;
+  case 0:  // ...
+  case 3:  // ...
+  case 5:  // This case is likely to be taken.
+  }
+
+CFG Modifications
+=================
+
+Branch Weight Metatada is not proof against CFG changes. If terminator operands'
+are changed some action should be taken. In other case some misoptimizations may
+occur due to incorrent branch prediction information.

Added: www-releases/trunk/3.2/docs/Bugpoint.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/Bugpoint.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/Bugpoint.rst (added)
+++ www-releases/trunk/3.2/docs/Bugpoint.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,218 @@
+.. _bugpoint:
+
+====================================
+LLVM bugpoint tool: design and usage
+====================================
+
+.. contents::
+   :local:
+
+Description
+===========
+
+``bugpoint`` 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 ``opt`` 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.
+
+For detailed case scenarios, such as debugging ``opt``, or one of the LLVM code
+generators, see `How To Submit a Bug Report document <HowToSubmitABug.html>`_.
+
+Design Philosophy
+=================
+
+``bugpoint`` 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.  ``bugpoint`` 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 ``bugpoint`` is generally very quick unless debugging a miscompilation
+where each test of the program (which requires executing it) takes a long time.
+
+Automatic Debugger Selection
+----------------------------
+
+``bugpoint`` reads each ``.bc`` or ``.ll`` 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), ``bugpoint`` starts the `crash debugger`_.
+
+Otherwise, if the ``-output`` option was not specified, ``bugpoint`` runs the
+test program with the "safe" backend (which is assumed to generate good code) to
+generate a reference output.  Once ``bugpoint`` has a reference output for the
+test program, it tries executing it with the selected code generator.  If the
+selected code generator crashes, ``bugpoint`` starts the `crash debugger`_ 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 `code generator debugger`_.
+
+Finally, if the output of the selected code generator matches the reference
+output, ``bugpoint`` 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
+`miscompilation debugger`_.  Otherwise, there is no problem ``bugpoint`` can
+debug.
+
+.. _crash debugger:
+
+Crash debugger
+--------------
+
+If an optimizer or code generator crashes, ``bugpoint`` will try as hard as it
+can to reduce the list of passes (for optimizer crashes) and the size of the
+test program.  First, ``bugpoint`` figures out which combination of optimizer
+passes triggers the bug. This is useful when debugging a problem exposed by
+``opt``, for example, because it runs over 38 passes.
+
+Next, ``bugpoint`` 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, ``bugpoint``
+deletes any individual LLVM instructions whose absence does not eliminate the
+failure.  At the end, ``bugpoint`` should tell you what passes crash, give you a
+bitcode file, and give you instructions on how to reproduce the failure with
+``opt`` or ``llc``.
+
+.. _code generator debugger:
+
+Code generator debugger
+-----------------------
+
+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.
+
+.. _miscompilation debugger:
+
+Miscompilation debugger
+-----------------------
+
+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.
+
+Advice for using bugpoint
+=========================
+
+``bugpoint`` can be a remarkably useful tool, but it sometimes works in
+non-obvious ways.  Here are some hints and tips:
+
+* In the code generator and miscompilation debuggers, ``bugpoint`` only works
+  with programs that have deterministic output.  Thus, if the program outputs
+  ``argv[0]``, the date, time, or any other "random" data, ``bugpoint`` 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.
+
+* 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.
+
+* ``bugpoint`` is extremely useful when working on a new optimization: it helps
+  track down regressions quickly.  To avoid having to relink ``bugpoint`` every
+  time you change your optimization however, have ``bugpoint`` dynamically load
+  your optimization with the ``-load`` option.
+
+* ``bugpoint`` 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:
+
+  .. code-block:: bash
+
+    bugpoint  ... |& tee bugpoint.log
+
+  to get a copy of ``bugpoint``'s output in the file ``bugpoint.log``, as well
+  as on your terminal.
+
+* ``bugpoint`` cannot debug problems with the LLVM linker. If ``bugpoint``
+  crashes before you see its "All input ok" message, you might try ``llvm-link
+  -v`` on the same set of input files. If that also crashes, you may be
+  experiencing a linker bug.
+
+* ``bugpoint`` is useful for proactively finding bugs in LLVM.  Invoking
+  ``bugpoint`` with the ``-find-bugs`` 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 ``bugpoint``.
+
+What to do when bugpoint isn't enough
+=====================================
+	
+Sometimes, ``bugpoint`` 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.
+
+Turn on ``-debug-only=instcombine`` and see which transformations within
+instcombine are firing by selecting out lines with "``IC``" in them.
+
+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.
+
+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 "``visit*``" methods of ``InstCombiner`` (*e.g.*
+``visitICmpInst``) by adding a "``return false``" as the first line of the
+method.
+
+If that still doesn't remove enough, then change the caller of
+``InstCombiner::DoOneIteration``, ``InstCombiner::runOnFunction`` to limit the
+number of iterations.
+
+You may also find it useful to use "``-stats``" now to see what parts of
+instcombine are firing.  This can guide where to put additional reporting code.
+
+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:
+
+.. code-block:: c++
+
+
+  static int calledCount = 0;
+  calledCount++;
+  DEBUG(if (calledCount < 212) return false);
+  DEBUG(if (calledCount > 217) return false);
+  DEBUG(if (calledCount == 213) return false);
+  DEBUG(if (calledCount == 214) return false);
+  DEBUG(if (calledCount == 215) return false);
+  DEBUG(if (calledCount == 216) return false);
+  DEBUG(dbgs() << "visitXOR calledCount: " << calledCount << "\n");
+  DEBUG(dbgs() << "I: "; I->dump());
+
+could be added to ``visitXOR`` to limit ``visitXor`` 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
+``return SDNode();`` instead of ``return false;``.
+
+Now that that the number of transformations is down to a manageable number, try
+examining the output to see if you can figure out which transformations are
+being done.  If that can be figured out, then do the usual debugging.  If which
+code corresponds to the transformation being performed isn't obvious, set a
+breakpoint after the call count based disabling and step through the code.
+Alternatively, you can use "``printf``" style debugging to report waypoints.

Added: www-releases/trunk/3.2/docs/CMake.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CMake.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CMake.rst (added)
+++ www-releases/trunk/3.2/docs/CMake.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,418 @@
+.. _building-with-cmake:
+
+========================
+Building LLVM with CMake
+========================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+`CMake <http://www.cmake.org/>`_ 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.
+
+If you are really anxious about getting a functional LLVM build, go to the
+`Quick start`_ section. If you are a CMake novice, start on `Basic CMake usage`_
+and then go back to the `Quick start`_ once you know what you are doing. The
+`Options and variables`_ section is a reference for customizing your build. If
+you already have experience with CMake, this is the recommended starting point.
+
+.. _Quick start:
+
+Quick start
+===========
+
+We use here the command-line, non-interactive CMake interface.
+
+#. `Download <http://www.cmake.org/cmake/resources/software.html>`_ and install
+   CMake. Version 2.8 is the minimum required.
+
+#. Open a shell. Your development tools must be reachable from this shell
+   through the PATH environment variable.
+
+#. Create a directory for containing the build. It is not supported to build
+   LLVM on the source directory. cd to this directory:
+
+   .. code-block:: bash
+
+     $ mkdir mybuilddir
+     $ cd mybuilddir
+
+#. Execute this command on the shell replacing `path/to/llvm/source/root` with
+   the path to the root of your LLVM source tree:
+
+   .. code-block:: bash
+
+     $ cmake path/to/llvm/source/root
+
+   CMake will detect your development environment, perform a series of test and
+   generate the files required for building LLVM. CMake will use default values
+   for all build parameters. See the `Options and variables`_ section for
+   fine-tuning your build
+
+   This can fail if CMake can't detect your toolset, or if it thinks that the
+   environment is not sane enough. On this case make sure that the toolset that
+   you intend to use is the only one reachable from the shell and that the shell
+   itself is the correct one for you development environment. CMake will refuse
+   to build MinGW makefiles if you have a POSIX shell reachable through the PATH
+   environment variable, for instance. You can force CMake to use a given build
+   tool, see the `Usage`_ section.
+
+.. _Basic CMake usage:
+.. _Usage:
+
+Basic CMake usage
+=================
+
+This section explains basic aspects of CMake, mostly for explaining those
+options which you may need on your day-to-day usage.
+
+CMake comes with extensive documentation in the form of html files and on the
+cmake executable itself. Execute ``cmake --help`` for further help options.
+
+CMake requires to know for which build tool it shall generate files (GNU make,
+Visual Studio, Xcode, etc). If not specified on the command line, it tries to
+guess it based on you environment. Once identified the build tool, CMake uses
+the corresponding *Generator* for creating files for your build tool. You can
+explicitly specify the generator with the command line option ``-G "Name of the
+generator"``. For knowing the available generators on your platform, execute
+
+.. code-block:: bash
+
+  $ cmake --help
+
+This will list the generator's names at the end of the help text. Generator's
+names are case-sensitive. Example:
+
+.. code-block:: bash
+
+  $ cmake -G "Visual Studio 9 2008" path/to/llvm/source/root
+
+For a given development platform there can be more than one adequate
+generator. If you use Visual Studio "NMake Makefiles" is a generator you can use
+for building with NMake. By default, CMake chooses the more specific generator
+supported by your development environment. If you want an alternative generator,
+you must tell this to CMake with the ``-G`` option.
+
+.. todo::
+
+  Explain variables and cache. Move explanation here from #options section.
+
+.. _Options and variables:
+
+Options and variables
+=====================
+
+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:
+
+.. code-block:: bash
+
+  $ cmake -DVARIABLE=value path/to/llvm/source
+
+You can set a variable after the initial CMake invocation for changing its
+value. You can also undefine a variable:
+
+.. code-block:: bash
+
+  $ cmake -UVARIABLE path/to/llvm/source
+
+Variables are stored on the CMake cache. This is a file named ``CMakeCache.txt``
+on the root of the build directory. Do not hand-edit it.
+
+Variables are listed here appending its type after a colon. It is correct to
+write the variable and the type on the CMake command line:
+
+.. code-block:: bash
+
+  $ cmake -DVARIABLE:TYPE=value path/to/llvm/source
+
+Frequently-used CMake variables
+-------------------------------
+
+Here are listed some of the CMake variables that are used often, along with a
+brief explanation and LLVM-specific notes. For full documentation, check the
+CMake docs or execute ``cmake --help-variable VARIABLE_NAME``.
+
+**CMAKE_BUILD_TYPE**:STRING
+  Sets the build type for ``make`` based generators. Possible values are
+  Release, Debug, RelWithDebInfo and MinSizeRel. On systems like Visual Studio
+  the user sets the build type with the IDE settings.
+
+**CMAKE_INSTALL_PREFIX**:PATH
+  Path where LLVM will be installed if "make install" is invoked or the
+  "INSTALL" target is built.
+
+**LLVM_LIBDIR_SUFFIX**:STRING
+  Extra suffix to append to the directory where libraries are to be
+  installed. On a 64-bit architecture, one could use ``-DLLVM_LIBDIR_SUFFIX=64``
+  to install libraries to ``/usr/lib64``.
+
+**CMAKE_C_FLAGS**:STRING
+  Extra flags to use when compiling C source files.
+
+**CMAKE_CXX_FLAGS**:STRING
+  Extra flags to use when compiling C++ source files.
+
+**BUILD_SHARED_LIBS**:BOOL
+  Flag indicating is shared libraries will be built. Its default value is
+  OFF. Shared libraries are not supported on Windows and not recommended in the
+  other OSes.
+
+.. _LLVM-specific variables:
+
+LLVM-specific variables
+-----------------------
+
+**LLVM_TARGETS_TO_BUILD**:STRING
+  Semicolon-separated list of targets to build, or *all* for building all
+  targets. Case-sensitive. For Visual C++ defaults to *X86*. On the other cases
+  defaults to *all*. Example: ``-DLLVM_TARGETS_TO_BUILD="X86;PowerPC"``.
+
+**LLVM_BUILD_TOOLS**:BOOL
+  Build LLVM tools. Defaults to ON. Targets for building each tool are generated
+  in any case. You can build an tool separately by invoking its target. For
+  example, you can build *llvm-as* with a makefile-based system executing *make
+  llvm-as* on the root of your build directory.
+
+**LLVM_INCLUDE_TOOLS**:BOOL
+  Generate build targets for the LLVM tools. Defaults to ON. You can use that
+  option for disabling the generation of build targets for the LLVM tools.
+
+**LLVM_BUILD_EXAMPLES**:BOOL
+  Build LLVM examples. Defaults to OFF. Targets for building each example are
+  generated in any case. See documentation for *LLVM_BUILD_TOOLS* above for more
+  details.
+
+**LLVM_INCLUDE_EXAMPLES**:BOOL
+  Generate build targets for the LLVM examples. Defaults to ON. You can use that
+  option for disabling the generation of build targets for the LLVM examples.
+
+**LLVM_BUILD_TESTS**:BOOL
+  Build LLVM unit tests. Defaults to OFF. Targets for building each unit test
+  are generated in any case. You can build a specific unit test with the target
+  *UnitTestNameTests* (where at this time *UnitTestName* can be ADT, Analysis,
+  ExecutionEngine, JIT, Support, Transform, VMCore; see the subdirectories of
+  *unittests* for an updated list.) It is possible to build all unit tests with
+  the target *UnitTests*.
+
+**LLVM_INCLUDE_TESTS**:BOOL
+  Generate build targets for the LLVM unit tests. Defaults to ON. You can use
+  that option for disabling the generation of build targets for the LLVM unit
+  tests.
+
+**LLVM_APPEND_VC_REV**:BOOL
+  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.
+
+**LLVM_ENABLE_THREADS**:BOOL
+  Build with threads support, if available. Defaults to ON.
+
+**LLVM_ENABLE_ASSERTIONS**:BOOL
+  Enables code assertions. Defaults to OFF if and only if ``CMAKE_BUILD_TYPE``
+  is *Release*.
+
+**LLVM_ENABLE_PIC**:BOOL
+  Add the ``-fPIC`` flag for the compiler command-line, if the compiler supports
+  this flag. Some systems, like Windows, do not need this flag. Defaults to ON.
+
+**LLVM_ENABLE_WARNINGS**:BOOL
+  Enable all compiler warnings. Defaults to ON.
+
+**LLVM_ENABLE_PEDANTIC**:BOOL
+  Enable pedantic mode. This disable compiler specific extensions, is
+  possible. Defaults to ON.
+
+**LLVM_ENABLE_WERROR**:BOOL
+  Stop and fail build, if a compiler warning is triggered. Defaults to OFF.
+
+**LLVM_BUILD_32_BITS**:BOOL
+  Build 32-bits executables and libraries on 64-bits systems. This option is
+  available only on some 64-bits unix systems. Defaults to OFF.
+
+**LLVM_TARGET_ARCH**:STRING
+  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.
+
+**LLVM_TABLEGEN**:STRING
+  Full path to a native TableGen executable (usually named ``tblgen``). This is
+  intended for cross-compiling: if the user sets this variable, no native
+  TableGen will be created.
+
+**LLVM_LIT_ARGS**:STRING
+  Arguments given to lit.  ``make check`` and ``make clang-test`` are affected.
+  By default, ``'-sv --no-progress-bar'`` on Visual C++ and Xcode, ``'-sv'`` on
+  others.
+
+**LLVM_LIT_TOOLS_DIR**:PATH
+  The path to GnuWin32 tools for tests. Valid on Windows host.  Defaults to "",
+  then Lit seeks tools according to %PATH%.  Lit can find tools(eg. grep, sort,
+  &c) on LLVM_LIT_TOOLS_DIR at first, without specifying GnuWin32 to %PATH%.
+
+**LLVM_ENABLE_FFI**:BOOL
+  Indicates whether LLVM Interpreter will be linked with Foreign Function
+  Interface library. If the library or its headers are installed on a custom
+  location, you can set the variables FFI_INCLUDE_DIR and
+  FFI_LIBRARY_DIR. Defaults to OFF.
+
+**LLVM_EXTERNAL_{CLANG,LLD,POLLY}_SOURCE_DIR**:PATH
+  Path to ``{Clang,lld,Polly}``\'s source directory. Defaults to
+  ``tools/{clang,lld,polly}``. ``{Clang,lld,Polly}`` will not be built when it
+  is empty or it does not point valid path.
+
+**LLVM_USE_OPROFILE**:BOOL
+  Enable building OProfile JIT support. Defaults to OFF
+
+**LLVM_USE_INTEL_JITEVENTS**:BOOL
+  Enable building support for Intel JIT Events API. Defaults to OFF
+
+Executing the test suite
+========================
+
+Testing is performed when the *check* target is built. For instance, if you are
+using makefiles, execute this command while on the top level of your build
+directory:
+
+.. code-block:: bash
+
+  $ make check
+
+On Visual Studio, you may run tests to build the project "check".
+
+Cross compiling
+===============
+
+See `this wiki page <http://www.vtk.org/Wiki/CMake_Cross_Compiling>`_ 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 `this section
+<http://www.vtk.org/Wiki/CMake_Cross_Compiling#Information_how_to_set_up_various_cross_compiling_toolchains>`_
+for a quick solution.
+
+Also see the `LLVM-specific variables`_ section for variables used when
+cross-compiling.
+
+Embedding LLVM in your project
+==============================
+
+The most difficult part of adding LLVM to the build of a project is to determine
+the set of LLVM libraries corresponding to the set of required LLVM
+features. What follows is an example of how to obtain this information:
+
+.. code-block:: cmake
+
+  # A convenience variable:
+  set(LLVM_ROOT "" CACHE PATH "Root of LLVM install.")
+
+  # A bit of a sanity check:
+  if( NOT EXISTS ${LLVM_ROOT}/include/llvm )
+  message(FATAL_ERROR "LLVM_ROOT (${LLVM_ROOT}) is not a valid LLVM install")
+  endif()
+
+  # We incorporate the CMake features provided by LLVM:
+  set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${LLVM_ROOT}/share/llvm/cmake")
+  include(LLVMConfig)
+
+  # Now set the header and library paths:
+  include_directories( ${LLVM_INCLUDE_DIRS} )
+  link_directories( ${LLVM_LIBRARY_DIRS} )
+  add_definitions( ${LLVM_DEFINITIONS} )
+
+  # Let's suppose we want to build a JIT compiler with support for
+  # binary code (no interpreter):
+  llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native)
+
+  # Finally, we link the LLVM libraries to our executable:
+  target_link_libraries(mycompiler ${REQ_LLVM_LIBRARIES})
+
+This assumes that LLVM_ROOT points to an install of LLVM. The procedure works
+too for uninstalled builds although we need to take care to add an
+`include_directories` for the location of the headers on the LLVM source
+directory (if we are building out-of-source.)
+
+Alternativaly, you can utilize CMake's ``find_package`` functionality. Here is
+an equivalent variant of snippet shown above:
+
+.. code-block:: cmake
+
+  find_package(LLVM)
+
+  if( NOT LLVM_FOUND )
+    message(FATAL_ERROR "LLVM package can't be found. Set CMAKE_PREFIX_PATH variable to LLVM's installation prefix.")
+  endif()
+
+  include_directories( ${LLVM_INCLUDE_DIRS} )
+  link_directories( ${LLVM_LIBRARY_DIRS} )
+
+  llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native)
+
+  target_link_libraries(mycompiler ${REQ_LLVM_LIBRARIES})
+
+Developing LLVM pass out of source
+----------------------------------
+
+It is possible to develop LLVM passes against installed LLVM.  An example of
+project layout provided below:
+
+.. code-block:: bash
+
+  <project dir>/
+      |
+      CMakeLists.txt
+      <pass name>/
+          |
+          CMakeLists.txt
+          Pass.cpp
+          ...
+
+Contents of ``<project dir>/CMakeLists.txt``:
+
+.. code-block:: cmake
+
+  find_package(LLVM)
+
+  # Define add_llvm_* macro's.
+  include(AddLLVM)
+
+  add_definitions(${LLVM_DEFINITIONS})
+  include_directories(${LLVM_INCLUDE_DIRS})
+  link_directories(${LLVM_LIBRARY_DIRS})
+
+  add_subdirectory(<pass name>)
+
+Contents of ``<project dir>/<pass name>/CMakeLists.txt``:
+
+.. code-block:: cmake
+
+  add_llvm_loadable_module(LLVMPassname
+    Pass.cpp
+    )
+
+When you are done developing your pass, you may wish to integrate it
+into LLVM source tree. You can achieve it in two easy steps:
+
+#. Copying ``<pass name>`` folder into ``<LLVM root>/lib/Transform`` directory.
+
+#. Adding ``add_subdirectory(<pass name>)`` line into
+   ``<LLVM root>/lib/Transform/CMakeLists.txt``.
+
+Compiler/Platform specific topics
+=================================
+
+Notes for specific compilers and/or platforms.
+
+Microsoft Visual C++
+--------------------
+
+**LLVM_COMPILER_JOBS**:STRING
+  Specifies the maximum number of parallell compiler jobs to use per project
+  when building with msbuild or Visual Studio. Only supported for Visual Studio
+  2008 and Visual Studio 2010 CMake generators. 0 means use all
+  processors. Default is 0.

Added: www-releases/trunk/3.2/docs/CodeGenerator.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CodeGenerator.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CodeGenerator.rst (added)
+++ www-releases/trunk/3.2/docs/CodeGenerator.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,2427 @@
+.. _code_generator:
+
+==========================================
+The LLVM Target-Independent Code Generator
+==========================================
+
+.. role:: raw-html(raw)
+   :format: html
+
+.. raw:: html
+
+  <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" }
+  </style>
+
+.. contents::
+   :local:
+
+.. warning::
+  This is a work in progress.
+
+Introduction
+============
+
+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:
+
+1. `Abstract target description`_ interfaces which capture important properties
+   about various aspects of the machine, independently of how they will be used.
+   These interfaces are defined in ``include/llvm/Target/``.
+
+2. Classes used to represent the `code being generated`_ for a target.  These
+   classes are intended to be abstract enough to represent the machine code for
+   *any* target machine.  These classes are defined in
+   ``include/llvm/CodeGen/``. At this level, concepts like "constant pool
+   entries" and "jump tables" are explicitly exposed.
+
+3. Classes and algorithms used to represent code as the object file level, the
+   `MC Layer`_.  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.
+
+4. `Target-independent algorithms`_ used to implement various phases of native
+   code generation (register allocation, scheduling, stack frame representation,
+   etc).  This code lives in ``lib/CodeGen/``.
+
+5. `Implementations of the abstract target description interfaces`_ 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 ``lib/Target/``.
+
+6. The target-independent JIT components.  The LLVM JIT is completely target
+   independent (it uses the ``TargetJITInfo`` structure to interface for
+   target-specific issues.  The code for the target-independent JIT lives in
+   ``lib/ExecutionEngine/JIT``.
+
+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 `target description`_ and `machine code representation`_
+classes.  If you want to add a backend for a new target, you will need to
+`implement the target description`_ classes for your new target and understand
+the `LLVM code representation <LangRef.html>`_.  If you are interested in
+implementing a new `code generation algorithm`_, it should only depend on the
+target-description and machine code representation classes, ensuring that it is
+portable.
+
+Required components in the code generator
+-----------------------------------------
+
+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 (:raw-html:`<tt>`
+`TargetMachine`_ :raw-html:`</tt>` and :raw-html:`<tt>` `DataLayout`_
+:raw-html:`</tt>`) 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.
+
+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.
+
+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.
+
+.. _high-level design of the code generator:
+
+The high-level design of the code generator
+-------------------------------------------
+
+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:
+
+1. `Instruction Selection`_ --- 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.
+
+2. `Scheduling and Formation`_ --- 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 :raw-html:`<tt>`
+   `MachineInstr`_\s :raw-html:`</tt>` with that ordering.  Note that we
+   describe this in the `instruction selection section`_ because it operates on
+   a `SelectionDAG`_.
+
+3. `SSA-based Machine Code Optimizations`_ --- 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.
+
+4. `Register Allocation`_ --- 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.
+
+5. `Prolog/Epilog Code Insertion`_ --- 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.
+
+6. `Late Machine Code Optimizations`_ --- Optimizations that operate on "final"
+   machine code can go here, such as spill code scheduling and peephole
+   optimizations.
+
+7. `Code Emission`_ --- The final stage actually puts out the code for the
+   current function, either in the target assembler format or in machine
+   code.
+
+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.
+
+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.
+
+Using TableGen for target description
+-------------------------------------
+
+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 ``add`` instruction is almost identical to a ``sub``
+instruction).  In order to allow the maximum amount of commonality to be
+factored out, the LLVM code generator uses the
+`TableGen <TableGenFundamentals.html>`_ 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.
+
+As LLVM continues to be developed and refined, we plan to move more and more of
+the target description to the ``.td`` 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 ``tblgen``, we only need a change
+in one place (``tblgen``) to update all of the targets to a new interface.
+
+.. _Abstract target description:
+.. _target description:
+
+Target description classes
+==========================
+
+The LLVM target description classes (located in the ``include/llvm/Target``
+directory) provide an abstract description of the target machine independent of
+any particular client.  These classes are designed to capture the *abstract*
+properties of the target (such as the instructions and registers it has), and do
+not incorporate any particular pieces of code generation algorithms.
+
+All of the target description classes (except the :raw-html:`<tt>` `DataLayout`_
+:raw-html:`</tt>` class) are designed to be subclassed by the concrete target
+implementation, and have virtual methods implemented.  To get to these
+implementations, the :raw-html:`<tt>` `TargetMachine`_ :raw-html:`</tt>` class
+provides accessors that should be implemented by the target.
+
+.. _TargetMachine:
+
+The ``TargetMachine`` class
+---------------------------
+
+The ``TargetMachine`` class provides virtual methods that are used to access the
+target-specific implementations of the various target description classes via
+the ``get*Info`` methods (``getInstrInfo``, ``getRegisterInfo``,
+``getFrameInfo``, etc.).  This class is designed to be specialized by a concrete
+target implementation (e.g., ``X86TargetMachine``) which implements the various
+virtual methods.  The only required target description class is the
+:raw-html:`<tt>` `DataLayout`_ :raw-html:`</tt>` class, but if the code
+generator components are to be used, the other interfaces should be implemented
+as well.
+
+.. _DataLayout:
+
+The ``DataLayout`` class
+------------------------
+
+The ``DataLayout`` 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).  ``DataLayout`` 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.
+
+.. _targetlowering:
+
+The ``TargetLowering`` class
+----------------------------
+
+The ``TargetLowering`` 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:
+
+* an initial register class to use for various ``ValueType``\s,
+
+* which operations are natively supported by the target machine,
+
+* the return type of ``setcc`` operations,
+
+* the type to use for shift amounts, and
+
+* various high-level characteristics, like whether it is profitable to turn
+  division by a constant into a multiplication sequence.
+
+The ``TargetRegisterInfo`` class
+--------------------------------
+
+The ``TargetRegisterInfo`` class is used to describe the register file of the
+target and any interactions between the registers.
+
+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 ``#0`` is reserved as a flag value.
+
+Each register in the processor description has an associated
+``TargetRegisterDesc`` 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).
+
+In addition to the per-register description, the ``TargetRegisterInfo`` class
+exposes a set of processor specific register classes (instances of the
+``TargetRegisterClass`` 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.
+
+The target-specific implementations of these classes is auto-generated from a
+`TableGen <TableGenFundamentals.html>`_ description of the register file.
+
+.. _TargetInstrInfo:
+
+The ``TargetInstrInfo`` class
+-----------------------------
+
+The ``TargetInstrInfo`` class is used to describe the machine instructions
+supported by the target. It is essentially an array of ``TargetInstrDescriptor``
+objects, each of which describes one instruction the target
+supports. Descriptors 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.
+
+The ``TargetFrameInfo`` class
+-----------------------------
+
+The ``TargetFrameInfo`` 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.
+
+The ``TargetSubtarget`` class
+-----------------------------
+
+The ``TargetSubtarget`` 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.
+
+The ``TargetJITInfo`` class
+---------------------------
+
+The ``TargetJITInfo`` class exposes an abstract interface used by the
+Just-In-Time code generator to perform target-specific activities, such as
+emitting stubs.  If a ``TargetMachine`` supports JIT code generation, it should
+provide one of these objects through the ``getJITInfo`` method.
+
+.. _code being generated:
+.. _machine code representation:
+
+Machine code description classes
+================================
+
+At the high-level, LLVM code is translated to a machine specific representation
+formed out of :raw-html:`<tt>` `MachineFunction`_ :raw-html:`</tt>`,
+:raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>`, and :raw-html:`<tt>`
+`MachineInstr`_ :raw-html:`</tt>` instances (defined in
+``include/llvm/CodeGen``).  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.
+
+.. _MachineInstr:
+
+The ``MachineInstr`` class
+--------------------------
+
+Target machine instructions are represented as instances of the ``MachineInstr``
+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.
+
+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
+``*InstrInfo.td`` file for the target. The opcode enum values are auto-generated
+from this description.  The ``MachineInstr`` 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 :raw-html:`<tt>`
+`TargetInstrInfo`_ :raw-html:`</tt>` class.
+
+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).
+
+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:
+"``add %i1, %i2, %i3``" 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 "``%i3, %i1, %i2``": with the destination first.
+
+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:
+
+.. code-block:: llvm
+
+  %r3 = add %i1, %i2
+
+Also if the first operand is a def, it is easier to `create instructions`_ whose
+only def is the first operand.
+
+.. _create instructions:
+
+Using the ``MachineInstrBuilder.h`` functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Machine instructions are created by using the ``BuildMI`` functions, located in
+the ``include/llvm/CodeGen/MachineInstrBuilder.h`` file.  The ``BuildMI``
+functions make it easy to build arbitrary machine instructions.  Usage of the
+``BuildMI`` functions look like this:
+
+.. code-block:: c++
+
+  // Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
+  // instruction.  The '1' specifies how many operands will be added.
+  MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
+
+  // Create the same instr, but insert it at the end of a basic block.
+  MachineBasicBlock &MBB = ...
+  BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
+
+  // Create the same instr, but insert it before a specified iterator point.
+  MachineBasicBlock::iterator MBBI = ...
+  BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
+
+  // Create a 'cmp Reg, 0' instruction, no destination reg.
+  MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
+
+  // Create an 'sahf' instruction which takes no operands and stores nothing.
+  MI = BuildMI(X86::SAHF, 0);
+
+  // Create a self looping branch instruction.
+  BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
+
+The key thing to remember with the ``BuildMI`` functions is that you have to
+specify the number of operands that the machine instruction will take.  This
+allows for efficient memory allocation.  You also need to specify if operands
+default to be uses of values, not definitions.  If you need to add a definition
+operand (other than the optional destination register), you must explicitly mark
+it as such:
+
+.. code-block:: c++
+
+  MI.addReg(Reg, RegState::Define);
+
+Fixed (preassigned) registers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 *must* 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 ``EAX``/``EDX``
+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.
+
+For example, consider this simple LLVM example:
+
+.. code-block:: llvm
+
+  define i32 @test(i32 %X, i32 %Y) {
+    %Z = udiv i32 %X, %Y
+    ret i32 %Z
+  }
+
+The X86 instruction selector produces this machine code for the ``div`` and
+``ret`` (use "``llc X.bc -march=x86 -print-machineinstrs``" to get this):
+
+.. code-block:: llvm
+
+  ;; 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
+
+By the end of code generation, the register allocator has coalesced the
+registers and deleted the resultant identity moves producing the following
+code:
+
+.. code-block:: llvm
+
+  ;; X is in EAX, Y is in ECX
+  mov %EAX, %EDX
+  sar %EDX, 31
+  idiv %ECX
+  ret 
+
+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 *must* live in a virtual register.
+
+Call-clobbered registers
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some machine instructions, like calls, clobber a large number of physical
+registers.  Rather than adding ``<def,dead>`` operands for all of them, it is
+possible to use an ``MO_RegisterMask`` operand instead.  The register mask
+operand holds a bit mask of preserved registers, and everything else is
+considered to be clobbered by the instruction.
+
+Machine code in SSA form
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+``MachineInstr``'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.
+
+After register allocation, machine code is no longer in SSA-form because there
+are no virtual registers left in the code.
+
+.. _MachineBasicBlock:
+
+The ``MachineBasicBlock`` class
+-------------------------------
+
+The ``MachineBasicBlock`` class contains a list of machine instructions
+(:raw-html:`<tt>` `MachineInstr`_ :raw-html:`</tt>` 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 ``MachineBasicBlock`` class has a "``getBasicBlock``" method,
+which returns the LLVM basic block that it comes from.
+
+.. _MachineFunction:
+
+The ``MachineFunction`` class
+-----------------------------
+
+The ``MachineFunction`` class contains a list of machine basic blocks
+(:raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>` instances).  It
+corresponds one-to-one with the LLVM function input to the instruction selector.
+In addition to a list of basic blocks, the ``MachineFunction`` contains a a
+``MachineConstantPool``, a ``MachineFrameInfo``, a ``MachineFunctionInfo``, and
+a ``MachineRegisterInfo``.  See ``include/llvm/CodeGen/MachineFunction.h`` for
+more information.
+
+``MachineInstr Bundles``
+------------------------
+
+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).
+
+Conceptually a MI bundle is a MI with a number of other MIs nested within:
+
+::
+
+  --------------
+  |   Bundle   | ---------
+  --------------          \
+         |           ----------------
+         |           |      MI      |
+         |           ----------------
+         |                   |
+         |           ----------------
+         |           |      MI      |
+         |           ----------------
+         |                   |
+         |           ----------------
+         |           |      MI      |
+         |           ----------------
+         |
+  --------------
+  |   Bundle   | --------
+  --------------         \
+         |           ----------------
+         |           |      MI      |
+         |           ----------------
+         |                   |
+         |           ----------------
+         |           |      MI      |
+         |           ----------------
+         |                   |
+         |                  ...
+         |
+  --------------
+  |   Bundle   | --------
+  --------------         \
+         |
+        ...
+
+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.
+
+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.
+
+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.
+
+.. _MC Layer:
+
+The "MC" Layer
+==============
+
+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.
+
+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.
+
+.. _MCStreamer:
+
+The ``MCStreamer`` API
+----------------------
+
+MCStreamer is best thought of as an assembler API.  It is an abstract API which
+is *implemented* 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.
+
+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 `Code Emission`_ phase of the code generator lowers
+higher level LLVM IR and Machine* constructs down to the MC layer, emitting
+directives through MCStreamer.
+
+On the implementation side of MCStreamer, there are two major implementations:
+one for writing out a .s file (MCAsmStreamer), and one for writing out a .o
+file (MCObjectStreamer).  MCAsmStreamer is a straight-forward implementation
+that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but
+MCObjectStreamer implements a full assembler.
+
+The ``MCContext`` class
+-----------------------
+
+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.
+
+The ``MCSymbol`` class
+----------------------
+
+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.
+
+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:
+
+::
+
+  foo:
+  bar:
+    .byte 4
+
+In this case, both the foo and bar symbols will have the same address.
+
+The ``MCSection`` class
+-----------------------
+
+The ``MCSection`` class represents an object-file specific section. It is
+subclassed by object file specific implementations (e.g. ``MCSectionMachO``,
+``MCSectionCOFF``, ``MCSectionELF``) 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).
+
+.. _MCInst:
+
+The ``MCInst`` class
+--------------------
+
+The ``MCInst`` class is a target-independent representation of an instruction.
+It is a simple class (much more so than `MachineInstr`_) 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. "``Lfoo-Lbar+42``") as an MCExpr.
+
+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.
+
+.. _Target-independent algorithms:
+.. _code generation algorithm:
+
+Target-independent code generation algorithms
+=============================================
+
+This section documents the phases described in the `high-level design of the
+code generator`_.  It explains how they work and some of the rationale behind
+their design.
+
+.. _Instruction Selection:
+.. _instruction selection section:
+
+Instruction Selection
+---------------------
+
+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.
+
+Portions of the DAG instruction selector are generated from the target
+description (``*.td``) files.  Our goal is for the entire instruction selector
+to be generated from these ``.td`` files, though currently there are still
+things that require custom C++ code.
+
+.. _SelectionDAG:
+
+Introduction to SelectionDAGs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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) `optimizations`_ may be
+performed; ones which require extensive information about the instructions
+efficiently supported by the target.
+
+The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
+``SDNode`` class.  The primary payload of the ``SDNode`` 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
+``include/llvm/CodeGen/SelectionDAGNodes.h`` file.
+
+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 ``SDValue`` class, which is a
+``<SDNode, unsigned>`` pair, indicating the node and result value being used,
+respectively.  Each value produced by an ``SDNode`` has an associated ``MVT``
+(Machine Value Type) indicating what the type of the value is.
+
+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 ``MVT::Other``.  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.
+
+A SelectionDAG has designated "Entry" and "Root" nodes.  The Entry node is
+always a marker node with an Opcode of ``ISD::EntryToken``.  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.
+
+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 `legalize types`_ and `legalize operations`_ phases
+are responsible for turning an illegal DAG into a legal DAG.
+
+SelectionDAG Instruction Selection Process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+SelectionDAG-based instruction selection consists of the following steps:
+
+#. `Build initial DAG`_ --- This stage performs a simple translation from the
+   input LLVM code to an illegal SelectionDAG.
+
+#. `Optimize SelectionDAG`_ --- This stage performs simple optimizations on the
+   SelectionDAG to simplify it, and recognize meta instructions (like rotates
+   and ``div``/``rem`` pairs) for targets that support these meta operations.
+   This makes the resultant code more efficient and the `select instructions
+   from DAG`_ phase (below) simpler.
+
+#. `Legalize SelectionDAG Types`_ --- This stage transforms SelectionDAG nodes
+   to eliminate any types that are unsupported on the target.
+
+#. `Optimize SelectionDAG`_ --- The SelectionDAG optimizer is run to clean up
+   redundancies exposed by type legalization.
+
+#. `Legalize SelectionDAG Ops`_ --- This stage transforms SelectionDAG nodes to
+   eliminate any operations that are unsupported on the target.
+
+#. `Optimize SelectionDAG`_ --- The SelectionDAG optimizer is run to eliminate
+   inefficiencies introduced by operation legalization.
+
+#. `Select instructions from DAG`_ --- 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.
+
+#. `SelectionDAG Scheduling and Formation`_ --- 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.
+
+After all of these steps are complete, the SelectionDAG is destroyed and the
+rest of the code generation passes are run.
+
+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 `need to configure your
+system <ProgrammersManual.html#ViewGraph>`_ to add support for it).
+
+* ``-view-dag-combine1-dags`` displays the DAG after being built, before the
+  first optimization pass.
+
+* ``-view-legalize-dags`` displays the DAG before Legalization.
+
+* ``-view-dag-combine2-dags`` displays the DAG before the second optimization
+  pass.
+
+* ``-view-isel-dags`` displays the DAG before the Select phase.
+
+* ``-view-sched-dags`` displays the DAG before Scheduling.
+
+The ``-view-sunit-dags`` 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.
+
+.. _Build initial DAG:
+
+Initial SelectionDAG Construction
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The initial SelectionDAG is na\ :raw-html:`ï`\ vely peephole expanded from
+the LLVM input by the ``SelectionDAGBuilder`` 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 ``add`` turns into an
+``SDNode add`` while a ``getelementptr`` is expanded into the obvious
+arithmetic). This pass requires target-specific hooks to lower calls, returns,
+varargs, etc.  For these features, the :raw-html:`<tt>` `TargetLowering`_
+:raw-html:`</tt>` interface is used.
+
+.. _legalize types:
+.. _Legalize SelectionDAG Types:
+.. _Legalize SelectionDAG Ops:
+
+SelectionDAG LegalizeTypes Phase
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The Legalize phase is in charge of converting a DAG to only use the types that
+are natively supported by the target.
+
+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.
+
+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").
+
+A target implementation tells the legalizer which types are supported (and which
+register class to use for them) by calling the ``addRegisterClass`` method in
+its TargetLowering constructor.
+
+.. _legalize operations:
+.. _Legalizer:
+
+SelectionDAG Legalize Phase
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The Legalize phase is in charge of converting a DAG to only use the operations
+that are natively supported by the target.
+
+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").
+
+A target implementation tells the legalizer which operations are not supported
+(and which of the above three actions to take) by calling the
+``setOperationAction`` method in its ``TargetLowering`` constructor.
+
+Prior to the existence of the Legalize passes, we required that every target
+`selector`_ 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.
+
+.. _optimizations:
+.. _Optimize SelectionDAG:
+.. _selector:
+
+SelectionDAG Optimization Phase: the DAG Combiner
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 *good* and legal code).
+
+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:
+
+"`Widening integer arithmetic <http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html>`_" :raw-html:`<br>`
+Kevin Redwine and Norman Ramsey :raw-html:`<br>`
+International Conference on Compiler Construction (CC) 2004
+
+"`Effective sign extension elimination <http://portal.acm.org/citation.cfm?doid=512529.512552>`_"  :raw-html:`<br>`
+Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani :raw-html:`<br>`
+Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
+and Implementation.
+
+.. _Select instructions from DAG:
+
+SelectionDAG Select Phase
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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:
+
+.. code-block:: llvm
+
+  %t1 = fadd float %W, %X
+  %t2 = fmul float %t1, %Y
+  %t3 = fadd float %t2, %Z
+
+This LLVM code corresponds to a SelectionDAG that looks basically like this:
+
+.. code-block:: llvm
+
+  (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
+
+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:
+
+::
+
+  (FMADDS (FADDS W, X), Y, Z)
+
+The ``FMADDS`` instruction is a ternary instruction that multiplies its first
+two operands and adds the third (as single-precision floating-point numbers).
+The ``FADDS`` instruction is a simple binary single-precision add instruction.
+To perform this pattern match, the PowerPC backend includes the following
+instruction definitions:
+
+::
+
+  def FMADDS : AForm_1<59, 29,
+                      (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
+                      "fmadds $FRT, $FRA, $FRC, $FRB",
+                      [(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
+                                             F4RC:$FRB))]>;
+  def FADDS : AForm_2<59, 21,
+                      (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
+                      "fadds $FRT, $FRA, $FRB",
+                      [(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))]>;
+
+The portion of the instruction definition in bold indicates the pattern used to
+match the instruction.  The DAG operators (like ``fmul``/``fadd``) are defined
+in the ``include/llvm/Target/TargetSelectionDAG.td`` file.  " ``F4RC``" is the
+register class of the input and result values.
+
+The TableGen DAG instruction selector generator reads the instruction patterns
+in the ``.td`` file and automatically builds parts of the pattern matching code
+for your target.  It has the following strengths:
+
+* At compiler-compiler time, it analyzes your instruction patterns and tells you
+  if your patterns make sense or not.
+
+* 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 ``immSExt16``
+  and related ``tblgen`` classes in the PowerPC backend.
+
+* It knows several important identities for the patterns defined.  For example,
+  it knows that addition is commutative, so it allows the ``FMADDS`` pattern
+  above to match "``(fadd X, (fmul Y, Z))``" as well as "``(fadd (fmul X, Y),
+  Z)``", without the target author having to specially handle this case.
+
+* 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 ``FMADDS`` case above, we didn't have to tell ``tblgen`` 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 ``F4RC`` has type 'f32'.
+
+* 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 "``(not
+  x)``" operation is actually defined as a pattern fragment that expands as
+  "``(xor x, -1)``", since the SelectionDAG does not have a native '``not``'
+  operation.  Targets can define their own short-hand fragments as they see fit.
+  See the definition of '``not``' and '``ineg``' for examples.
+
+* 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:
+
+  ::
+
+    // Arbitrary immediate support.  Implement in terms of LIS/ORI.
+    def : Pat<(i32 imm:$imm),
+              (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;
+
+  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 ``ORI`` ('or a 16-bit immediate') and an ``LIS``
+  ('load 16-bit immediate, where the immediate is shifted to the left 16 bits')
+  instruction".  To make this work, the ``LO16``/``HI16`` node transformations
+  are used to manipulate the input immediate (in this case, take the high or low
+  16-bits of the immediate).
+
+* 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.
+
+While it has many strengths, the system currently has some limitations,
+primarily because it is a work in progress and is not yet finished:
+
+* Overall, there is no way to define or match SelectionDAG nodes that define
+  multiple values (e.g. ``SMUL_LOHI``, ``LOAD``, ``CALL``, etc).  This is the
+  biggest reason that you currently still *have to* write custom C++ code
+  for your instruction selector.
+
+* 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 `X86 addressing mode`_, which are
+  currently matched with custom C++ code).  In addition, we'll extend fragments
+  so that a fragment can match multiple different patterns.
+
+* We don't automatically infer flags like ``isStore``/``isLoad`` yet.
+
+* We don't automatically generate the set of supported registers and operations
+  for the `Legalizer`_ yet.
+
+* We don't have a way of tying in custom legalized nodes yet.
+
+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!
+
+.. _Scheduling and Formation:
+.. _SelectionDAG Scheduling and Formation:
+
+SelectionDAG Scheduling and Formation Phase
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 :raw-html:`<tt>` `MachineInstr`_\s :raw-html:`</tt>` and
+the SelectionDAG is destroyed.
+
+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.
+
+Future directions for the SelectionDAG
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+#. Optional function-at-a-time selection.
+
+#. Auto-generate entire selector from ``.td`` file.
+
+.. _SSA-based Machine Code Optimizations:
+
+SSA-based Machine Code Optimizations
+------------------------------------
+
+To Be Written
+
+Live Intervals
+--------------
+
+Live Intervals are the ranges (intervals) where a variable is *live*.  They are
+used by some `register allocator`_ 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 *spilled*.
+
+Live Variable Analysis
+^^^^^^^^^^^^^^^^^^^^^^
+
+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 *virtual* register and *register allocatable* 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.
+
+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 ``return``, then it's marked as using all live out values in the
+function.
+
+``PHI`` 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 ``PHI`` node is defined
+before it's used. When a ``PHI`` node is encountered, only the definition is
+handled, because the uses will be handled in other basic blocks.
+
+For each ``PHI`` 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 ``PHI`` node and one of the ``PHI`` node's operands
+is coming from the current basic block, then the variable is marked as *alive*
+within the current basic block and all of its predecessor basic blocks, until
+the basic block with the defining instruction is encountered.
+
+Live Intervals Analysis
+^^^^^^^^^^^^^^^^^^^^^^^
+
+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 ``[1, N]``.  A live interval is an interval
+``[i, j)``, where ``1 >= i >= j > N``, for which a variable is live.
+
+.. note::
+  More to come...
+
+.. _Register Allocation:
+.. _register allocator:
+
+Register Allocation
+-------------------
+
+The *Register Allocation problem* consists in mapping a program
+:raw-html:`<b><tt>` P\ :sub:`v`\ :raw-html:`</tt></b>`, that can use an unbounded
+number of virtual registers, to a program :raw-html:`<b><tt>` P\ :sub:`p`\
+:raw-html:`</tt></b>` 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 *spilled virtuals*.
+
+How registers are represented in LLVM
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 ``GenRegisterNames.inc`` file for that
+architecture. For instance, by inspecting
+``lib/Target/X86/X86GenRegisterInfo.inc`` we see that the 32-bit register
+``EAX`` is denoted by 43, and the MMX register ``MM0`` is mapped to 65.
+
+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 ``EAX``, ``AX`` and ``AL`` share the first eight bits. These physical
+registers are marked as *aliased* in LLVM. Given a particular architecture, you
+can check which registers are aliased by inspecting its ``RegisterInfo.td``
+file. Moreover, the class ``MCRegAliasIterator`` enumerates all the physical
+registers aliased to a register.
+
+Physical registers, in LLVM, are grouped in *Register Classes*.  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
+``TargetRegisterClass`` objects.  To discover if a virtual register is
+compatible with a given physical, this code can be used:</p>
+
+.. code-block:: c++
+
+  bool RegMapping_Fer::compatible_class(MachineFunction &mf,
+                                        unsigned v_reg,
+                                        unsigned p_reg) {
+    assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
+           "Target register must be physical");
+    const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
+    return trc->contains(p_reg);
+  }
+
+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 ``TargetRegsterInfo.td`` file. Just ``grep`` for
+``RegisterClass``, 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 *allocation order*. See the
+definition of the ``GR8`` register class in
+``lib/Target/X86/X86RegisterInfo.td`` for an example of this.
+
+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 ``TargetRegisterInfo.td`` 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
+``MachineRegisterInfo::createVirtualRegister()``. This method will return a new
+virtual register. Use an ``IndexedMap<Foo, VirtReg2IndexFunctor>`` to hold
+information per virtual register. If you need to enumerate all virtual
+registers, use the function ``TargetRegisterInfo::index2VirtReg()`` to find the
+virtual register numbers:
+
+.. code-block:: c++
+
+    for (unsigned i = 0, e = MRI->getNumVirtRegs(); i != e; ++i) {
+      unsigned VirtReg = TargetRegisterInfo::index2VirtReg(i);
+      stuff(VirtReg);
+    }
+
+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
+``MachineOperand::isRegister()``. To obtain the integer code of a register, use
+``MachineOperand::getReg()``. An instruction may define or use a register. For
+instance, ``ADD reg:1026 := reg:1025 reg:1024`` defines the registers 1024, and
+uses registers 1025 and 1026. Given a register operand, the method
+``MachineOperand::isUse()`` informs if that register is being used by the
+instruction. The method ``MachineOperand::isDef()`` informs if that registers is
+being defined.
+
+We will call physical registers present in the LLVM bitcode before register
+allocation *pre-colored registers*. 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 *implicitly* defined, and those *explicitly*
+defined. Explicitly defined registers are normal operands, and can be accessed
+with ``MachineInstr::getOperand(int)::getReg()``.  In order to check which
+registers are implicitly defined by an instruction, use the
+``TargetInstrInfo::get(opcode)::ImplicitDefs``, where ``opcode`` 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
+``TargetInstrInfo::get(opcode)::ImplicitUses``. 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.
+
+Mapping virtual registers to physical registers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are two ways to map virtual registers to physical registers (or to memory
+slots). The first way, that we will call *direct mapping*, is based on the use
+of methods of the classes ``TargetRegisterInfo``, and ``MachineOperand``. The
+second way, that we will call *indirect mapping*, relies on the ``VirtRegMap``
+class in order to insert loads and stores sending and getting values to and from
+memory.
+
+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 ``MachineOperand::setReg(p_reg)``. To
+insert a store instruction, use ``TargetInstrInfo::storeRegToStackSlot(...)``,
+and to insert a load instruction, use ``TargetInstrInfo::loadRegFromStackSlot``.
+
+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 ``VirtRegMap::assignVirt2Phys(vreg, preg)``.  In order to map
+a certain virtual register to memory, use
+``VirtRegMap::assignVirt2StackSlot(vreg)``. This method will return the stack
+slot where ``vreg``'s value will be located.  If it is necessary to map another
+virtual register to the same stack slot, use
+``VirtRegMap::assignVirt2StackSlot(vreg, stack_location)``. 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.
+
+If the indirect strategy is used, after all the virtual registers have been
+mapped to physical registers or stack slots, it is necessary to use a spiller
+object to place load and store instructions in the code. Every virtual that has
+been mapped to a stack slot will be stored to memory after been defined and will
+be loaded before being used. The implementation of the spiller tries to recycle
+load/store instructions, avoiding unnecessary instructions. For an example of
+how to invoke the spiller, see ``RegAllocLinearScan::runOnMachineFunction`` in
+``lib/CodeGen/RegAllocLinearScan.cpp``.
+
+Handling two address instructions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+With very rare exceptions (e.g., function calls), the LLVM machine code
+instructions are three address instructions. That is, each instruction is
+expected to define at most one register, and to use at most two registers.
+However, some architectures use two address instructions. In this case, the
+defined register is also one of the used register. For instance, an instruction
+such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX +
+%EBX``.
+
+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 ``TwoAddressInstructionPass`` 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 ``%a = ADD %b %c`` is converted to two
+instructions such as:
+
+::
+
+  %a = MOVE %b
+  %a = ADD %a %c
+
+Notice that, internally, the second instruction is represented as ``ADD
+%a[def/use] %c``. I.e., the register operand ``%a`` is both used and defined by
+the instruction.
+
+The SSA deconstruction phase
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An important transformation that happens during register allocation is called
+the *SSA Deconstruction Phase*. 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.
+
+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
+``lib/CodeGen/PHIElimination.cpp``. In order to invoke this pass, the identifier
+``PHIEliminationID`` must be marked as required in the code of the register
+allocator.
+
+Instruction folding
+^^^^^^^^^^^^^^^^^^^
+
+*Instruction folding* is an optimization performed during register allocation
+that removes unnecessary copy instructions. For instance, a sequence of
+instructions such as:
+
+::
+
+  %EBX = LOAD %mem_address
+  %EAX = COPY %EBX
+
+can be safely substituted by the single instruction:
+
+::
+
+  %EAX = LOAD %mem_address
+
+Instructions can be folded with the
+``TargetRegisterInfo::foldMemoryOperand(...)`` method. Care must be taken when
+folding instructions; a folded instruction can be quite different from the
+original instruction. See ``LiveIntervals::addIntervalsForSpills`` in
+``lib/CodeGen/LiveIntervalAnalysis.cpp`` for an example of its use.
+
+Built in register allocators
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The LLVM infrastructure provides the application developer with three different
+register allocators:
+
+* *Fast* --- 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.
+
+* *Basic* --- 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.
+
+* *Greedy* --- *The default allocator*. This is a highly tuned implementation of
+  the *Basic* allocator that incorporates global live range splitting. This
+  allocator works hard to minimize the cost of spill code.
+
+* *PBQP* --- 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.
+
+The type of register allocator used in ``llc`` can be chosen with the command
+line option ``-regalloc=...``:
+
+.. code-block:: bash
+
+  $ llc -regalloc=linearscan file.bc -o ln.s
+  $ llc -regalloc=fast file.bc -o fa.s
+  $ llc -regalloc=pbqp file.bc -o pbqp.s
+
+.. _Prolog/Epilog Code Insertion:
+
+Prolog/Epilog Code Insertion
+----------------------------
+
+Compact Unwind
+
+Throwing an exception requires *unwinding* 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 *compact
+unwind* and requires just 4-bytes per function.
+
+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 ``__TEXT,__unwind_info`` 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 ``__TEXT,__unwind_info`` section. If we emit DWARF
+unwind info, the ``__TEXT,__unwind_info`` section will contain the offset of the
+FDE in the ``__TEXT,__eh_frame`` section in the final linked image.
+
+For X86, there are three modes for the compact unwind encoding:
+
+*Function with a Frame Pointer (``EBP`` or ``RBP``)*
+  ``EBP/RBP``-based frame, where ``EBP/RBP`` is pushed onto the stack
+  immediately after the return address, then ``ESP/RSP`` is moved to
+  ``EBP/RBP``. Thus to unwind, ``ESP/RSP`` is restored with the current
+  ``EBP/RBP`` value, then ``EBP/RBP`` 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 ``EBP-4`` to ``EBP-1020`` (``RBP-8`` to
+  ``RBP-1020``). The offset (divided by 4 in 32-bit mode and 8 in 64-bit mode)
+  is encoded in bits 16-23 (mask: ``0x00FF0000``).  The registers saved are
+  encoded in bits 0-14 (mask: ``0x00007FFF``) as five 3-bit entries from the
+  following table:
+
+    ==============  =============  ===============
+    Compact Number  i386 Register  x86-64 Register
+    ==============  =============  ===============
+    1               ``EBX``        ``RBX``
+    2               ``ECX``        ``R12``
+    3               ``EDX``        ``R13``
+    4               ``EDI``        ``R14``
+    5               ``ESI``        ``R15``
+    6               ``EBP``        ``RBP``
+    ==============  =============  ===============
+
+*Frameless with a Small Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)*
+  To return, a constant (encoded in the compact unwind encoding) is added to the
+  ``ESP/RSP``.  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:
+  ``0x00FF0000``). 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: ``0x00001C00``). Bits 0-9 (mask: ``0x000003FF``) contain which
+  registers were saved and their order. (See the
+  ``encodeCompactUnwindRegistersWithoutFrame()`` function in
+  ``lib/Target/X86FrameLowering.cpp`` for the encoding algorithm.)
+
+*Frameless with a Large Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)*
+  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 "``subl $nnnnnn, %esp``" in its
+  prolog. The compact encoding contains the offset to the ``$nnnnnn`` value in
+  the function in bits 9-12 (mask: ``0x00001C00``).
+
+.. _Late Machine Code Optimizations:
+
+Late Machine Code Optimizations
+-------------------------------
+
+.. note::
+
+  To Be Written
+
+.. _Code Emission:
+
+Code Emission
+-------------
+
+The code emission step of code generation is responsible for lowering from the
+code generator abstractions (like `MachineFunction`_, `MachineInstr`_, etc) down
+to the abstractions used by the MC layer (`MCInst`_, `MCStreamer`_, 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.
+
+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.
+
+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:
+
+#. 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.
+
+#. Second, you need to implement an instruction printer for your target.  The
+   instruction printer takes an `MCInst`_ and renders it to a raw_ostream as
+   text.  Most of this is automatically generated from the .td file (when you
+   specify something like "``add $dst, $src1, $src2``" in the instructions), but
+   you need to implement routines to print operands.
+
+#. Third, you need to implement code that lowers a `MachineInstr`_ 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.
+
+Finally, at your choosing, you can also implement an subclass of MCCodeEmitter
+which lowers MCInst's into machine code bytes and relocations.  This is
+important if you want to support direct .o file emission, or would like to
+implement an assembler for your target.
+
+VLIW Packetizer
+---------------
+
+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 *packets* or
+*bundles*. The VLIW packetizer in LLVM is a target-independent mechanism to
+enable the packetization of machine instructions.
+
+Mapping from instructions to functional units
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+How the packetization tables are generated and used
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+To generate tables for a VLIW target, add *Target*\ GenDFAPacketizer.inc as a
+target to the Makefile in the target directory. The exported API provides three
+functions: ``DFAPacketizer::clearResources()``,
+``DFAPacketizer::reserveResources(MachineInstr *MI)``, and
+``DFAPacketizer::canReserveResources(MachineInstr *MI)``. 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
+``llvm/CodeGen/DFAPacketizer.h`` for more information.
+
+Implementing a Native Assembler
+===============================
+
+Though you're probably reading this because you want to write or maintain a
+compiler backend, LLVM also fully supports building a native assemblers too.
+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.
+
+Instruction Parsing
+-------------------
+
+.. note::
+
+  To Be Written
+
+
+Instruction Alias Processing
+----------------------------
+
+Once the instruction is parsed, it enters the MatchInstructionImpl function.
+The MatchInstructionImpl function performs alias processing and then does actual
+matching.
+
+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.
+
+Mnemonic Aliases
+^^^^^^^^^^^^^^^^
+
+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:
+
+::
+
+  def : MnemonicAlias<"cbw",     "cbtw">;
+  def : MnemonicAlias<"smovq",   "movsq">;
+  def : MnemonicAlias<"fldcww",  "fldcw">;
+  def : MnemonicAlias<"fucompi", "fucomip">;
+  def : MnemonicAlias<"ud2a",    "ud2">;
+
+... 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:
+
+::
+
+  def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
+  def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;
+
+In this example, the mnemonic gets mapped into different a new one depending on
+the current instruction set.
+
+Instruction Aliases
+^^^^^^^^^^^^^^^^^^^
+
+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:
+
+::
+
+  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)>;
+
+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:
+
+::
+
+  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)>;
+
+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:
+
+::
+
+  // 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)>;
+
+Instruction aliases can also have a Requires clause to make them subtarget
+specific.
+
+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.
+
+Instruction Matching
+--------------------
+
+.. note::
+
+  To Be Written
+
+.. _Implementations of the abstract target description interfaces:
+.. _implement the target description:
+
+Target-specific Implementation Notes
+====================================
+
+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.
+
+Target Feature Matrix
+---------------------
+
+Note that this table does not include the C backend or Cpp backends, since they
+do not use the target independent code generator infrastructure.  It also
+doesn't list features that are not supported fully by any target yet.  It
+considers a feature to be supported if at least one subtarget supports it.  A
+feature being supported means that it is useful and works for most cases, it
+does not indicate that there are zero known bugs in the implementation.  Here is
+the key:
+
+:raw-html:`<table border="1" cellspacing="0">`
+:raw-html:`<tr>`
+:raw-html:`<th>Unknown</th>`
+:raw-html:`<th>No support</th>`
+:raw-html:`<th>Partial Support</th>`
+:raw-html:`<th>Complete Support</th>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td class="unknown"></td>`
+:raw-html:`<td class="no"></td>`
+:raw-html:`<td class="partial"></td>`
+:raw-html:`<td class="yes"></td>`
+:raw-html:`</tr>`
+:raw-html:`</table>`
+
+Here is the table:
+
+:raw-html:`<table width="689" border="1" cellspacing="0">`
+:raw-html:`<tr><td></td>`
+:raw-html:`<td colspan="13" align="center" style="background-color:#ffc">Target</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<th>Feature</th>`
+:raw-html:`<th>ARM</th>`
+:raw-html:`<th>CellSPU</th>`
+:raw-html:`<th>Hexagon</th>`
+:raw-html:`<th>MBlaze</th>`
+:raw-html:`<th>MSP430</th>`
+:raw-html:`<th>Mips</th>`
+:raw-html:`<th>PTX</th>`
+:raw-html:`<th>PowerPC</th>`
+:raw-html:`<th>Sparc</th>`
+:raw-html:`<th>X86</th>`
+:raw-html:`<th>XCore</th>`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a href="#feat_reliable">is generally reliable</a></td>`
+:raw-html:`<td class="yes"></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="yes"></td> <!-- Hexagon -->`
+:raw-html:`<td class="no"></td> <!-- MBlaze -->`
+:raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
+:raw-html:`<td class="yes"></td> <!-- Mips -->`
+:raw-html:`<td class="no"></td> <!-- PTX -->`
+:raw-html:`<td class="yes"></td> <!-- PowerPC -->`
+:raw-html:`<td class="yes"></td> <!-- Sparc -->`
+:raw-html:`<td class="yes"></td> <!-- X86 -->`
+:raw-html:`<td class="unknown"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a href="#feat_asmparser">assembly parser</a></td>`
+:raw-html:`<td class="no"></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="no"></td> <!-- Hexagon -->`
+:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
+:raw-html:`<td class="no"></td> <!-- MSP430 -->`
+:raw-html:`<td class="no"></td> <!-- Mips -->`
+:raw-html:`<td class="no"></td> <!-- PTX -->`
+:raw-html:`<td class="no"></td> <!-- PowerPC -->`
+:raw-html:`<td class="no"></td> <!-- Sparc -->`
+:raw-html:`<td class="yes"></td> <!-- X86 -->`
+:raw-html:`<td class="no"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a href="#feat_disassembler">disassembler</a></td>`
+:raw-html:`<td class="yes"></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="no"></td> <!-- Hexagon -->`
+:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
+:raw-html:`<td class="no"></td> <!-- MSP430 -->`
+:raw-html:`<td class="no"></td> <!-- Mips -->`
+:raw-html:`<td class="no"></td> <!-- PTX -->`
+:raw-html:`<td class="no"></td> <!-- PowerPC -->`
+:raw-html:`<td class="no"></td> <!-- Sparc -->`
+:raw-html:`<td class="yes"></td> <!-- X86 -->`
+:raw-html:`<td class="no"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a href="#feat_inlineasm">inline asm</a></td>`
+:raw-html:`<td class="yes"></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="yes"></td> <!-- Hexagon -->`
+:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
+:raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
+:raw-html:`<td class="no"></td> <!-- Mips -->`
+:raw-html:`<td class="unknown"></td> <!-- PTX -->`
+:raw-html:`<td class="yes"></td> <!-- PowerPC -->`
+:raw-html:`<td class="unknown"></td> <!-- Sparc -->`
+:raw-html:`<td class="yes"></td> <!-- X86 -->`
+:raw-html:`<td class="unknown"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a href="#feat_jit">jit</a></td>`
+:raw-html:`<td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="no"></td> <!-- Hexagon -->`
+:raw-html:`<td class="no"></td> <!-- MBlaze -->`
+:raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
+:raw-html:`<td class="yes"></td> <!-- Mips -->`
+:raw-html:`<td class="unknown"></td> <!-- PTX -->`
+:raw-html:`<td class="yes"></td> <!-- PowerPC -->`
+:raw-html:`<td class="unknown"></td> <!-- Sparc -->`
+:raw-html:`<td class="yes"></td> <!-- X86 -->`
+:raw-html:`<td class="unknown"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a href="#feat_objectwrite">.o file writing</a></td>`
+:raw-html:`<td class="no"></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="no"></td> <!-- Hexagon -->`
+:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
+:raw-html:`<td class="no"></td> <!-- MSP430 -->`
+:raw-html:`<td class="no"></td> <!-- Mips -->`
+:raw-html:`<td class="no"></td> <!-- PTX -->`
+:raw-html:`<td class="no"></td> <!-- PowerPC -->`
+:raw-html:`<td class="no"></td> <!-- Sparc -->`
+:raw-html:`<td class="yes"></td> <!-- X86 -->`
+:raw-html:`<td class="no"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a hr:raw-html:`ef="#feat_tailcall">tail calls</a></td>`
+:raw-html:`<td class="yes"></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="yes"></td> <!-- Hexagon -->`
+:raw-html:`<td class="no"></td> <!-- MBlaze -->`
+:raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
+:raw-html:`<td class="no"></td> <!-- Mips -->`
+:raw-html:`<td class="unknown"></td> <!-- PTX -->`
+:raw-html:`<td class="yes"></td> <!-- PowerPC -->`
+:raw-html:`<td class="unknown"></td> <!-- Sparc -->`
+:raw-html:`<td class="yes"></td> <!-- X86 -->`
+:raw-html:`<td class="unknown"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`<tr>`
+:raw-html:`<td><a href="#feat_segstacks">segmented stacks</a></td>`
+:raw-html:`<td class="no"></td> <!-- ARM -->`
+:raw-html:`<td class="no"></td> <!-- CellSPU -->`
+:raw-html:`<td class="no"></td> <!-- Hexagon -->`
+:raw-html:`<td class="no"></td> <!-- MBlaze -->`
+:raw-html:`<td class="no"></td> <!-- MSP430 -->`
+:raw-html:`<td class="no"></td> <!-- Mips -->`
+:raw-html:`<td class="no"></td> <!-- PTX -->`
+:raw-html:`<td class="no"></td> <!-- PowerPC -->`
+:raw-html:`<td class="no"></td> <!-- Sparc -->`
+:raw-html:`<td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 -->`
+:raw-html:`<td class="no"></td> <!-- XCore -->`
+:raw-html:`</tr>`
+
+:raw-html:`</table>`
+
+.. _feat_reliable:
+
+Is Generally Reliable
+^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+.. _feat_asmparser:
+
+Assembly Parser
+^^^^^^^^^^^^^^^
+
+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.
+
+.. _feat_disassembler:
+
+Disassembler
+^^^^^^^^^^^^
+
+This box indicates whether the target supports the MCDisassembler API for
+disassembling machine opcode bytes into MCInst's.
+
+.. _feat_inlineasm:
+
+Inline Asm
+^^^^^^^^^^
+
+This box indicates whether the target supports most popular inline assembly
+constraints and modifiers.
+
+.. _feat_jit:
+
+JIT Support
+^^^^^^^^^^^
+
+This box indicates whether the target supports the JIT compiler through the
+ExecutionEngine interface.
+
+.. _feat_jit_arm:
+
+The ARM backend has basic support for integer code in ARM codegen mode, but
+lacks NEON and full Thumb support.
+
+.. _feat_objectwrite:
+
+.o File Writing
+^^^^^^^^^^^^^^^
+
+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.
+
+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).
+
+.. _feat_tailcall:
+
+Tail Calls
+^^^^^^^^^^
+
+This box indicates whether the target supports guaranteed tail calls.  These are
+calls marked "`tail <LangRef.html#i_call>`_" and use the fastcc calling
+convention.  Please see the `tail call section more more details`_.
+
+.. _feat_segstacks:
+
+Segmented Stacks
+^^^^^^^^^^^^^^^^
+
+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 `gcc implementation <http://gcc.gnu.org/wiki/SplitStacks>`_ used by the Go
+front end.
+
+.. _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.
+
+.. _tail call section more more details:
+
+Tail call optimization
+----------------------
+
+Tail call optimization, callee reusing the stack of the caller, is currently
+supported on x86/x86-64 and PowerPC. It is performed if:
+
+* Caller and callee have the calling convention ``fastcc`` or ``cc 10`` (GHC
+  call convention).
+
+* The call is a tail call - in tail position (ret immediately follows call and
+  ret uses value of call or is void).
+
+* Option ``-tailcallopt`` is enabled.
+
+* Platform specific constraints are met.
+
+x86/x86-64 constraints:
+
+* No variable argument lists are used.
+
+* On x86-64 when generating GOT/PIC code only module-local calls (visibility =
+  hidden or protected) are supported.
+
+PowerPC constraints:
+
+* No variable argument lists are used.
+
+* No byval parameters are used.
+
+* On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected)
+  are supported.
+
+Example:
+
+Call as ``llc -tailcallopt test.ll``.
+
+.. code-block:: llvm
+
+  declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
+
+  define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
+    %l1 = add i32 %in1, %in2
+    %tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
+    ret i32 %tmp
+  }
+
+Implications of ``-tailcallopt``:
+
+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 ``fastcc`` 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.
+
+Sibling call optimization
+-------------------------
+
+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 ``-tailcallopt`` option is not
+specified.
+
+Sibling call optimization is currently performed on x86/x86-64 when the
+following constraints are met:
+
+* Caller and callee have the same calling convention. It can be either ``c`` or
+  ``fastcc``.
+
+* The call is a tail call - in tail position (ret immediately follows call and
+  ret uses value of call or is void).
+
+* Caller and callee have matching return type or the callee result is not used.
+
+* 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.
+
+Example:
+
+.. code-block:: llvm
+
+  declare i32 @bar(i32, i32)
+
+  define i32 @foo(i32 %a, i32 %b, i32 %c) {
+  entry:
+    %0 = tail call i32 @bar(i32 %a, i32 %b)
+    ret i32 %0
+  }
+
+The X86 backend
+---------------
+
+The X86 code generator lives in the ``lib/Target/X86`` 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.
+
+X86 Target Triples supported
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+* **i686-pc-linux-gnu** --- Linux
+
+* **i386-unknown-freebsd5.3** --- FreeBSD 5.3
+
+* **i686-pc-cygwin** --- Cygwin on Win32
+
+* **i686-pc-mingw32** --- MingW on Win32
+
+* **i386-pc-mingw32msvc** --- MingW crosscompiler on Linux
+
+* **i686-apple-darwin*** --- Apple Darwin on X86
+
+* **x86_64-unknown-linux-gnu** --- Linux
+
+X86 Calling Conventions supported
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following target-specific calling conventions are known to backend:
+
+* **x86_StdCall** --- stdcall calling convention seen on Microsoft Windows
+  platform (CC ID = 64).
+
+* **x86_FastCall** --- fastcall calling convention seen on Microsoft Windows
+  platform (CC ID = 65).
+
+* **x86_ThisCall** --- 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).
+
+.. _X86 addressing mode:
+
+Representing X86 addressing modes in MachineInstrs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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):
+
+::
+
+  SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32
+
+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 '``mov``' has the
+following ``MachineOperand``\s in this order:
+
+::
+
+  Index:        0     |    1        2       3           4          5
+  Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement Segment
+  OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm  PhysReg
+
+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.
+
+X86 address spaces supported
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+x86 has a feature which provides the ability to perform loads and stores to
+different address spaces via the x86 segment registers.  A segment override
+prefix byte on an instruction causes the instruction's memory access to go to
+the specified segment.  LLVM address space 0 is the default address space, which
+includes the stack, and any unqualified memory accesses in a program.  Address
+spaces 1-255 are currently reserved for user-defined code.  The GS-segment is
+represented by address space 256, while the FS-segment is represented by address
+space 257. Other x86 segments have yet to be allocated address space
+numbers.
+
+While these address spaces may seem similar to TLS via the ``thread_local``
+keyword, and often use the same underlying hardware, there are some fundamental
+differences.
+
+The ``thread_local`` 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 ``thread_local`` keyword is
+target-independent at the LLVM IR level (though LLVM doesn't yet have
+implementations of it for some configurations)
+
+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).
+
+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.
+
+Instruction naming
+^^^^^^^^^^^^^^^^^^
+
+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:
+
+::
+
+  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
+
+The PowerPC backend
+-------------------
+
+The PowerPC code generator lives in the lib/Target/PowerPC directory.  The code
+generation is retargetable to several variations or *subtargets* of the PowerPC
+ISA; including ppc32, ppc64 and altivec.
+
+LLVM PowerPC ABI
+^^^^^^^^^^^^^^^^
+
+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 `PowerPC ABI
+<http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html>`_\
+. 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.
+
+Frame Layout
+^^^^^^^^^^^^
+
+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.
+
+An invocation frame is laid out as follows (low memory at top):
+
+:raw-html:`<table border="1" cellspacing="0">`
+:raw-html:`<tr>`
+:raw-html:`<td>Linkage<br><br></td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>Parameter area<br><br></td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>Dynamic area<br><br></td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>Locals area<br><br></td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>Saved registers area<br><br></td>`
+:raw-html:`</tr>`
+:raw-html:`<tr style="border-style: none hidden none hidden;">`
+:raw-html:`<td><br></td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>Previous Frame<br><br></td>`
+:raw-html:`</tr>`
+:raw-html:`</table>`
+
+The *linkage* 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.
+
+32 bit linkage area:
+
+:raw-html:`<table  border="1" cellspacing="0">`
+:raw-html:`<tr>`
+:raw-html:`<td>0</td>`
+:raw-html:`<td>Saved SP (r1)</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>4</td>`
+:raw-html:`<td>Saved CR</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>8</td>`
+:raw-html:`<td>Saved LR</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>12</td>`
+:raw-html:`<td>Reserved</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>16</td>`
+:raw-html:`<td>Reserved</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>20</td>`
+:raw-html:`<td>Saved FP (r31)</td>`
+:raw-html:`</tr>`
+:raw-html:`</table>`
+
+64 bit linkage area:
+
+:raw-html:`<table border="1" cellspacing="0">`
+:raw-html:`<tr>`
+:raw-html:`<td>0</td>`
+:raw-html:`<td>Saved SP (r1)</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>8</td>`
+:raw-html:`<td>Saved CR</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>16</td>`
+:raw-html:`<td>Saved LR</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>24</td>`
+:raw-html:`<td>Reserved</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>32</td>`
+:raw-html:`<td>Reserved</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>40</td>`
+:raw-html:`<td>Saved FP (r31)</td>`
+:raw-html:`</tr>`
+:raw-html:`</table>`
+
+The *parameter area* 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.)
+
+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.
+
+The *dynamic area* 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.
+
+The *locals area* is where the llvm compiler reserves space for local variables.
+
+The *saved registers area* is where the llvm compiler spills callee saved
+registers on entry to the callee.
+
+Prolog/Epilog
+^^^^^^^^^^^^^
+
+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.
+
+Dynamic Allocation
+^^^^^^^^^^^^^^^^^^
+
+.. note::
+
+  TODO - More to come.
+
+The PTX backend
+---------------
+
+The PTX code generator lives in the lib/Target/PTX directory. It is currently a
+work-in-progress, but already supports most of the code generation functionality
+needed to generate correct PTX kernels for CUDA devices.
+
+The code generator can target PTX 2.0+, and shader model 1.0+.  The PTX ISA
+Reference Manual is used as the primary source of ISA information, though an
+effort is made to make the output of the code generator match the output of the
+NVidia nvcc compiler, whenever possible.
+
+Code Generator Options:
+
+:raw-html:`<table border="1" cellspacing="0">`
+:raw-html:`<tr>`
+:raw-html:`<th>Option</th>`
+:raw-html:`<th>Description</th>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>``double``</td>`
+:raw-html:`<td align="left">If enabled, the map_f64_to_f32 directive is disabled in the PTX output, allowing native double-precision arithmetic</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>``no-fma``</td>`
+:raw-html:`<td align="left">Disable generation of Fused-Multiply Add instructions, which may be beneficial for some devices</td>`
+:raw-html:`</tr>`
+:raw-html:`<tr>`
+:raw-html:`<td>``smxy / computexy``</td>`
+:raw-html:`<td align="left">Set shader model/compute capability to x.y, e.g. sm20 or compute13</td>`
+:raw-html:`</tr>`
+:raw-html:`</table>`
+
+Working:
+
+* Arithmetic instruction selection (including combo FMA)
+
+* Bitwise instruction selection
+
+* Control-flow instruction selection
+
+* Function calls (only on SM 2.0+ and no return arguments)
+
+* Addresses spaces (0 = global, 1 = constant, 2 = local, 4 = shared)
+
+* Thread synchronization (bar.sync)
+
+* Special register reads ([N]TID, [N]CTAID, PMx, CLOCK, etc.)
+
+In Progress:
+
+* Robust call instruction selection
+
+* Stack frame allocation
+
+* Device-specific instruction scheduling optimizations

Added: www-releases/trunk/3.2/docs/CodingStandards.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CodingStandards.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CodingStandards.rst (added)
+++ www-releases/trunk/3.2/docs/CodingStandards.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,1326 @@
+.. _coding_standards:
+
+=====================
+LLVM Coding Standards
+=====================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+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).
+
+This document intentionally does not prescribe fixed standards for religious
+issues such as brace placement and space usage.  For issues like this, follow
+the golden rule:
+
+.. _Golden Rule:
+
+    **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.**
+
+Note that some code bases (e.g. ``libc++``) have really good reasons to deviate
+from the coding standards.  In the case of ``libc++``, this is because the
+naming and other conventions are dictated by the C++ standard.  If you think
+there is a specific good reason to deviate from the standards here, please bring
+it up on the LLVMdev mailing list.
+
+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 *do not*
+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.
+  
+The ultimate goal of these guidelines is the increase readability and
+maintainability of our common source base. If you have suggestions for topics to
+be included, please mail them to `Chris <mailto:sabre at nondot.org>`_.
+
+Mechanical Source Issues
+========================
+
+Source Code Formatting
+----------------------
+
+Commenting
+^^^^^^^^^^
+
+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
+*how* it does it at a micro level. Here are a few critical things to document:
+
+.. _header file comment:
+
+File Headers
+""""""""""""
+
+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:
+
+.. code-block:: c++
+
+  //===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
+  //
+  //                     The LLVM Compiler Infrastructure
+  //
+  // This file is distributed under the University of Illinois Open Source
+  // License. See LICENSE.TXT for details.
+  //
+  //===----------------------------------------------------------------------===//
+  ///
+  /// \file
+  /// \brief This file contains the declaration of the Instruction class, which is
+  /// the base class for all of the VM instructions.
+  ///
+  //===----------------------------------------------------------------------===//
+
+A few things to note about this particular format: The "``-*- C++ -*-``" string
+on the first line is there to tell Emacs that the source file is a C++ file, not
+a C file (Emacs assumes ``.h`` files are C files by default).
+
+.. note::
+
+    This tag is not necessary in ``.cpp`` 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.
+
+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.
+
+The main body is a ``doxygen`` comment describing the purpose of the file.  It
+should have a ``\brief`` command that describes the file in one or two
+sentences.  Any additional information should be separated by a blank line.  If
+an algorithm is being implemented or something tricky is going on, a reference
+to the paper where it is published should be included, as well as any notes or
+*gotchas* in the code to watch out for.
+
+Class overviews
+"""""""""""""""
+
+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
+``doxygen`` comment block.
+
+Method information
+""""""""""""""""""
+
+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.
+
+Good things to talk about here are what happens when something unexpected
+happens: does the method return null?  Abort?  Format your hard disk?
+
+Comment Formatting
+^^^^^^^^^^^^^^^^^^
+
+In general, prefer C++ style (``//``) 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 (``/* */``) comments however:
+
+#. When writing C code: Obviously if you are writing C code, use C style
+   comments.
+
+#. When writing a header file that may be ``#include``\d by a C source file.
+
+#. When writing a source file that is used by a tool that only accepts C style
+   comments.
+
+To comment out a large block of code, use ``#if 0`` and ``#endif``. These nest
+properly and are better behaved in general than C style comments.
+
+Doxygen Use in Documentation Comments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the ``\file`` command to turn the standard file header into a file-level
+comment.
+
+Include descriptive ``\brief`` paragraphs for all public interfaces (public
+classes, member and non-member functions).  Explain API use and purpose in
+``\brief`` paragraphs, don't just restate the information that can be inferred
+from the API name.  Put detailed discussion into separate paragraphs.
+
+To refer to parameter names inside a paragraph, use the ``\p name`` command.
+Don't use the ``\arg name`` command since it starts a new paragraph that
+contains documentation for the parameter.
+
+Wrap non-inline code examples in ``\code ... \endcode``.
+
+To document a function parameter, start a new paragraph with the
+``\param name`` command.  If the parameter is used as an out or an in/out
+parameter, use the ``\param [out] name`` or ``\param [in,out] name`` command,
+respectively.
+
+To describe function return value, start a new paragraph with the ``\returns``
+command.
+
+A minimal documentation comment:
+
+.. code-block:: c++
+
+  /// \brief Does foo and bar.
+  void fooBar(bool Baz);
+
+A documentation comment that uses all Doxygen features in a preferred way:
+
+.. code-block:: c++
+
+  /// \brief Does foo and bar.
+  ///
+  /// Does not do foo the usual way if \p Baz is true.
+  ///
+  /// Typical usage:
+  /// \code
+  ///   fooBar(false, "quux", Res);
+  /// \endcode
+  ///
+  /// \param Quux kind of foo to do.
+  /// \param [out] Result filled with bar sequence on foo success.
+  ///
+  /// \returns true on success.
+  bool fooBar(bool Baz, StringRef Quux, std::vector<int> &Result);
+
+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.
+
+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.
+
+Wrong:
+
+.. code-block:: c++
+
+  // In Something.h:
+
+  /// Something - An abstraction for some complicated thing.
+  class Something {
+  public:
+    /// fooBar - Does foo and bar.
+    void fooBar();
+  };
+
+  // In Something.cpp:
+
+  /// fooBar - Does foo and bar.
+  void Something::fooBar() { ... }
+
+Correct:
+
+.. code-block:: c++
+
+  // In Something.h:
+
+  /// \brief An abstraction for some complicated thing.
+  class Something {
+  public:
+    /// \brief Does foo and bar.
+    void fooBar();
+  };
+
+  // In Something.cpp:
+
+  // Builds a B-tree in order to do foo.  See paper by...
+  void Something::fooBar() { ... }
+
+It is not required to use additional Doxygen features, but sometimes it might
+be a good idea to do so.
+
+Consider:
+
+* adding comments to any narrow namespace containing a collection of
+  related functions or types;
+
+* using top-level groups to organize a collection of related functions at
+  namespace scope where the grouping is smaller than the namespace;
+
+* using member groups and additional comments attached to member
+  groups to organize within a class.
+
+For example:
+
+.. code-block:: c++
+
+  class Something {
+    /// \name Functions that do Foo.
+    /// @{
+    void fooBar();
+    void fooBaz();
+    /// @}
+    ...
+  };
+
+``#include`` Style
+^^^^^^^^^^^^^^^^^^
+
+Immediately after the `header file comment`_ (and include guards if working on a
+header file), the `minimal list of #includes`_ required by the file should be
+listed.  We prefer these ``#include``\s to be listed in this order:
+
+.. _Main Module Header:
+.. _Local/Private Headers:
+
+#. Main Module Header
+#. Local/Private Headers
+#. ``llvm/*``
+#. ``llvm/Analysis/*``
+#. ``llvm/Assembly/*``
+#. ``llvm/Bitcode/*``
+#. ``llvm/CodeGen/*``
+#. ...
+#. ``llvm/Support/*``
+#. ``llvm/Config/*``
+#. System ``#include``\s
+
+and each category should be sorted by name.
+
+The `Main Module Header`_ file applies to ``.cpp`` files which implement an
+interface defined by a ``.h`` file.  This ``#include`` should always be included
+**first** regardless of where it lives on the file system.  By including a
+header file first in the ``.cpp`` files that implement the interfaces, we ensure
+that the header does not have any hidden dependencies which are not explicitly
+``#include``\d in the header, but should be. It is also a form of documentation
+in the ``.cpp`` file to indicate where the interfaces it implements are defined.
+
+.. _fit into 80 columns:
+
+Source Code Width
+^^^^^^^^^^^^^^^^^
+
+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 ``xterm`` without resizing
+it.
+
+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).
+
+This is one of many contentious issues in coding standards, but it is not up for
+debate.
+
+Use Spaces Instead of Tabs
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+As always, follow the `Golden Rule`_ above: follow the style of
+existing code if you are modifying and extending it.  If you like four spaces of
+indentation, **DO NOT** 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.
+
+Indent Code Consistently
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+Compiler Issues
+---------------
+
+Treat Compiler Warnings Like Errors
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+It is not possible to prevent all warnings from all compilers, nor is it
+desirable.  Instead, pick a standard compiler (like ``gcc``) that provides a
+good thorough set of warnings, and stick to it.  At least in the case of
+``gcc``, 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:
+
+.. code-block:: c++
+
+  if (V = getValue()) {
+    ...
+  }
+
+``gcc`` will warn me that I probably want to use the ``==`` 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:
+
+.. code-block:: c++
+
+  if ((V = getValue())) {
+    ...
+  }
+
+which shuts ``gcc`` up.  Any ``gcc`` warning that annoys you can be fixed by
+massaging the code appropriately.
+
+Write Portable Code
+^^^^^^^^^^^^^^^^^^^
+
+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.
+
+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 ``libSystem``.
+
+Do not use RTTI or Exceptions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In an effort to reduce code and executable size, LLVM does not use RTTI
+(e.g. ``dynamic_cast<>;``) or exceptions.  These two language features violate
+the general C++ principle of *"you only pay for what you use"*, 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.
+
+That said, LLVM does make extensive use of a hand-rolled form of RTTI that use
+templates like `isa<>, cast<>, and dyn_cast<> <ProgrammersManual.html#isa>`_.
+This form of RTTI is opt-in and can be added to any class.  It is also
+substantially more efficient than ``dynamic_cast<>``.
+
+.. _static constructor:
+
+Do not use Static Constructors
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 `well known problems
+<http://yosefk.com/c++fqa/ctors.html#fqa-10.12>`_ 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.
+  
+Consider the use of LLVM as a JIT linked into another application (perhaps for
+`OpenGL, custom languages <http://llvm.org/Users.html>`_, `shaders in movies
+<http://llvm.org/devmtg/2010-11/Gritz-OpenShadingLang.pdf>`_, 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:
+
+* The time to run the static constructors impacts startup time of applications
+  --- a critical time for GUI apps, among others.
+  
+* The static constructors cause the app to pull many extra pages of memory off
+  the disk: both the code for the constructor in each ``.o`` 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.
+
+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.
+  
+That said, LLVM unfortunately does contain static constructors.  It would be a
+`great project <http://llvm.org/PR11944>`_ for someone to purge all static
+constructors from LLVM, and then enable the ``-Wglobal-constructors`` warning
+flag (when building with Clang) to ensure we do not regress in the future.
+
+Use of ``class`` and ``struct`` Keywords
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In C++, the ``class`` and ``struct`` keywords can be used almost
+interchangeably. The only difference is when they are used to declare a class:
+``class`` makes all members private by default while ``struct`` makes all
+members public by default.
+
+Unfortunately, not all compilers follow the rules and some will generate
+different symbols based on whether ``class`` or ``struct`` was used to declare
+the symbol.  This can lead to problems at link time.
+
+So, the rule for LLVM is to always use the ``class`` keyword, unless **all**
+members are public and the type is a C++ `POD
+<http://en.wikipedia.org/wiki/Plain_old_data_structure>`_ type, in which case
+``struct`` is allowed.
+
+Style Issues
+============
+
+The High-Level Issues
+---------------------
+
+A Public Header File **is** a Module
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 "``include``" directory), you are
+defining a module of functionality.
+
+Ideally, modules should be completely independent of each other, and their
+header files should only ``#include`` 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.
+
+In general, a module should be implemented by one or more ``.cpp`` files.  Each
+of these ``.cpp`` 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.
+
+.. _minimal list of #includes:
+
+``#include`` as Little as Possible
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``#include`` hurts compile time performance.  Don't do it unless you have to,
+especially in header files.
+
+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 ``#include`` 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 ``#include``\ing speeds up
+compilation.
+
+It is easy to try to go too overboard on this recommendation, however.  You
+**must** 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 **first** in the implementation
+file (as mentioned above).  This way there won't be any hidden dependencies that
+you'll find out about later.
+
+Keep "Internal" Headers Private
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Many modules have a complex implementation that causes them to use more than one
+implementation (``.cpp``) 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!
+
+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.
+
+.. note::
+
+    It's okay to put extra implementation methods in a public class itself. Just
+    make them private (or protected) and all is well.
+
+.. _early exits:
+
+Use Early Exits and ``continue`` to Simplify Code
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 ``continue`` keyword in long loops.  As an example of using an early
+exit from a function, consider this "bad" code:
+
+.. code-block:: c++
+
+  Value *doSomething(Instruction *I) {
+    if (!isa<TerminatorInst>(I) &&
+        I->hasOneUse() && doOtherThing(I)) {
+      ... some long code ....
+    }
+
+    return 0;
+  }
+
+This code has several problems if the body of the ``'if'`` is large.  When
+you're looking at the top of the function, it isn't immediately clear that this
+*only* 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 ``if``
+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.
+
+It is much preferred to format the code like this:
+
+.. code-block:: c++
+
+  Value *doSomething(Instruction *I) {
+    // Terminators never need 'something' done to them because ... 
+    if (isa<TerminatorInst>(I))
+      return 0;
+
+    // We conservatively avoid transforming instructions with multiple uses
+    // because goats like cheese.
+    if (!I->hasOneUse())
+      return 0;
+
+    // This is really just here for example.
+    if (!doOtherThing(I))
+      return 0;
+    
+    ... some long code ....
+  }
+
+This fixes these problems.  A similar problem frequently happens in ``for``
+loops.  A silly example is something like this:
+
+.. code-block:: c++
+
+  for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
+    if (BinaryOperator *BO = dyn_cast<BinaryOperator>(II)) {
+      Value *LHS = BO->getOperand(0);
+      Value *RHS = BO->getOperand(1);
+      if (LHS != RHS) {
+        ...
+      }
+    }
+  }
+
+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 ``if`` conditions will have ``else``\s etc.
+It is strongly preferred to structure the loop like this:
+
+.. code-block:: c++
+
+  for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
+    BinaryOperator *BO = dyn_cast<BinaryOperator>(II);
+    if (!BO) continue;
+
+    Value *LHS = BO->getOperand(0);
+    Value *RHS = BO->getOperand(1);
+    if (LHS == RHS) continue;
+
+    ...
+  }
+
+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 ``else`` coming up that they
+have to push context into their brain for.  If a loop is large, this can be a
+big understandability win.
+
+Don't use ``else`` after a ``return``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For similar reasons above (reduction of indentation and easier reading), please
+do not use ``'else'`` or ``'else if'`` after something that interrupts control
+flow --- like ``return``, ``break``, ``continue``, ``goto``, etc. For
+example, this is *bad*:
+
+.. code-block:: c++
+
+  case 'J': {
+    if (Signed) {
+      Type = Context.getsigjmp_bufType();
+      if (Type.isNull()) {
+        Error = ASTContext::GE_Missing_sigjmp_buf;
+        return QualType();
+      } else {
+        break;
+      }
+    } else {
+      Type = Context.getjmp_bufType();
+      if (Type.isNull()) {
+        Error = ASTContext::GE_Missing_jmp_buf;
+        return QualType();
+      } else {
+        break;
+      }
+    }
+  }
+
+It is better to write it like this:
+
+.. code-block:: c++
+
+  case 'J':
+    if (Signed) {
+      Type = Context.getsigjmp_bufType();
+      if (Type.isNull()) {
+        Error = ASTContext::GE_Missing_sigjmp_buf;
+        return QualType();
+      }
+    } else {
+      Type = Context.getjmp_bufType();
+      if (Type.isNull()) {
+        Error = ASTContext::GE_Missing_jmp_buf;
+        return QualType();
+      }
+    }
+    break;
+
+Or better yet (in this case) as:
+
+.. code-block:: c++
+
+  case 'J':
+    if (Signed)
+      Type = Context.getsigjmp_bufType();
+    else
+      Type = Context.getjmp_bufType();
+    
+    if (Type.isNull()) {
+      Error = Signed ? ASTContext::GE_Missing_sigjmp_buf :
+                       ASTContext::GE_Missing_jmp_buf;
+      return QualType();
+    }
+    break;
+
+The idea is to reduce indentation and the amount of code you have to keep track
+of when reading the code.
+              
+Turn Predicate Loops into Predicate Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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:
+
+.. code-block:: c++
+
+  bool FoundFoo = false;
+  for (unsigned i = 0, e = BarList.size(); i != e; ++i)
+    if (BarList[i]->isFoo()) {
+      FoundFoo = true;
+      break;
+    }
+
+  if (FoundFoo) {
+    ...
+  }
+
+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 `static`_) that uses `early exits`_ to compute the predicate.  We prefer the
+code to be structured like this:
+
+.. code-block:: c++
+
+  /// \returns true if the specified list has an element that is a foo.
+  static bool containsFoo(const std::vector<Bar*> &List) {
+    for (unsigned i = 0, e = List.size(); i != e; ++i)
+      if (List[i]->isFoo())
+        return true;
+    return false;
+  }
+  ...
+
+  if (containsFoo(BarList)) {
+    ...
+  }
+
+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 *forces you to pick a name* 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.
+
+The Low-Level Issues
+--------------------
+
+Name Types, Functions, Variables, and Enumerators Properly
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Poorly-chosen names can mislead the reader and cause bugs. We cannot stress
+enough how important it is to use *descriptive* 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.
+
+In general, names should be in camel case (e.g. ``TextFileReader`` and
+``isLValue()``).  Different kinds of declarations have different rules:
+
+* **Type names** (including classes, structs, enums, typedefs, etc) should be
+  nouns and start with an upper-case letter (e.g. ``TextFileReader``).
+
+* **Variable names** should be nouns (as they represent state).  The name should
+  be camel case, and start with an upper case letter (e.g. ``Leader`` or
+  ``Boats``).
+  
+* **Function names** 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. ``openFile()`` or ``isFoo()``).
+
+* **Enum declarations** (e.g. ``enum Foo {...}``) 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 ``Kind`` suffix
+  (e.g. ``ValueKind``).
+  
+* **Enumerators** (e.g. ``enum { Foo, Bar }``) and **public member variables**
+  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, ``enum ValueKind { ... };`` may contain enumerators like
+  ``VK_Argument``, ``VK_BasicBlock``, etc.  Enumerators that are just
+  convenience constants are exempt from the requirement for a prefix.  For
+  instance:
+
+  .. code-block:: c++
+
+      enum {
+        MaxSize = 42,
+        Density = 12
+      };
+  
+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. ``begin()``,
+``push_back()``, and ``empty()``).
+
+Here are some examples of good and bad names:
+
+.. code-block:: c++
+
+  class VehicleMaker {
+    ...
+    Factory<Tire> F;            // Bad -- abbreviation and non-descriptive.
+    Factory<Tire> Factory;      // Better.
+    Factory<Tire> TireFactory;  // Even better -- if VehicleMaker has more than one
+                                // kind of factories.
+  };
+
+  Vehicle MakeVehicle(VehicleType Type) {
+    VehicleMaker M;                         // Might be OK if having a short life-span.
+    Tire tmp1 = M.makeTire();               // Bad -- 'tmp1' provides no information.
+    Light headlight = M.makeLight("head");  // Good -- descriptive.
+    ...
+  }
+
+Assert Liberally
+^^^^^^^^^^^^^^^^
+
+Use the "``assert``" 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
+"``<cassert>``" header file is probably already included by the header files you
+are using, so it doesn't cost anything to use it.
+
+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:
+
+.. code-block:: c++
+
+  inline Value *getOperand(unsigned i) { 
+    assert(i < Operands.size() && "getOperand() out of range!");
+    return Operands[i]; 
+  }
+
+Here are more examples:
+
+.. code-block:: c++
+
+  assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+
+  assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
+
+  assert(idx < getNumSuccessors() && "Successor # out of range!");
+
+  assert(V1.getType() == V2.getType() && "Constant types must be identical!");
+
+  assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!");
+
+You get the idea.
+
+In the past, asserts were used to indicate a piece of code that should not be
+reached.  These were typically of the form:
+
+.. code-block:: c++
+
+  assert(0 && "Invalid radix for integer literal");
+
+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.
+
+Today, we have something much better: ``llvm_unreachable``:
+
+.. code-block:: c++
+
+  llvm_unreachable("Invalid radix for integer literal");
+
+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), ``llvm_unreachable`` 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.
+
+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:
+
+.. code-block:: c++
+
+  unsigned Size = V.size();
+  assert(Size > 42 && "Vector smaller than it should be");
+
+  bool NewToSet = Myset.insert(Value);
+  assert(NewToSet && "The value shouldn't be in the set yet");
+
+These are two interesting different cases. In the first case, the call to
+``V.size()`` 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:
+
+.. code-block:: c++
+
+  assert(V.size() > 42 && "Vector smaller than it should be");
+
+  bool NewToSet = Myset.insert(Value); (void)NewToSet;
+  assert(NewToSet && "The value shouldn't be in the set yet");
+
+Do Not Use ``using namespace std``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In LLVM, we prefer to explicitly prefix all identifiers from the standard
+namespace with an "``std::``" prefix, rather than rely on "``using namespace
+std;``".
+
+In header files, adding a ``'using namespace XXX'`` directive pollutes the
+namespace of any source file that ``#include``\s the header.  This is clearly a
+bad thing.
+
+In implementation files (e.g. ``.cpp`` files), the rule is more of a stylistic
+rule, but is still important.  Basically, using explicit namespace prefixes
+makes the code **clearer**, because it is immediately obvious what facilities
+are being used and where they are coming from. And **more portable**, 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 ``std`` namespace.  As such, we
+never use ``'using namespace std;'`` in LLVM.
+
+The exception to the general rule (i.e. it's not an exception for the ``std``
+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 ``.cpp`` files to have a ``'using namespace
+llvm;'`` directive at the top, after the ``#include``\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 ``.cpp`` file that implements code in any namespace may use that
+namespace (and its parents'), but should not use any others.
+
+Provide a Virtual Method Anchor for Classes in Headers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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 ``.o`` file that ``#include``\s the
+header, bloating ``.o`` file sizes and increasing link times.
+
+Don't use default labels in fully covered switches over enumerations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``-Wswitch`` 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 ``-Wswitch`` warning won't fire
+when new elements are added to that enumeration. To help avoid adding these
+kinds of defaults, Clang has the warning ``-Wcovered-switch-default`` which is
+off by default but turned on when building LLVM with a version of Clang that
+supports the warning.
+
+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 ``llvm_unreachable`` after
+the switch.
+
+Use ``LLVM_DELETED_FUNCTION`` to mark uncallable methods
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Prior to C++11, a common pattern to make a class uncopyable was to declare an
+unimplemented copy constructor and copy assignment operator and make them
+private. This would give a compiler error for accessing a private method or a
+linker error because it wasn't implemented.
+
+With C++11, we can mark methods that won't be implemented with ``= delete``.
+This will trigger a much better error message and tell the compiler that the
+method will never be implemented. This enables other checks like
+``-Wunused-private-field`` to run correctly on classes that contain these
+methods.
+
+To maintain compatibility with C++03, ``LLVM_DELETED_FUNCTION`` should be used
+which will expand to ``= delete`` if the compiler supports it. These methods
+should still be declared private. Example of the uncopyable pattern:
+
+.. code-block:: c++
+
+  class DontCopy {
+  private:
+    DontCopy(const DontCopy&) LLVM_DELETED_FUNCTION;
+    DontCopy &operator =(const DontCopy&) LLVM_DELETED_FUNCTION;
+  public:
+    ...
+  };
+
+Don't evaluate ``end()`` every time through a loop
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Because C++ doesn't have a standard "``foreach``" 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:
+
+.. code-block:: c++
+
+  BasicBlock *BB = ...
+  for (BasicBlock::iterator I = BB->begin(); I != BB->end(); ++I)
+    ... use I ...
+
+The problem with this construct is that it evaluates "``BB->end()``" 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:
+
+.. code-block:: c++
+
+  BasicBlock *BB = ...
+  for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I)
+    ... use I ...
+
+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
+"``BB->end()``" 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.
+
+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: "``SomeMap[x]->end()``" 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.
+
+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.
+
+While the second form of the loop is a few extra keystrokes, we do strongly
+prefer it.
+
+``#include <iostream>`` is Forbidden
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The use of ``#include <iostream>`` in library files is hereby **forbidden**,
+because many common implementations transparently inject a `static constructor`_
+into every translation unit that includes it.
+  
+Note that using the other stream headers (``<sstream>`` for example) is not
+problematic in this regard --- just ``<iostream>``. However, ``raw_ostream``
+provides various APIs that are better performing for almost every use than
+``std::ostream`` style APIs.
+
+.. note::
+
+  New code should always use `raw_ostream`_ for writing, or the
+  ``llvm::MemoryBuffer`` API for reading files.
+
+.. _raw_ostream:
+
+Use ``raw_ostream``
+^^^^^^^^^^^^^^^^^^^
+
+LLVM includes a lightweight, simple, and efficient stream implementation in
+``llvm/Support/raw_ostream.h``, which provides all of the common features of
+``std::ostream``.  All new code should use ``raw_ostream`` instead of
+``ostream``.
+
+Unlike ``std::ostream``, ``raw_ostream`` is not a template and can be forward
+declared as ``class raw_ostream``.  Public headers should generally not include
+the ``raw_ostream`` header, but use forward declarations and constant references
+to ``raw_ostream`` instances.
+
+Avoid ``std::endl``
+^^^^^^^^^^^^^^^^^^^
+
+The ``std::endl`` modifier, when used with ``iostreams`` 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:
+
+.. code-block:: c++
+
+  std::cout << std::endl;
+  std::cout << '\n' << std::flush;
+
+Most of the time, you probably have no reason to flush the output stream, so
+it's better to use a literal ``'\n'``.
+
+Microscopic Details
+-------------------
+
+This section describes preferred low-level formatting guidelines along with
+reasoning on why we prefer them.
+
+Spaces Before Parentheses
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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:
+
+.. code-block:: c++
+
+  if (x) ...
+  for (i = 0; i != 100; ++i) ...
+  while (llvm_rocks) ...
+
+  somefunc(42);
+  assert(3 != 4 && "laws of math are failing me");
+  
+  a = foo(42, 92) + bar(x);
+
+and this is bad:
+
+.. code-block:: c++
+
+  if(x) ...
+  for(i = 0; i != 100; ++i) ...
+  while(llvm_rocks) ...
+
+  somefunc (42);
+  assert (3 != 4 && "laws of math are failing me");
+  
+  a = foo (42, 92) + bar (x);
+
+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 "``a``" example as:
+
+.. code-block:: c++
+
+  a = foo ((42, 92) + bar) (x);
+
+when skimming through the code.  By avoiding a space in a function, we avoid
+this misinterpretation.
+
+Prefer Preincrement
+^^^^^^^^^^^^^^^^^^^
+
+Hard fast rule: Preincrement (``++X``) may be no slower than postincrement
+(``X++``) and could very well be a lot faster than it.  Use preincrementation
+whenever possible.
+
+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.
+
+
+Namespace Indentation
+^^^^^^^^^^^^^^^^^^^^^
+
+In general, we strive to reduce indentation wherever possible.  This is useful
+because we want code to `fit into 80 columns`_ without wrapping horribly, but
+also because it makes it easier to understand the code.  Namespaces are a funny
+thing: they are often large, and we often desire to put lots of stuff into them
+(so they can be large).  Other times they are tiny, because they just hold an
+enum or something similar.  In order to balance this, we use different
+approaches for small versus large namespaces.
+
+If a namespace definition is small and *easily* fits on a screen (say, less than
+35 lines of code), then you should indent its body.  Here's an example:
+
+.. code-block:: c++
+
+  namespace llvm {
+    namespace X86 {
+      /// \brief An enum for the x86 relocation codes.  Note that
+      /// the terminology here doesn't follow x86 convention - word means
+      /// 32-bit and dword means 64-bit.
+      enum RelocationType {
+        /// \brief PC relative relocation, add the relocated value to
+        /// the value already in memory, after we adjust it for where the PC is.
+        reloc_pcrel_word = 0,
+
+        /// \brief PIC base relative relocation, add the relocated value to
+        /// the value already in memory, after we adjust it for where the
+        /// PIC base is.
+        reloc_picrel_word = 1,
+
+        /// \brief Absolute relocation, just add the relocated value to the
+        /// value already in memory.
+        reloc_absolute_word = 2,
+        reloc_absolute_dword = 3
+      };
+    }
+  }
+
+Since the body is small, indenting adds value because it makes it very clear
+where the namespace starts and ends, and it is easy to take the whole thing in
+in one "gulp" when reading the code.  If the blob of code in the namespace is
+larger (as it typically is in a header in the ``llvm`` or ``clang`` namespaces),
+do not indent the code, and add a comment indicating what namespace is being
+closed.  For example:
+
+.. code-block:: c++
+
+  namespace llvm {
+  namespace knowledge {
+
+  /// This class represents things that Smith can have an intimate
+  /// understanding of and contains the data associated with it.
+  class Grokable {
+  ...
+  public:
+    explicit Grokable() { ... }
+    virtual ~Grokable() = 0;
+  
+    ...
+
+  };
+
+  } // end namespace knowledge
+  } // end namespace llvm
+
+Because the class is large, we don't expect that the reader can easily
+understand the entire concept in a glance, and the end of the file (where the
+namespaces end) may be a long ways away from the place they open.  As such,
+indenting the contents of the namespace doesn't add any value, and detracts from
+the readability of the class.  In these cases it is best to *not* indent the
+contents of the namespace.
+
+.. _static:
+
+Anonymous Namespaces
+^^^^^^^^^^^^^^^^^^^^
+
+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 "``static``"
+is available in C++, anonymous namespaces are more general: they can make entire
+classes private to a file.
+
+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.
+
+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:
+
+.. code-block:: c++
+
+  namespace {
+    class StringSort {
+    ...
+    public:
+      StringSort(...)
+      bool operator<(const char *RHS) const;
+    };
+  } // end anonymous namespace
+
+  static void runHelper() { 
+    ... 
+  }
+
+  bool StringSort::operator<(const char *RHS) const {
+    ...
+  }
+
+This is bad:
+
+.. code-block:: c++
+
+  namespace {
+  class StringSort {
+  ...
+  public:
+    StringSort(...)
+    bool operator<(const char *RHS) const;
+  };
+
+  void runHelper() { 
+    ... 
+  }
+
+  bool StringSort::operator<(const char *RHS) const {
+    ...
+  }
+
+  } // end anonymous namespace
+
+This is bad specifically because if you're looking at "``runHelper``" 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 "``operator<``" in the
+namespace just because it was declared there.
+
+See Also
+========
+
+A lot of these comments and recommendations have been culled for other sources.
+Two particularly important books for our work are:
+
+#. `Effective C++
+   <http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876>`_
+   by Scott Meyers.  Also interesting and useful are "More Effective C++" and
+   "Effective STL" by the same author.
+
+#. `Large-Scale C++ Software Design
+   <http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620/ref=sr_1_1>`_
+   by John Lakos
+
+If you get some free time, and you haven't read them: do so, you might learn
+something.

Added: www-releases/trunk/3.2/docs/CommandGuide/FileCheck.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/FileCheck.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/FileCheck.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/FileCheck.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,290 @@
+FileCheck - Flexible pattern matching file verifier
+===================================================
+
+
+SYNOPSIS
+--------
+
+
+**FileCheck** *match-filename* [*--check-prefix=XXX*] [*--strict-whitespace*]
+
+
+DESCRIPTION
+-----------
+
+
+**FileCheck** 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. llc) contains the expected information (for example, a movsd from esp or
+whatever is interesting).  This is similar to using grep, but it is optimized
+for matching multiple different inputs in one file in a specific order.
+
+The *match-filename* file specifies the file that contains the patterns to
+match.  The file to verify is always read from standard input.
+
+
+OPTIONS
+-------
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**--check-prefix** *prefix*
+
+ FileCheck searches the contents of *match-filename* for patterns to match.  By
+ default, these patterns are prefixed with "CHECK:".  If you'd like to use a
+ different prefix (e.g. because the same input file is checking multiple
+ different tool or options), the **--check-prefix** argument allows you to specify
+ a specific prefix to match.
+
+
+
+**--input-file** *filename*
+
+  File to check (defaults to stdin).
+
+
+**--strict-whitespace**
+
+ By default, FileCheck canonicalizes input horizontal whitespace (spaces and
+ tabs) which causes it to ignore these differences (a space will match a tab).
+ The --strict-whitespace argument disables this behavior.
+
+
+
+**-version**
+
+ Show the version number of this program.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **FileCheck** 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.
+
+
+TUTORIAL
+--------
+
+
+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:
+
+
+.. code-block:: llvm
+
+   ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s
+
+
+This syntax says to pipe the current file ("%s") into llvm-as, pipe that into
+llc, then pipe the output of llc into FileCheck.  This means that FileCheck will
+be verifying its standard input (the llc output) against the filename argument
+specified (the original .ll file specified by "%s").  To see how this works,
+let's look at the rest of the .ll file (after the RUN line):
+
+
+.. code-block:: llvm
+
+   define void @sub1(i32* %p, i32 %v) {
+   entry:
+   ; CHECK: sub1:
+   ; CHECK: subl
+           %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
+           ret void
+   }
+
+   define void @inc4(i64* %p) {
+   entry:
+   ; CHECK: inc4:
+   ; CHECK: incq
+           %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
+           ret void
+   }
+
+
+Here you can see some "CHECK:" lines specified in comments.  Now you can see
+how the file is piped into llvm-as, then llc, and the machine code output is
+what we are verifying.  FileCheck checks the machine code output to verify that
+it matches what the "CHECK:" lines specify.
+
+The syntax of the CHECK: 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 CHECK: line is required to match some thing in the test file exactly.
+
+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 "sub1:" and "inc4:" labels, it will not match unless there
+is a "subl" in between those labels.  If it existed somewhere else in the file,
+that would not count: "grep subl" matches if subl exists anywhere in the
+file.
+
+The FileCheck -check-prefix option
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+The FileCheck -check-prefix option allows multiple test configurations to be
+driven from one .ll file.  This is useful in many circumstances, for example,
+testing different architectural variants with llc.  Here's a simple example:
+
+
+.. code-block:: llvm
+
+   ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
+   ; RUN:              | FileCheck %s -check-prefix=X32
+   ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
+   ; RUN:              | FileCheck %s -check-prefix=X64
+
+   define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
+           %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
+           ret <4 x i32> %tmp1
+   ; X32: pinsrd_1:
+   ; X32:    pinsrd $1, 4(%esp), %xmm0
+
+   ; X64: pinsrd_1:
+   ; X64:    pinsrd $1, %edi, %xmm0
+   }
+
+
+In this case, we're testing that we get the expected code generation with
+both 32-bit and 64-bit code generation.
+
+
+The "CHECK-NEXT:" directive
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+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 CHECK: and CHECK-NEXT: directives to specify this.  If
+you specified a custom check prefix, just use "<PREFIX>-NEXT:".  For
+example, something like this works as you'd expect:
+
+
+.. code-block:: llvm
+
+   define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
+ 	%tmp3 = load <2 x double>* %A, align 16
+ 	%tmp7 = insertelement <2 x double> undef, double %B, i32 0
+ 	%tmp9 = shufflevector <2 x double> %tmp3,
+                               <2 x double> %tmp7,
+                               <2 x i32> < i32 0, i32 2 >
+ 	store <2 x double> %tmp9, <2 x double>* %r, align 16
+ 	ret void
+
+   ; CHECK:          t2:
+   ; CHECK: 	        movl	8(%esp), %eax
+   ; CHECK-NEXT: 	movapd	(%eax), %xmm0
+   ; CHECK-NEXT: 	movhpd	12(%esp), %xmm0
+   ; CHECK-NEXT: 	movl	4(%esp), %eax
+   ; CHECK-NEXT: 	movapd	%xmm0, (%eax)
+   ; CHECK-NEXT: 	ret
+   }
+
+
+CHECK-NEXT: directives reject the input unless there is exactly one newline
+between it an the previous directive.  A CHECK-NEXT cannot be the first
+directive in a file.
+
+
+The "CHECK-NOT:" directive
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+The CHECK-NOT: 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:
+
+
+.. code-block:: llvm
+
+   define i8 @coerce_offset0(i32 %V, i32* %P) {
+     store i32 %V, i32* %P
+
+     %P2 = bitcast i32* %P to i8*
+     %P3 = getelementptr i8* %P2, i32 2
+
+     %A = load i8* %P3
+     ret i8 %A
+   ; CHECK: @coerce_offset0
+   ; CHECK-NOT: load
+   ; CHECK: ret i8
+   }
+
+
+
+FileCheck Pattern Matching Syntax
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+The CHECK: and CHECK-NOT: directives both take a pattern to match.  For most
+uses of FileCheck, fixed string matching is perfectly sufficient.  For some
+things, a more flexible form of matching is desired.  To support this, FileCheck
+allows you to specify regular expressions in matching strings, surrounded by
+double braces: **{{yourregex}}**.  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:
+
+
+.. code-block:: llvm
+
+   ; CHECK: movhpd	{{[0-9]+}}(%esp), {{%xmm[0-7]}}
+
+
+In this case, any offset from the ESP register will be allowed, and any xmm
+register will be allowed.
+
+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
+**{{[{][{]}}** as your pattern.
+
+
+FileCheck Variables
+~~~~~~~~~~~~~~~~~~~
+
+
+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, FileCheck
+allows named variables to be defined and substituted into patterns.  Here is a
+simple example:
+
+
+.. code-block:: llvm
+
+   ; CHECK: test5:
+   ; CHECK:    notw	[[REGISTER:%[a-z]+]]
+   ; CHECK:    andw	{{.*}}[[REGISTER]]
+
+
+The first check line matches a regex (**%[a-z]+**) and captures it into
+the variable "REGISTER".  The second line verifies that whatever is in REGISTER
+occurs later in the file after an "andw".  FileCheck variable references are
+always contained in **[[ ]]** pairs, and their names can be formed with the
+regex **[a-zA-Z][a-zA-Z0-9]***.  If a colon follows the name, then it is a
+definition of the variable; otherwise, it is a use.
+
+FileCheck variables can be defined multiple times, and uses always get the
+latest value.  Note that variables are all read at the start of a "CHECK" line
+and are all defined at the end.  This means that if you have something like
+"**CHECK: [[XYZ:.\\*]]x[[XYZ]]**", the check line will read the previous
+value of the XYZ variable and define a new one after the match is performed.  If
+you need to do something like this you can probably take advantage of the fact
+that FileCheck is not actually line-oriented when it matches, this allows you to
+define two separate CHECK lines that match on the same line.

Added: www-releases/trunk/3.2/docs/CommandGuide/bugpoint.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/bugpoint.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/bugpoint.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/bugpoint.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,247 @@
+bugpoint - automatic test case reduction tool
+=============================================
+
+
+SYNOPSIS
+--------
+
+
+**bugpoint** [*options*] [*input LLVM ll/bc files*] [*LLVM passes*] **--args**
+*program arguments*
+
+
+DESCRIPTION
+-----------
+
+
+**bugpoint** 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 **bugpoint**, as well as
+advice for using bugpoint, see *llvm/docs/Bugpoint.html* in the LLVM
+distribution.
+
+
+OPTIONS
+-------
+
+
+
+**--additional-so** *library*
+
+ Load the dynamic shared object *library* 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.
+
+
+
+**--append-exit-code**\ =\ *{true,false}*
+
+ 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.
+
+
+
+**--args** *program args*
+
+ Pass all arguments specified after -args to the test program whenever it runs.
+ Note that if any of the *program args* start with a '-', you should use:
+
+
+ .. code-block:: perl
+
+      bugpoint [bugpoint args] --args -- [program args]
+
+
+ The "--" right after the **--args** option tells **bugpoint** to consider any
+ options starting with ``-`` to be part of the **--args** option, not as options to
+ **bugpoint** itself.
+
+
+
+**--tool-args** *tool args*
+
+ Pass all arguments specified after --tool-args to the LLVM tool under test
+ (**llc**, **lli**, etc.) whenever it runs.  You should use this option in the
+ following way:
+
+
+ .. code-block:: perl
+
+      bugpoint [bugpoint args] --tool-args -- [tool args]
+
+
+ The "--" right after the **--tool-args** option tells **bugpoint** to consider any
+ options starting with ``-`` to be part of the **--tool-args** option, not as
+ options to **bugpoint** itself. (See **--args**, above.)
+
+
+
+**--safe-tool-args** *tool args*
+
+ Pass all arguments specified after **--safe-tool-args** to the "safe" execution
+ tool.
+
+
+
+**--gcc-tool-args** *gcc tool args*
+
+ Pass all arguments specified after **--gcc-tool-args** to the invocation of
+ **gcc**.
+
+
+
+**--opt-args** *opt args*
+
+ Pass all arguments specified after **--opt-args** to the invocation of **opt**.
+
+
+
+**--disable-{dce,simplifycfg}**
+
+ Do not run the specified passes to clean up and reduce the size of the test
+ program. By default, **bugpoint** uses these passes internally when attempting to
+ reduce test programs.  If you're trying to find a bug in one of these passes,
+ **bugpoint** may crash.
+
+
+
+**--enable-valgrind**
+
+ Use valgrind to find faults in the optimization phase. This will allow
+ bugpoint to find otherwise asymptomatic problems caused by memory
+ mis-management.
+
+
+
+**-find-bugs**
+
+ Continually randomize the specified passes and run them on the test program
+ until a bug is found or the user kills **bugpoint**.
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**--input** *filename*
+
+ Open *filename* and redirect the standard input of the test program, whenever
+ it runs, to come from that file.
+
+
+
+**--load** *plugin*
+
+ Load the dynamic object *plugin* into **bugpoint** 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 **-help** and **--load** options together; for example:
+
+
+ .. code-block:: perl
+
+      bugpoint --load myNewPass.so -help
+
+
+
+
+**--mlimit** *megabytes*
+
+ Specifies an upper limit on memory usage of the optimization and codegen. Set
+ to zero to disable the limit.
+
+
+
+**--output** *filename*
+
+ Whenever the test program produces output on its standard output stream, it
+ should match the contents of *filename* (the "reference output"). If you
+ do not use this option, **bugpoint** will attempt to generate a reference output
+ by compiling the program with the "safe" backend and running it.
+
+
+
+**--profile-info-file** *filename*
+
+ Profile file loaded by **--profile-loader**.
+
+
+
+**--run-{int,jit,llc,custom}**
+
+ Whenever the test program is compiled, **bugpoint** 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 **--exec-command**) respectively.
+
+
+
+**--safe-{llc,custom}**
+
+ When debugging a code generator, **bugpoint** 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 **--exec-command**)
+ respectively. The interpreter and the JIT backends cannot currently
+ be used as the "safe" backends.
+
+
+
+**--exec-command** *command*
+
+ This option defines the command to use with the **--run-custom** and
+ **--safe-custom** options to execute the bitcode testcase. This can
+ be useful for cross-compilation.
+
+
+
+**--compile-command** *command*
+
+ This option defines the command to use with the **--compile-custom**
+ option to compile the bitcode testcase. This can be useful for
+ testing compiler output without running any link or execute stages. To
+ generate a reduced unit test, you may add CHECK directives to the
+ testcase and pass the name of an executable compile-command script in this form:
+
+
+ .. code-block:: sh
+
+      #!/bin/sh
+      llc "$@"
+      not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
+
+
+ This script will "fail" as long as FileCheck passes. So the result
+ will be the minimum bitcode that passes FileCheck.
+
+
+
+**--safe-path** *path*
+
+ This option defines the path to the command to execute with the
+ **--safe-{int,jit,llc,custom}**
+ option.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **bugpoint** succeeds in finding a problem, it will exit with 0.  Otherwise,
+if an error occurs, it will exit with a non-zero value.
+
+
+SEE ALSO
+--------
+
+
+opt|opt

Added: www-releases/trunk/3.2/docs/CommandGuide/index.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/index.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/index.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/index.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,53 @@
+.. _commands:
+
+LLVM Command Guide
+------------------
+
+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 ``--help`` (general options) or
+``--help-hidden`` (general and debugging options) arguments to the tool you are
+interested in.
+
+Basic Commands
+~~~~~~~~~~~~~~
+
+.. toctree::
+   :maxdepth: 1
+
+   llvm-as
+   llvm-dis
+   opt
+   llc
+   lli
+   llvm-link
+   llvm-ar
+   llvm-ranlib
+   llvm-nm
+   llvm-prof
+   llvm-config
+   llvm-diff
+   llvm-cov
+   llvm-stress
+
+Debugging Tools
+~~~~~~~~~~~~~~~
+
+.. toctree::
+   :maxdepth: 1
+
+   bugpoint
+   llvm-extract
+   llvm-bcanalyzer
+
+Developer Tools
+~~~~~~~~~~~~~~~
+
+.. toctree::
+   :maxdepth: 1
+
+   FileCheck
+   tblgen
+   lit
+   llvm-build

Added: www-releases/trunk/3.2/docs/CommandGuide/lit.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/lit.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/lit.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/lit.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,487 @@
+lit - LLVM Integrated Tester
+============================
+
+
+SYNOPSIS
+--------
+
+
+**lit** [*options*] [*tests*]
+
+
+DESCRIPTION
+-----------
+
+
+**lit** is a portable tool for executing LLVM and Clang style test suites,
+summarizing their results, and providing indication of failures. **lit** is
+designed to be a lightweight testing tool with as simple a user interface as
+possible.
+
+**lit** should be run with one or more *tests* to run specified on the command
+line. Tests can be either individual test files or directories to search for
+tests (see "TEST DISCOVERY").
+
+Each specified test will be executed (potentially in parallel) and once all
+tests have been run **lit** will print summary information on the number of tests
+which passed or failed (see "TEST STATUS RESULTS"). The **lit** program will
+execute with a non-zero exit code if any tests fail.
+
+By default **lit** will use a succinct progress display and will only print
+summary information for test failures. See "OUTPUT OPTIONS" for options
+controlling the **lit** progress display and output.
+
+**lit** also includes a number of options for controlling how tests are executed
+(specific features may depend on the particular test format). See "EXECUTION
+OPTIONS" for more information.
+
+Finally, **lit** also supports additional options for only running a subset of
+the options specified on the command line, see "SELECTION OPTIONS" for
+more information.
+
+Users interested in the **lit** architecture or designing a **lit** testing
+implementation should see "LIT INFRASTRUCTURE"
+
+
+GENERAL OPTIONS
+---------------
+
+
+
+**-h**, **--help**
+
+ Show the **lit** help message.
+
+
+
+**-j** *N*, **--threads**\ =\ *N*
+
+ Run *N* tests in parallel. By default, this is automatically chosen to match
+ the number of detected available CPUs.
+
+
+
+**--config-prefix**\ =\ *NAME*
+
+ Search for *NAME.cfg* and *NAME.site.cfg* when searching for test suites,
+ instead of *lit.cfg* and *lit.site.cfg*.
+
+
+
+**--param** *NAME*, **--param** *NAME*\ =\ *VALUE*
+
+ Add a user defined parameter *NAME* with the given *VALUE* (or the empty
+ string if not given). The meaning and use of these parameters is test suite
+ dependent.
+
+
+
+
+OUTPUT OPTIONS
+--------------
+
+
+
+**-q**, **--quiet**
+
+ Suppress any output except for test failures.
+
+
+
+**-s**, **--succinct**
+
+ Show less output, for example don't show information on tests that pass.
+
+
+
+**-v**, **--verbose**
+
+ Show more information on test failures, for example the entire test output
+ instead of just the test result.
+
+
+
+**--no-progress-bar**
+
+ Do not use curses based progress bar.
+
+
+
+
+EXECUTION OPTIONS
+-----------------
+
+
+
+**--path**\ =\ *PATH*
+
+ Specify an addition *PATH* to use when searching for executables in tests.
+
+
+
+**--vg**
+
+ Run individual tests under valgrind (using the memcheck tool). The
+ *--error-exitcode* argument for valgrind is used so that valgrind failures will
+ cause the program to exit with a non-zero status.
+
+ When this option is enabled, **lit** will also automatically provide a
+ "valgrind" feature that can be used to conditionally disable (or expect failure
+ in) certain tests.
+
+
+
+**--vg-arg**\ =\ *ARG*
+
+ When *--vg* is used, specify an additional argument to pass to valgrind itself.
+
+
+
+**--vg-leak**
+
+ When *--vg* is used, enable memory leak checks. When this option is enabled,
+ **lit** will also automatically provide a "vg_leak" feature that can be
+ used to conditionally disable (or expect failure in) certain tests.
+
+
+
+
+**--time-tests**
+
+ 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 *-j
+ 1*.
+
+
+
+
+SELECTION OPTIONS
+-----------------
+
+
+
+**--max-tests**\ =\ *N*
+
+ Run at most *N* tests and then terminate.
+
+
+
+**--max-time**\ =\ *N*
+
+ Spend at most *N* seconds (approximately) running tests and then terminate.
+
+
+
+**--shuffle**
+
+ Run the tests in a random order.
+
+
+
+
+ADDITIONAL OPTIONS
+------------------
+
+
+
+**--debug**
+
+ Run **lit** in debug mode, for debugging configuration issues and **lit** itself.
+
+
+
+**--show-suites**
+
+ List the discovered test suites as part of the standard output.
+
+
+
+**--no-tcl-as-sh**
+
+ Run Tcl scripts internally (instead of converting to shell scripts).
+
+
+
+**--repeat**\ =\ *N*
+
+ Run each test *N* times. Currently this is primarily useful for timing tests,
+ other results are not collated in any reasonable fashion.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+**lit** 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).
+
+
+TEST DISCOVERY
+--------------
+
+
+The inputs passed to **lit** can be either individual tests, or entire
+directories or hierarchies of tests to run. When **lit** starts up, the first
+thing it does is convert the inputs into a complete list of tests to run as part
+of *test discovery*.
+
+In the **lit** model, every test must exist inside some *test suite*. **lit**
+resolves the inputs specified on the command line to test suites by searching
+upwards from the input path until it finds a *lit.cfg* or *lit.site.cfg*
+file. These files serve as both a marker of test suites and as configuration
+files which **lit** loads in order to understand how to find and run the tests
+inside the test suite.
+
+Once **lit** 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.
+
+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, **lit** always identifies tests by the test suite they
+are in, and their relative path inside the test suite. For appropriately
+configured projects, this allows **lit** to provide convenient and flexible
+support for out-of-tree builds.
+
+
+TEST STATUS RESULTS
+-------------------
+
+
+Each test ultimately produces one of the following six results:
+
+
+**PASS**
+
+ The test succeeded.
+
+
+
+**XFAIL**
+
+ 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.
+
+
+
+**XPASS**
+
+ 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).
+
+
+
+**FAIL**
+
+ The test failed.
+
+
+
+**UNRESOLVED**
+
+ 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.
+
+
+
+**UNSUPPORTED**
+
+ The test is not supported in this environment. This is used by test formats
+ which can report unsupported tests.
+
+
+
+Depending on the test format tests may produce additional information about
+their status (generally only for failures). See the Output|"OUTPUT OPTIONS"
+section for more information.
+
+
+LIT INFRASTRUCTURE
+------------------
+
+
+This section describes the **lit** testing architecture for users interested in
+creating a new **lit** testing implementation, or extending an existing one.
+
+**lit** proper is primarily an infrastructure for discovering and running
+arbitrary tests, and to expose a single convenient interface to these
+tests. **lit** itself doesn't know how to run tests, rather this logic is
+defined by *test suites*.
+
+TEST SUITES
+~~~~~~~~~~~
+
+
+As described in "TEST DISCOVERY", tests are always located inside a *test
+suite*. 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.
+
+**lit** identifies test suites as directories containing *lit.cfg* or
+*lit.site.cfg* files (see also **--config-prefix**). 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 **--show-suites** to display the
+discovered test suites at startup.
+
+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:
+
+
+**lit**
+
+ The global **lit** configuration object (a *LitConfig* instance), which defines
+ the builtin test formats, global configuration parameters, and other helper
+ routines for implementing test configurations.
+
+
+
+**config**
+
+ This is the config object (a *TestingConfig* instance) for the test suite,
+ which the config file is expected to populate. The following variables are also
+ available on the *config* object, some of which must be set by the config and
+ others are optional or predefined:
+
+ **name** *[required]* The name of the test suite, for use in reports and
+ diagnostics.
+
+ **test_format** *[required]* 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 *lit.formats* module.
+
+ **test_src_root** The filesystem path to the test suite root. For out-of-dir
+ builds this is the directory that will be scanned for tests.
+
+ **test_exec_root** 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.
+
+ **environment** A dictionary representing the environment to use when executing
+ tests in the suite.
+
+ **suffixes** For **lit** test formats which scan directories for tests, this
+ variable is a list of suffixes to identify test files. Used by: *ShTest*,
+ *TclTest*.
+
+ **substitutions** For **lit** test formats which substitute variables into a test
+ script, the list of substitutions to perform. Used by: *ShTest*, *TclTest*.
+
+ **unsupported** Mark an unsupported directory, all tests within it will be
+ reported as unsupported. Used by: *ShTest*, *TclTest*.
+
+ **parent** The parent configuration, this is the config object for the directory
+ containing the test suite, or None.
+
+ **root** The root configuration. This is the top-most **lit** configuration in
+ the project.
+
+ **on_clone** The config is actually cloned for every subdirectory inside a test
+ suite, to allow local configuration on a per-directory basis. The *on_clone*
+ variable can be set to a Python function which will be called whenever a
+ configuration is cloned (for a subdirectory). The function should takes three
+ arguments: (1) the parent configuration, (2) the new configuration (which the
+ *on_clone* function will generally modify), and (3) the test path to the new
+ directory being scanned.
+
+
+
+
+TEST DISCOVERY
+~~~~~~~~~~~~~~
+
+
+Once test suites are located, **lit** recursively traverses the source directory
+(following *test_src_root*) looking for tests. When **lit** 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 "LOCAL CONFIGURATION
+FILES").
+
+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 *GoogleTest*) 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.
+
+
+LOCAL CONFIGURATION FILES
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+When **lit** loads a subdirectory in a test suite, it instantiates a local test
+configuration by cloning the configuration for the parent direction -- the root
+of this configuration chain will always be a test suite. Once the test
+configuration is cloned **lit** checks for a *lit.local.cfg* 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.
+
+
+TEST RUN OUTPUT FORMAT
+~~~~~~~~~~~~~~~~~~~~~~
+
+
+The b<lit> 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.
+
+Each test result is expected to appear on a line that matches:
+
+<result code>: <test name> (<progress info>)
+
+where <result-code> 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.
+
+The <test name> field can consist of an arbitrary string containing no newline.
+
+The <progress info> field can be used to report progress information such as
+(1/300) or can be empty, but even when empty the parentheses are required.
+
+Each test result may include additional (multiline) log information in the
+following format.
+
+<log delineator> TEST '(<test name>)' <trailing delineator>
+... log message ...
+<log delineator>
+
+where <test name> should be the name of a preceding reported test, <log
+delineator> is a string of '\*' characters *at least* four characters long (the
+recommended length is 20), and <trailing delineator> is an arbitrary (unparsed)
+string.
+
+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::
+
+  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)
+
+
+LIT EXAMPLE TESTS
+~~~~~~~~~~~~~~~~~
+
+
+The **lit** distribution contains several example implementations of test suites
+in the *ExampleTests* directory.
+
+
+SEE ALSO
+--------
+
+
+valgrind(1)

Added: www-releases/trunk/3.2/docs/CommandGuide/llc.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llc.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llc.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llc.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,251 @@
+llc - LLVM static compiler
+==========================
+
+
+SYNOPSIS
+--------
+
+
+**llc** [*options*] [*filename*]
+
+
+DESCRIPTION
+-----------
+
+
+The **llc** 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.
+
+The choice of architecture for the output assembly code is automatically
+determined from the input file, unless the **-march** option is used to override
+the default.
+
+
+OPTIONS
+-------
+
+
+If *filename* is - or omitted, **llc** reads from standard input.  Otherwise, it
+will from *filename*.  Inputs can be in either the LLVM assembly language
+format (.ll) or the LLVM bitcode format (.bc).
+
+If the **-o** option is omitted, then **llc** will send its output to standard
+output if the input is from standard input.  If the **-o** option specifies -,
+then the output will also be sent to standard output.
+
+If no **-o** option is specified and an input file other than - is specified,
+then **llc** creates the output filename by taking the input filename,
+removing any existing *.bc* extension, and adding a *.s* suffix.
+
+Other **llc** options are as follows:
+
+End-user Options
+~~~~~~~~~~~~~~~~
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**-O**\ =\ *uint*
+
+ Generate code at different optimization levels. These correspond to the *-O0*,
+ *-O1*, *-O2*, and *-O3* optimization levels used by **llvm-gcc** and
+ **clang**.
+
+
+
+**-mtriple**\ =\ *target triple*
+
+ Override the target triple specified in the input file with the specified
+ string.
+
+
+
+**-march**\ =\ *arch*
+
+ Specify the architecture for which to generate assembly, overriding the target
+ encoded in the input file.  See the output of **llc -help** for a list of
+ valid architectures.  By default this is inferred from the target triple or
+ autodetected to the current architecture.
+
+
+
+**-mcpu**\ =\ *cpuname*
+
+ 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:
+ **llvm-as < /dev/null | llc -march=xyz -mcpu=help**
+
+
+
+**-mattr**\ =\ *a1,+a2,-a3,...*
+
+ 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:
+ **llvm-as < /dev/null | llc -march=xyz -mattr=help**
+
+
+
+**--disable-fp-elim**
+
+ Disable frame pointer elimination optimization.
+
+
+
+**--disable-excess-fp-precision**
+
+ 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).
+
+
+
+**--enable-no-infs-fp-math**
+
+ Enable optimizations that assume no Inf values.
+
+
+
+**--enable-no-nans-fp-math**
+
+ Enable optimizations that assume no NAN values.
+
+
+
+**--enable-unsafe-fp-math**
+
+ 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 fsin on X86).
+
+
+
+**--enable-correct-eh-support**
+
+ Instruct the **lowerinvoke** pass to insert code for correct exception handling
+ support.  This is expensive and is by default omitted for efficiency.
+
+
+
+**--stats**
+
+ Print statistics recorded by code-generation passes.
+
+
+
+**--time-passes**
+
+ Record the amount of time needed for each pass and print a report to standard
+ error.
+
+
+
+**--load**\ =\ *dso_path*
+
+ Dynamically load *dso_path* (a path to a dynamically shared object) that
+ implements an LLVM target. This will permit the target name to be used with the
+ **-march** option so that code can be generated for that target.
+
+
+
+
+Tuning/Configuration Options
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+**--print-machineinstrs**
+
+ Print generated machine code between compilation phases (useful for debugging).
+
+
+
+**--regalloc**\ =\ *allocator*
+
+ Specify the register allocator to use. The default *allocator* is *local*.
+ Valid register allocators are:
+
+
+ *simple*
+
+  Very simple "always spill" register allocator
+
+
+
+ *local*
+
+  Local register allocator
+
+
+
+ *linearscan*
+
+  Linear scan global register allocator
+
+
+
+ *iterativescan*
+
+  Iterative scan global register allocator
+
+
+
+
+
+**--spiller**\ =\ *spiller*
+
+ 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
+ *spiller* is *local*.  Valid spillers are:
+
+
+ *simple*
+
+  Simple spiller
+
+
+
+ *local*
+
+  Local spiller
+
+
+
+
+
+
+Intel IA-32-specific Options
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+**--x86-asm-syntax=att|intel**
+
+ Specify whether to emit assembly code in AT&T syntax (the default) or intel
+ syntax.
+
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llc** succeeds, it will exit with 0.  Otherwise, if an error occurs,
+it will exit with a non-zero value.
+
+
+SEE ALSO
+--------
+
+
+lli|lli

Added: www-releases/trunk/3.2/docs/CommandGuide/lli.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/lli.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/lli.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/lli.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,300 @@
+lli - directly execute programs from LLVM bitcode
+=================================================
+
+
+SYNOPSIS
+--------
+
+
+**lli** [*options*] [*filename*] [*program args*]
+
+
+DESCRIPTION
+-----------
+
+
+**lli** directly executes programs in LLVM bitcode format.  It takes a program
+in LLVM bitcode format and executes it using a just-in-time compiler, if one is
+available for the current architecture, or an interpreter.  **lli** takes all of
+the same code generator options as llc|llc, but they are only effective when
+**lli** is using the just-in-time compiler.
+
+If *filename* is not specified, then **lli** reads the LLVM bitcode for the
+program from standard input.
+
+The optional *args* specified on the command line are passed to the program as
+arguments.
+
+
+GENERAL OPTIONS
+---------------
+
+
+
+**-fake-argv0**\ =\ *executable*
+
+ Override the ``argv[0]`` value passed into the executing program.
+
+
+
+**-force-interpreter**\ =\ *{false,true}*
+
+ If set to true, use the interpreter even if a just-in-time compiler is available
+ for this architecture. Defaults to false.
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**-load**\ =\ *puginfilename*
+
+ Causes **lli** to load the plugin (shared object) named *pluginfilename* and use
+ it for optimization.
+
+
+
+**-stats**
+
+ Print statistics from the code-generation passes. This is only meaningful for
+ the just-in-time compiler, at present.
+
+
+
+**-time-passes**
+
+ Record the amount of time needed for each code-generation pass and print it to
+ standard error.
+
+
+
+**-version**
+
+ Print out the version of **lli** and exit without doing anything else.
+
+
+
+
+TARGET OPTIONS
+--------------
+
+
+
+**-mtriple**\ =\ *target triple*
+
+ 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.
+
+
+
+**-march**\ =\ *arch*
+
+ Specify the architecture for which to generate assembly, overriding the target
+ encoded in the bitcode file.  See the output of **llc -help** for a list of
+ valid architectures.  By default this is inferred from the target triple or
+ autodetected to the current architecture.
+
+
+
+**-mcpu**\ =\ *cpuname*
+
+ 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:
+ **llvm-as < /dev/null | llc -march=xyz -mcpu=help**
+
+
+
+**-mattr**\ =\ *a1,+a2,-a3,...*
+
+ 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:
+ **llvm-as < /dev/null | llc -march=xyz -mattr=help**
+
+
+
+
+FLOATING POINT OPTIONS
+----------------------
+
+
+
+**-disable-excess-fp-precision**
+
+ Disable optimizations that may increase floating point precision.
+
+
+
+**-enable-no-infs-fp-math**
+
+ Enable optimizations that assume no Inf values.
+
+
+
+**-enable-no-nans-fp-math**
+
+ Enable optimizations that assume no NAN values.
+
+
+
+**-enable-unsafe-fp-math**
+
+ Causes **lli** to enable optimizations that may decrease floating point
+ precision.
+
+
+
+**-soft-float**
+
+ Causes **lli** to generate software floating point library calls instead of
+ equivalent hardware instructions.
+
+
+
+
+CODE GENERATION OPTIONS
+-----------------------
+
+
+
+**-code-model**\ =\ *model*
+
+ Choose the code model from:
+
+
+ .. code-block:: perl
+
+      default: Target default code model
+      small: Small code model
+      kernel: Kernel code model
+      medium: Medium code model
+      large: Large code model
+
+
+
+
+**-disable-post-RA-scheduler**
+
+ Disable scheduling after register allocation.
+
+
+
+**-disable-spill-fusing**
+
+ Disable fusing of spill code into instructions.
+
+
+
+**-enable-correct-eh-support**
+
+ Make the -lowerinvoke pass insert expensive, but correct, EH code.
+
+
+
+**-jit-enable-eh**
+
+ Exception handling should be enabled in the just-in-time compiler.
+
+
+
+**-join-liveintervals**
+
+ Coalesce copies (default=true).
+
+
+
+**-nozero-initialized-in-bss** Don't place zero-initialized symbols into the BSS section.
+
+
+
+**-pre-RA-sched**\ =\ *scheduler*
+
+ Instruction schedulers available (before register allocation):
+
+
+ .. code-block:: perl
+
+      =default: Best scheduler for the target
+      =none: No scheduling: breadth first sequencing
+      =simple: Simple two pass scheduling: minimize critical path and maximize processor utilization
+      =simple-noitin: Simple two pass scheduling: Same as simple except using generic latency
+      =list-burr: Bottom-up register reduction list scheduling
+      =list-tdrr: Top-down register reduction list scheduling
+      =list-td: Top-down list scheduler -print-machineinstrs - Print generated machine code
+
+
+
+
+**-regalloc**\ =\ *allocator*
+
+ Register allocator to use (default=linearscan)
+
+
+ .. code-block:: perl
+
+      =bigblock: Big-block register allocator
+      =linearscan: linear scan register allocator =local -   local register allocator
+      =simple: simple register allocator
+
+
+
+
+**-relocation-model**\ =\ *model*
+
+ Choose relocation model from:
+
+
+ .. code-block:: perl
+
+      =default: Target default relocation model
+      =static: Non-relocatable code =pic -   Fully relocatable, position independent code
+      =dynamic-no-pic: Relocatable external references, non-relocatable code
+
+
+
+
+**-spiller**
+
+ Spiller to use (default=local)
+
+
+ .. code-block:: perl
+
+      =simple: simple spiller
+      =local: local spiller
+
+
+
+
+**-x86-asm-syntax**\ =\ *syntax*
+
+ Choose style of code to emit from X86 backend:
+
+
+ .. code-block:: perl
+
+      =att: Emit AT&T-style assembly
+      =intel: Emit Intel-style assembly
+
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **lli** 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.
+
+
+SEE ALSO
+--------
+
+
+llc|llc

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-ar.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-ar.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-ar.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-ar.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,458 @@
+llvm-ar - LLVM archiver
+=======================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-ar** [-]{dmpqrtx}[Rabfikou] [relpos] [count] <archive> [files...]
+
+
+DESCRIPTION
+-----------
+
+
+The **llvm-ar** command is similar to the common Unix utility, ``ar``. It
+archives several files together into a single file. The intent for this is
+to produce archive libraries by LLVM bitcode that can be linked into an
+LLVM program. However, the archive can contain any kind of file. By default,
+**llvm-ar** generates a symbol table that makes linking faster because
+only the symbol table needs to be consulted, not each individual file member
+of the archive.
+
+The **llvm-ar** command can be used to *read* both SVR4 and BSD style archive
+files. However, it cannot be used to write them.  While the **llvm-ar** command
+produces files that are *almost* identical to the format used by other ``ar``
+implementations, it has two significant departures in order to make the
+archive appropriate for LLVM. The first departure is that **llvm-ar** only
+uses BSD4.4 style long path names (stored immediately after the header) and
+never contains a string table for long names. The second departure is that the
+symbol table is formated for efficient construction of an in-memory data
+structure that permits rapid (red-black tree) lookups. Consequently, archives
+produced with **llvm-ar** usually won't be readable or editable with any
+``ar`` implementation or useful for linking.  Using the ``f`` modifier to flatten
+file names will make the archive readable by other ``ar`` implementations
+but not for linking because the symbol table format for LLVM is unique. If an
+SVR4 or BSD style archive is used with the ``r`` (replace) or ``q`` (quick
+update) operations, the archive will be reconstructed in LLVM format. This
+means that the string table will be dropped (in deference to BSD 4.4 long names)
+and an LLVM symbol table will be added (by default). The system symbol table
+will be retained.
+
+Here's where **llvm-ar** departs from previous ``ar`` implementations:
+
+
+*Symbol Table*
+
+ Since **llvm-ar** is intended to archive bitcode files, the symbol table
+ won't make much sense to anything but LLVM. Consequently, the symbol table's
+ format has been simplified. It consists simply of a sequence of pairs
+ of a file member index number as an LSB 4byte integer and a null-terminated
+ string.
+
+
+
+*Long Paths*
+
+ Some ``ar`` implementations (SVR4) use a separate file member to record long
+ path names (> 15 characters). **llvm-ar** takes the BSD 4.4 and Mac OS X
+ approach which is to simply store the full path name immediately preceding
+ the data for the file. The path name is null terminated and may contain the
+ slash (/) character.
+
+
+
+*Directory Recursion*
+
+ Most ``ar`` implementations do not recurse through directories but simply
+ ignore directories if they are presented to the program in the *files*
+ option. **llvm-ar**, however, can recurse through directory structures and
+ add all the files under a directory, if requested.
+
+
+
+*TOC Verbose Output*
+
+ When **llvm-ar** prints out the verbose table of contents (``tv`` option), it
+ precedes the usual output with a character indicating the basic kind of
+ content in the file. A blank means the file is a regular file. A 'B' means
+ the file is an LLVM bitcode file. An 'S' means the file is the symbol table.
+
+
+
+
+OPTIONS
+-------
+
+
+The options to **llvm-ar** are compatible with other ``ar`` implementations.
+However, there are a few modifiers (*R*) that are not found in other ``ar``
+implementations. The options to **llvm-ar** specify a single basic operation to
+perform on the archive, a variety of modifiers for that operation, the name of
+the archive file, and an optional list of file names. These options are used to
+determine how **llvm-ar** should process the archive file.
+
+The Operations and Modifiers are explained in the sections below. The minimal
+set of options is at least one operator and the name of the archive. Typically
+archive files end with a ``.a`` suffix, but this is not required. Following
+the *archive-name* comes a list of *files* that indicate the specific members
+of the archive to operate on. If the *files* option is not specified, it
+generally means either "none" or "all" members, depending on the operation.
+
+Operations
+~~~~~~~~~~
+
+
+
+d
+
+ Delete files from the archive. No modifiers are applicable to this operation.
+ The *files* options specify which members should be removed from the
+ archive. It is not an error if a specified file does not appear in the archive.
+ If no *files* are specified, the archive is not modified.
+
+
+
+m[abi]
+
+ Move files from one location in the archive to another. The *a*, *b*, and
+ *i* modifiers apply to this operation. The *files* will all be moved
+ to the location given by the modifiers. If no modifiers are used, the files
+ will be moved to the end of the archive. If no *files* are specified, the
+ archive is not modified.
+
+
+
+p[k]
+
+ Print files to the standard output. The *k* modifier applies to this
+ operation. This operation simply prints the *files* indicated to the
+ standard output. If no *files* are specified, the entire archive is printed.
+ Printing bitcode files is ill-advised as they might confuse your terminal
+ settings. The *p* operation never modifies the archive.
+
+
+
+q[Rf]
+
+ Quickly append files to the end of the archive. The *R*, and *f*
+ modifiers apply to this operation.  This operation quickly adds the
+ *files* to the archive without checking for duplicates that should be
+ removed first. If no *files* are specified, the archive is not modified.
+ Because of the way that **llvm-ar** constructs the archive file, its dubious
+ whether the *q* operation is any faster than the *r* operation.
+
+
+
+r[Rabfu]
+
+ Replace or insert file members. The *R*, *a*, *b*, *f*, and *u*
+ modifiers apply to this operation. This operation will replace existing
+ *files* or insert them at the end of the archive if they do not exist. If no
+ *files* are specified, the archive is not modified.
+
+
+
+t[v]
+
+ Print the table of contents. Without any modifiers, this operation just prints
+ the names of the members to the standard output. With the *v* modifier,
+ **llvm-ar** also prints out the file type (B=bitcode, S=symbol
+ table, blank=regular file), the permission mode, the owner and group, the
+ size, and the date. If any *files* are specified, the listing is only for
+ those files. If no *files* are specified, the table of contents for the
+ whole archive is printed.
+
+
+
+x[oP]
+
+ Extract archive members back to files. The *o* modifier applies to this
+ operation. This operation retrieves the indicated *files* from the archive
+ and writes them back to the operating system's file system. If no
+ *files* are specified, the entire archive is extract.
+
+
+
+
+Modifiers (operation specific)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+The modifiers below are specific to certain operations. See the Operations
+section (above) to determine which modifiers are applicable to which operations.
+
+
+[a]
+
+ When inserting or moving member files, this option specifies the destination of
+ the new files as being after the *relpos* member. If *relpos* is not found,
+ the files are placed at the end of the archive.
+
+
+
+[b]
+
+ When inserting or moving member files, this option specifies the destination of
+ the new files as being before the *relpos* member. If *relpos* is not
+ found, the files are placed at the end of the archive. This modifier is
+ identical to the *i* modifier.
+
+
+
+[f]
+
+ Normally, **llvm-ar** stores the full path name to a file as presented to it on
+ the command line. With this option, truncated (15 characters max) names are
+ used. This ensures name compatibility with older versions of ``ar`` but may also
+ thwart correct extraction of the files (duplicates may overwrite). If used with
+ the *R* option, the directory recursion will be performed but the file names
+ will all be flattened to simple file names.
+
+
+
+[i]
+
+ A synonym for the *b* option.
+
+
+
+[k]
+
+ Normally, **llvm-ar** will not print the contents of bitcode files when the
+ *p* operation is used. This modifier defeats the default and allows the
+ bitcode members to be printed.
+
+
+
+[N]
+
+ This option is ignored by **llvm-ar** but provided for compatibility.
+
+
+
+[o]
+
+ When extracting files, this option will cause **llvm-ar** to preserve the
+ original modification times of the files it writes.
+
+
+
+[P]
+
+ use full path names when matching
+
+
+
+[R]
+
+ This modifier instructions the *r* option to recursively process directories.
+ Without *R*, directories are ignored and only those *files* that refer to
+ files will be added to the archive. When *R* is used, any directories specified
+ with *files* will be scanned (recursively) to find files to be added to the
+ archive. Any file whose name begins with a dot will not be added.
+
+
+
+[u]
+
+ When replacing existing files in the archive, only replace those files that have
+ a time stamp than the time stamp of the member in the archive.
+
+
+
+
+Modifiers (generic)
+~~~~~~~~~~~~~~~~~~~
+
+
+The modifiers below may be applied to any operation.
+
+
+[c]
+
+ For all operations, **llvm-ar** will always create the archive if it doesn't
+ exist. Normally, **llvm-ar** will print a warning message indicating that the
+ archive is being created. Using this modifier turns off that warning.
+
+
+
+[s]
+
+ This modifier requests that an archive index (or symbol table) be added to the
+ archive. This is the default mode of operation. The symbol table will contain
+ all the externally visible functions and global variables defined by all the
+ bitcode files in the archive. Using this modifier is more efficient that using
+ llvm-ranlib|llvm-ranlib which also creates the symbol table.
+
+
+
+[S]
+
+ This modifier is the opposite of the *s* modifier. It instructs **llvm-ar** to
+ not build the symbol table. If both *s* and *S* are used, the last modifier to
+ occur in the options will prevail.
+
+
+
+[v]
+
+ This modifier instructs **llvm-ar** to be verbose about what it is doing. Each
+ editing operation taken against the archive will produce a line of output saying
+ what is being done.
+
+
+
+
+
+STANDARDS
+---------
+
+
+The **llvm-ar** utility is intended to provide a superset of the IEEE Std 1003.2
+(POSIX.2) functionality for ``ar``. **llvm-ar** can read both SVR4 and BSD4.4 (or
+Mac OS X) archives. If the ``f`` modifier is given to the ``x`` or ``r`` operations
+then **llvm-ar** will write SVR4 compatible archives. Without this modifier,
+**llvm-ar** will write BSD4.4 compatible archives that have long names
+immediately after the header and indicated using the "#1/ddd" notation for the
+name in the header.
+
+
+FILE FORMAT
+-----------
+
+
+The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
+archive files. In fact, except for the symbol table, the ``ar`` commands on those
+operating systems should be able to read LLVM archive files. The details of the
+file format follow.
+
+Each archive begins with the archive magic number which is the eight printable
+characters "!<arch>\n" where \n represents the newline character (0x0A).
+Following the magic number, the file is composed of even length members that
+begin with an archive header and end with a \n padding character if necessary
+(to make the length even). Each file member is composed of a header (defined
+below), an optional newline-terminated "long file name" and the contents of
+the file.
+
+The fields of the header are described in the items below. All fields of the
+header contain only ASCII characters, are left justified and are right padded
+with space characters.
+
+
+name - char[16]
+
+ This field of the header provides the name of the archive member. If the name is
+ longer than 15 characters or contains a slash (/) character, then this field
+ contains ``#1/nnn`` where ``nnn`` provides the length of the name and the ``#1/``
+ is literal.  In this case, the actual name of the file is provided in the ``nnn``
+ bytes immediately following the header. If the name is 15 characters or less, it
+ is contained directly in this field and terminated with a slash (/) character.
+
+
+
+date - char[12]
+
+ This field provides the date of modification of the file in the form of a
+ decimal encoded number that provides the number of seconds since the epoch
+ (since 00:00:00 Jan 1, 1970) per Posix specifications.
+
+
+
+uid - char[6]
+
+ This field provides the user id of the file encoded as a decimal ASCII string.
+ This field might not make much sense on non-Unix systems. On Unix, it is the
+ same value as the st_uid field of the stat structure returned by the stat(2)
+ operating system call.
+
+
+
+gid - char[6]
+
+ This field provides the group id of the file encoded as a decimal ASCII string.
+ This field might not make much sense on non-Unix systems. On Unix, it is the
+ same value as the st_gid field of the stat structure returned by the stat(2)
+ operating system call.
+
+
+
+mode - char[8]
+
+ This field provides the access mode of the file encoded as an octal ASCII
+ string. This field might not make much sense on non-Unix systems. On Unix, it
+ is the same value as the st_mode field of the stat structure returned by the
+ stat(2) operating system call.
+
+
+
+size - char[10]
+
+ This field provides the size of the file, in bytes, encoded as a decimal ASCII
+ string.
+
+
+
+fmag - char[2]
+
+ This field is the archive file member magic number. Its content is always the
+ two characters back tick (0x60) and newline (0x0A). This provides some measure
+ utility in identifying archive files that have been corrupted.
+
+
+
+The LLVM symbol table has the special name "#_LLVM_SYM_TAB_#". It is presumed
+that no regular archive member file will want this name. The LLVM symbol table
+is simply composed of a sequence of triplets: byte offset, length of symbol,
+and the symbol itself. Symbols are not null or newline terminated. Here are
+the details on each of these items:
+
+
+offset - vbr encoded 32-bit integer
+
+ The offset item provides the offset into the archive file where the bitcode
+ member is stored that is associated with the symbol. The offset value is 0
+ based at the start of the first "normal" file member. To derive the actual
+ file offset of the member, you must add the number of bytes occupied by the file
+ signature (8 bytes) and the symbol tables. The value of this item is encoded
+ using variable bit rate encoding to reduce the size of the symbol table.
+ Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
+ if there are more bytes to follow. The remaining 7 bits in each byte carry bits
+ from the value. The final byte does not have the high bit set.
+
+
+
+length - vbr encoded 32-bit integer
+
+ The length item provides the length of the symbol that follows. Like this
+ *offset* item, the length is variable bit rate encoded.
+
+
+
+symbol - character array
+
+ The symbol item provides the text of the symbol that is associated with the
+ *offset*. The symbol is not terminated by any character. Its length is provided
+ by the *length* field. Note that is allowed (but unwise) to use non-printing
+ characters (even 0x00) in the symbol. This allows for multiple encodings of
+ symbol names.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-ar** succeeds, it will exit with 0.  A usage error, results
+in an exit code of 1. A hard (file system typically) error results in an
+exit code of 2. Miscellaneous or unknown errors result in an
+exit code of 3.
+
+
+SEE ALSO
+--------
+
+
+llvm-ranlib|llvm-ranlib, ar(1)

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-as.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-as.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-as.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-as.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,56 @@
+llvm-as - LLVM assembler
+========================
+
+SYNOPSIS
+--------
+
+**llvm-as** [*options*] [*filename*]
+
+DESCRIPTION
+-----------
+
+**llvm-as** is the LLVM assembler.  It reads a file containing human-readable
+LLVM assembly language, translates it to LLVM bitcode, and writes the result
+into a file or to standard output.
+
+If *filename* is omitted or is ``-``, then **llvm-as** reads its input from
+standard input.
+
+If an output file is not specified with the **-o** option, then
+**llvm-as** sends its output to a file or standard output by following
+these rules:
+
+* If the input is standard input, then the output is standard output.
+
+* If the input is a file that ends with ``.ll``, then the output file is of the
+  same name, except that the suffix is changed to ``.bc``.
+
+* If the input is a file that does not end with the ``.ll`` suffix, then the
+  output file has the same name as the input file, except that the ``.bc``
+  suffix is appended.
+
+OPTIONS
+-------
+
+**-f**
+ Enable binary output on terminals.  Normally, **llvm-as** will refuse to
+ write raw bitcode output if the output stream is a terminal. With this option,
+ **llvm-as** will write raw bitcode regardless of the output device.
+
+**-help**
+ Print a summary of command line options.
+
+**-o** *filename*
+ Specify the output file name.  If *filename* is ``-``, then **llvm-as**
+ sends its output to standard output.
+
+EXIT STATUS
+-----------
+
+If **llvm-as** succeeds, it will exit with 0.  Otherwise, if an error occurs, it
+will exit with a non-zero value.
+
+SEE ALSO
+--------
+
+llvm-dis|llvm-dis, gccas|gccas

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-bcanalyzer.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-bcanalyzer.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-bcanalyzer.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-bcanalyzer.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,424 @@
+llvm-bcanalyzer - LLVM bitcode analyzer
+=======================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-bcanalyzer** [*options*] [*filename*]
+
+
+DESCRIPTION
+-----------
+
+
+The **llvm-bcanalyzer** command is a small utility for analyzing bitcode files.
+The tool reads a bitcode file (such as generated with the **llvm-as** tool) and
+produces a statistical report on the contents of the bitcode file.  The tool
+can also dump a low level but human readable version of the bitcode file.
+This tool is probably not of much interest or utility except for those working
+directly with the bitcode file format. Most LLVM users can just ignore
+this tool.
+
+If *filename* is omitted or is ``-``, then **llvm-bcanalyzer** reads its input
+from standard input. This is useful for combining the tool into a pipeline.
+Output is written to the standard output.
+
+
+OPTIONS
+-------
+
+
+
+**-nodetails**
+
+ Causes **llvm-bcanalyzer** to abbreviate its output by writing out only a module
+ level summary. The details for individual functions are not displayed.
+
+
+
+**-dump**
+
+ Causes **llvm-bcanalyzer** to dump the bitcode in a human readable format. This
+ format is significantly different from LLVM assembly and provides details about
+ the encoding of the bitcode file.
+
+
+
+**-verify**
+
+ Causes **llvm-bcanalyzer** to verify the module produced by reading the
+ bitcode. This ensures that the statistics generated are based on a consistent
+ module.
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-bcanalyzer** succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value, usually 1.
+
+
+SUMMARY OUTPUT DEFINITIONS
+--------------------------
+
+
+The following items are always printed by llvm-bcanalyzer. They comprize the
+summary output.
+
+
+**Bitcode Analysis Of Module**
+
+ This just provides the name of the module for which bitcode analysis is being
+ generated.
+
+
+
+**Bitcode Version Number**
+
+ The bitcode version (not LLVM version) of the file read by the analyzer.
+
+
+
+**File Size**
+
+ The size, in bytes, of the entire bitcode file.
+
+
+
+**Module Bytes**
+
+ The size, in bytes, of the module block. Percentage is relative to File Size.
+
+
+
+**Function Bytes**
+
+ The size, in bytes, of all the function blocks. Percentage is relative to File
+ Size.
+
+
+
+**Global Types Bytes**
+
+ The size, in bytes, of the Global Types Pool. Percentage is relative to File
+ Size. This is the size of the definitions of all types in the bitcode file.
+
+
+
+**Constant Pool Bytes**
+
+ The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
+ Size.
+
+
+
+**Module Globals Bytes**
+
+ Ths size, in bytes, of the Global Variable Definitions and their initializers.
+ Percentage is relative to File Size.
+
+
+
+**Instruction List Bytes**
+
+ The size, in bytes, of all the instruction lists in all the functions.
+ Percentage is relative to File Size. Note that this value is also included in
+ the Function Bytes.
+
+
+
+**Compaction Table Bytes**
+
+ The size, in bytes, of all the compaction tables in all the functions.
+ Percentage is relative to File Size. Note that this value is also included in
+ the Function Bytes.
+
+
+
+**Symbol Table Bytes**
+
+ The size, in bytes, of all the symbol tables in all the functions. Percentage is
+ relative to File Size. Note that this value is also included in the Function
+ Bytes.
+
+
+
+**Dependent Libraries Bytes**
+
+ The size, in bytes, of the list of dependent libraries in the module. Percentage
+ is relative to File Size. Note that this value is also included in the Module
+ Global Bytes.
+
+
+
+**Number Of Bitcode Blocks**
+
+ The total number of blocks of any kind in the bitcode file.
+
+
+
+**Number Of Functions**
+
+ The total number of function definitions in the bitcode file.
+
+
+
+**Number Of Types**
+
+ The total number of types defined in the Global Types Pool.
+
+
+
+**Number Of Constants**
+
+ The total number of constants (of any type) defined in the Constant Pool.
+
+
+
+**Number Of Basic Blocks**
+
+ The total number of basic blocks defined in all functions in the bitcode file.
+
+
+
+**Number Of Instructions**
+
+ The total number of instructions defined in all functions in the bitcode file.
+
+
+
+**Number Of Long Instructions**
+
+ The total number of long instructions defined in all functions in the bitcode
+ file. Long instructions are those taking greater than 4 bytes. Typically long
+ instructions are GetElementPtr with several indices, PHI nodes, and calls to
+ functions with large numbers of arguments.
+
+
+
+**Number Of Operands**
+
+ The total number of operands used in all instructions in the bitcode file.
+
+
+
+**Number Of Compaction Tables**
+
+ The total number of compaction tables in all functions in the bitcode file.
+
+
+
+**Number Of Symbol Tables**
+
+ The total number of symbol tables in all functions in the bitcode file.
+
+
+
+**Number Of Dependent Libs**
+
+ The total number of dependent libraries found in the bitcode file.
+
+
+
+**Total Instruction Size**
+
+ The total size of the instructions in all functions in the bitcode file.
+
+
+
+**Average Instruction Size**
+
+ The average number of bytes per instruction across all functions in the bitcode
+ file. This value is computed by dividing Total Instruction Size by Number Of
+ Instructions.
+
+
+
+**Maximum Type Slot Number**
+
+ The maximum value used for a type's slot number. Larger slot number values take
+ more bytes to encode.
+
+
+
+**Maximum Value Slot Number**
+
+ The maximum value used for a value's slot number. Larger slot number values take
+ more bytes to encode.
+
+
+
+**Bytes Per Value**
+
+ The average size of a Value definition (of any type). This is computed by
+ dividing File Size by the total number of values of any type.
+
+
+
+**Bytes Per Global**
+
+ The average size of a global definition (constants and global variables).
+
+
+
+**Bytes Per Function**
+
+ The average number of bytes per function definition. This is computed by
+ dividing Function Bytes by Number Of Functions.
+
+
+
+**# of VBR 32-bit Integers**
+
+ The total number of 32-bit integers encoded using the Variable Bit Rate
+ encoding scheme.
+
+
+
+**# of VBR 64-bit Integers**
+
+ The total number of 64-bit integers encoded using the Variable Bit Rate encoding
+ scheme.
+
+
+
+**# of VBR Compressed Bytes**
+
+ The total number of bytes consumed by the 32-bit and 64-bit integers that use
+ the Variable Bit Rate encoding scheme.
+
+
+
+**# of VBR Expanded Bytes**
+
+ The total number of bytes that would have been consumed by the 32-bit and 64-bit
+ integers had they not been compressed with the Variable Bit Rage encoding
+ scheme.
+
+
+
+**Bytes Saved With VBR**
+
+ The total number of bytes saved by using the Variable Bit Rate encoding scheme.
+ The percentage is relative to # of VBR Expanded Bytes.
+
+
+
+
+DETAILED OUTPUT DEFINITIONS
+---------------------------
+
+
+The following definitions occur only if the -nodetails option was not given.
+The detailed output provides additional information on a per-function basis.
+
+
+**Type**
+
+ The type signature of the function.
+
+
+
+**Byte Size**
+
+ The total number of bytes in the function's block.
+
+
+
+**Basic Blocks**
+
+ The number of basic blocks defined by the function.
+
+
+
+**Instructions**
+
+ The number of instructions defined by the function.
+
+
+
+**Long Instructions**
+
+ The number of instructions using the long instruction format in the function.
+
+
+
+**Operands**
+
+ The number of operands used by all instructions in the function.
+
+
+
+**Instruction Size**
+
+ The number of bytes consumed by instructions in the function.
+
+
+
+**Average Instruction Size**
+
+ The average number of bytes consumed by the instructions in the function. This
+ value is computed by dividing Instruction Size by Instructions.
+
+
+
+**Bytes Per Instruction**
+
+ The average number of bytes used by the function per instruction. This value is
+ computed by dividing Byte Size by Instructions. Note that this is not the same
+ as Average Instruction Size. It computes a number relative to the total function
+ size not just the size of the instruction list.
+
+
+
+**Number of VBR 32-bit Integers**
+
+ The total number of 32-bit integers found in this function (for any use).
+
+
+
+**Number of VBR 64-bit Integers**
+
+ The total number of 64-bit integers found in this function (for any use).
+
+
+
+**Number of VBR Compressed Bytes**
+
+ The total number of bytes in this function consumed by the 32-bit and 64-bit
+ integers that use the Variable Bit Rate encoding scheme.
+
+
+
+**Number of VBR Expanded Bytes**
+
+ The total number of bytes in this function that would have been consumed by
+ the 32-bit and 64-bit integers had they not been compressed with the Variable
+ Bit Rate encoding scheme.
+
+
+
+**Bytes Saved With VBR**
+
+ The total number of bytes saved in this function by using the Variable Bit
+ Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes.
+
+
+
+
+SEE ALSO
+--------
+
+
+llvm-dis|llvm-dis, `http://llvm.org/docs/BitCodeFormat.html <http://llvm.org/docs/BitCodeFormat.html>`_

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-build.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-build.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-build.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-build.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,102 @@
+llvm-build - LLVM Project Build Utility
+=======================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-build** [*options*]
+
+
+DESCRIPTION
+-----------
+
+
+**llvm-build** is a tool for working with LLVM projects that use the LLVMBuild
+system for describing their components.
+
+At heart, **llvm-build** is responsible for loading, verifying, and manipulating
+the project's component data. The tool is primarily designed for use in
+implementing build systems and tools which need access to the project structure
+information.
+
+
+OPTIONS
+-------
+
+
+
+**-h**, **--help**
+
+ Print the builtin program help.
+
+
+
+**--source-root**\ =\ *PATH*
+
+ If given, load the project at the given source root path. If this option is not
+ given, the location of the project sources will be inferred from the location of
+ the **llvm-build** script itself.
+
+
+
+**--print-tree**
+
+ Print the component tree for the project.
+
+
+
+**--write-library-table**
+
+ Write out the C++ fragment which defines the components, library names, and
+ required libraries. This C++ fragment is built into llvm-config|llvm-config
+ in order to provide clients with the list of required libraries for arbitrary
+ component combinations.
+
+
+
+**--write-llvmbuild**
+
+ Write out new *LLVMBuild.txt* files based on the loaded components. This is
+ useful for auto-upgrading the schema of the files. **llvm-build** will try to a
+ limited extent to preserve the comments which were written in the original
+ source file, although at this time it only preserves block comments that precede
+ the section names in the *LLVMBuild* files.
+
+
+
+**--write-cmake-fragment**
+
+ Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
+ consumed by the CMake based build system. The exact contents and format of this
+ file are closely tied to how LLVMBuild is integrated with CMake, see LLVM's
+ top-level CMakeLists.txt.
+
+
+
+**--write-make-fragment**
+
+ Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be
+ consumed by a Make based build system. The exact contents and format of this
+ file are closely tied to how LLVMBuild is integrated with the Makefiles, see
+ LLVM's Makefile.rules.
+
+
+
+**--llvmbuild-source-root**\ =\ *PATH*
+
+ If given, expect the *LLVMBuild* files for the project to be rooted at the
+ given path, instead of inside the source tree itself. This option is primarily
+ designed for use in conjunction with **--write-llvmbuild** to test changes to
+ *LLVMBuild* schema.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+**llvm-build** exits with 0 if operation was successful. Otherwise, it will exist
+with a non-zero value.

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-config.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-config.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-config.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-config.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,176 @@
+llvm-config - Print LLVM compilation options
+============================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-config** *option* [*components*...]
+
+
+DESCRIPTION
+-----------
+
+
+**llvm-config** makes it easier to build applications that use LLVM.  It can
+print the compiler flags, linker flags and object libraries needed to link
+against LLVM.
+
+
+EXAMPLES
+--------
+
+
+To link against the JIT:
+
+
+.. code-block:: sh
+
+   g++ `llvm-config --cxxflags` -o HowToUseJIT.o -c HowToUseJIT.cpp
+   g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o \
+       `llvm-config --libs engine bcreader scalaropts`
+
+
+
+OPTIONS
+-------
+
+
+
+**--version**
+
+ Print the version number of LLVM.
+
+
+
+**-help**
+
+ Print a summary of **llvm-config** arguments.
+
+
+
+**--prefix**
+
+ Print the installation prefix for LLVM.
+
+
+
+**--src-root**
+
+ Print the source root from which LLVM was built.
+
+
+
+**--obj-root**
+
+ Print the object root used to build LLVM.
+
+
+
+**--bindir**
+
+ Print the installation directory for LLVM binaries.
+
+
+
+**--includedir**
+
+ Print the installation directory for LLVM headers.
+
+
+
+**--libdir**
+
+ Print the installation directory for LLVM libraries.
+
+
+
+**--cxxflags**
+
+ Print the C++ compiler flags needed to use LLVM headers.
+
+
+
+**--ldflags**
+
+ Print the flags needed to link against LLVM libraries.
+
+
+
+**--libs**
+
+ Print all the libraries needed to link against the specified LLVM
+ *components*, including any dependencies.
+
+
+
+**--libnames**
+
+ Similar to **--libs**, but prints the bare filenames of the libraries
+ without **-l** or pathnames.  Useful for linking against a not-yet-installed
+ copy of LLVM.
+
+
+
+**--libfiles**
+
+ Similar to **--libs**, but print the full path to each library file.  This is
+ useful when creating makefile dependencies, to ensure that a tool is relinked if
+ any library it uses changes.
+
+
+
+**--components**
+
+ Print all valid component names.
+
+
+
+**--targets-built**
+
+ Print the component names for all targets supported by this copy of LLVM.
+
+
+
+**--build-mode**
+
+ Print the build mode used when LLVM was built (e.g. Debug or Release)
+
+
+
+
+COMPONENTS
+----------
+
+
+To print a list of all available components, run **llvm-config
+--components**.  In most cases, components correspond directly to LLVM
+libraries.  Useful "virtual" components include:
+
+
+**all**
+
+ Includes all LLVM libaries.  The default if no components are specified.
+
+
+
+**backend**
+
+ Includes either a native backend or the C backend.
+
+
+
+**engine**
+
+ Includes either a native JIT or the bitcode interpreter.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-config** succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-cov.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-cov.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-cov.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-cov.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,51 @@
+llvm-cov - emit coverage information
+====================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-cov** [-gcno=filename] [-gcda=filename] [dump]
+
+
+DESCRIPTION
+-----------
+
+
+The experimental **llvm-cov** tool reads in description file generated by compiler
+and coverage data file generated by instrumented program. This program assumes
+that the description and data file uses same format as gcov files.
+
+
+OPTIONS
+-------
+
+
+
+**-gcno=filename]**
+
+ This option selects input description file generated by compiler while instrumenting
+ program.
+
+
+
+**-gcda=filename]**
+
+ This option selects coverage data file generated by instrumented compiler.
+
+
+
+**-dump**
+
+ This options enables output dump that is suitable for a developer to help debug
+ **llvm-cov** itself.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+**llvm-cov** returns 1 if it cannot read input files. Otherwise, it exits with zero.

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-diff.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-diff.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-diff.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-diff.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,56 @@
+llvm-diff - LLVM structural 'diff'
+==================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-diff** [*options*] *module 1* *module 2* [*global name ...*]
+
+
+DESCRIPTION
+-----------
+
+
+**llvm-diff** compares the structure of two LLVM modules, primarily
+focusing on differences in function definitions.  Insignificant
+differences, such as changes in the ordering of globals or in the
+names of local values, are ignored.
+
+An input module will be interpreted as an assembly file if its name
+ends in '.ll';  otherwise it will be read in as a bitcode file.
+
+If a list of global names is given, just the values with those names
+are compared; otherwise, all global values are compared, and
+diagnostics are produced for globals which only appear in one module
+or the other.
+
+**llvm-diff** compares two functions by comparing their basic blocks,
+beginning with the entry blocks.  If the terminators seem to match,
+then the corresponding successors are compared; otherwise they are
+ignored.  This algorithm is very sensitive to changes in control flow,
+which tend to stop any downstream changes from being detected.
+
+**llvm-diff** is intended as a debugging tool for writers of LLVM
+passes and frontends.  It does not have a stable output format.
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-diff** finds no differences between the modules, it will exit
+with 0 and produce no output.  Otherwise it will exit with a non-zero
+value.
+
+
+BUGS
+----
+
+
+Many important differences, like changes in linkage or function
+attributes, are not diagnosed.
+
+Changes in memory behavior (for example, coalescing loads) can cause
+massive detected differences in blocks.

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-dis.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-dis.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-dis.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-dis.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,69 @@
+llvm-dis - LLVM disassembler
+============================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-dis** [*options*] [*filename*]
+
+
+DESCRIPTION
+-----------
+
+
+The **llvm-dis** command is the LLVM disassembler.  It takes an LLVM
+bitcode file and converts it into human-readable LLVM assembly language.
+
+If filename is omitted or specified as ``-``, **llvm-dis** reads its
+input from standard input.
+
+If the input is being read from standard input, then **llvm-dis**
+will send its output to standard output by default.  Otherwise, the
+output will be written to a file named after the input file, with
+a ``.ll`` suffix added (any existing ``.bc`` suffix will first be
+removed).  You can override the choice of output file using the
+**-o** option.
+
+
+OPTIONS
+-------
+
+
+
+**-f**
+
+ Enable binary output on terminals.  Normally, **llvm-dis** will refuse to
+ write raw bitcode output if the output stream is a terminal. With this option,
+ **llvm-dis** will write raw bitcode regardless of the output device.
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**-o** *filename*
+
+ Specify the output file name.  If *filename* is -, then the output is sent
+ to standard output.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-dis** succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+
+SEE ALSO
+--------
+
+
+llvm-as|llvm-as

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-extract.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-extract.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-extract.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-extract.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,104 @@
+llvm-extract - extract a function from an LLVM module
+=====================================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-extract** [*options*] **--func** *function-name* [*filename*]
+
+
+DESCRIPTION
+-----------
+
+
+The **llvm-extract** command takes the name of a function and extracts it from
+the specified LLVM bitcode file.  It is primarily used as a debugging tool to
+reduce test cases from larger programs that are triggering a bug.
+
+In addition to extracting the bitcode of the specified function,
+**llvm-extract** will also remove unreachable global variables, prototypes, and
+unused types.
+
+The **llvm-extract** command reads its input from standard input if filename is
+omitted or if filename is -.  The output is always written to standard output,
+unless the **-o** option is specified (see below).
+
+
+OPTIONS
+-------
+
+
+
+**-f**
+
+ Enable binary output on terminals.  Normally, **llvm-extract** will refuse to
+ write raw bitcode output if the output stream is a terminal. With this option,
+ **llvm-extract** will write raw bitcode regardless of the output device.
+
+
+
+**--func** *function-name*
+
+ Extract the function named *function-name* from the LLVM bitcode. May be
+ specified multiple times to extract multiple functions at once.
+
+
+
+**--rfunc** *function-regular-expr*
+
+ Extract the function(s) matching *function-regular-expr* from the LLVM bitcode.
+ All functions matching the regular expression will be extracted.  May be
+ specified multiple times.
+
+
+
+**--glob** *global-name*
+
+ Extract the global variable named *global-name* from the LLVM bitcode. May be
+ specified multiple times to extract multiple global variables at once.
+
+
+
+**--rglob** *glob-regular-expr*
+
+ Extract the global variable(s) matching *global-regular-expr* from the LLVM
+ bitcode. All global variables matching the regular expression will be extracted.
+ May be specified multiple times.
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**-o** *filename*
+
+ Specify the output filename.  If filename is "-" (the default), then
+ **llvm-extract** sends its output to standard output.
+
+
+
+**-S**
+
+ Write output in LLVM intermediate language (instead of bitcode).
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-extract** succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+
+SEE ALSO
+--------
+
+
+bugpoint|bugpoint

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-link.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-link.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-link.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-link.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,96 @@
+llvm-link - LLVM linker
+=======================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-link** [*options*] *filename ...*
+
+
+DESCRIPTION
+-----------
+
+
+**llvm-link** takes several LLVM bitcode files and links them together into a
+single LLVM bitcode file.  It writes the output file to standard output, unless
+the **-o** option is used to specify a filename.
+
+**llvm-link** attempts to load the input files from the current directory.  If
+that fails, it looks for each file in each of the directories specified by the
+**-L** options on the command line.  The library search paths are global; each
+one is searched for every input file if necessary.  The directories are searched
+in the order they were specified on the command line.
+
+
+OPTIONS
+-------
+
+
+
+**-L** *directory*
+
+ Add the specified *directory* to the library search path.  When looking for
+ libraries, **llvm-link** will look in path name for libraries.  This option can be
+ specified multiple times; **llvm-link** will search inside these directories in
+ the order in which they were specified on the command line.
+
+
+
+**-f**
+
+ Enable binary output on terminals.  Normally, **llvm-link** will refuse to
+ write raw bitcode output if the output stream is a terminal. With this option,
+ **llvm-link** will write raw bitcode regardless of the output device.
+
+
+
+**-o** *filename*
+
+ Specify the output file name.  If *filename* is ``-``, then **llvm-link** will
+ write its output to standard output.
+
+
+
+**-S**
+
+ Write output in LLVM intermediate language (instead of bitcode).
+
+
+
+**-d**
+
+ If specified, **llvm-link** prints a human-readable version of the output
+ bitcode file to standard error.
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**-v**
+
+ Verbose mode.  Print information about what **llvm-link** is doing.  This
+ typically includes a message for each bitcode file linked in and for each
+ library found.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-link** succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+
+SEE ALSO
+--------
+
+
+gccld|gccld

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-nm.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-nm.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-nm.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-nm.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,189 @@
+llvm-nm - list LLVM bitcode and object file's symbol table
+==========================================================
+
+
+SYNOPSIS
+--------
+
+
+:program:`llvm-nm` [*options*] [*filenames...*]
+
+
+DESCRIPTION
+-----------
+
+
+The :program:`llvm-nm` utility lists the names of symbols from the LLVM bitcode
+files, object files, or :program:`ar` archives containing them, named on the
+command line. Each symbol is listed along with some simple information about its
+provenance. If no file name is specified, or *-* is used as a file name,
+:program:`llvm-nm` will process a file on its standard input stream.
+
+:program:`llvm-nm`'s default output format is the traditional BSD :program:`nm`
+output format. Each such output record consists of an (optional) 8-digit
+hexadecimal address, followed by a type code character, followed by a name, for
+each symbol. One record is printed per line; fields are separated by spaces.
+When the address is omitted, it is replaced by 8 spaces.
+
+Type code characters currently supported, and their meanings, are as follows:
+
+
+U
+
+ Named object is referenced but undefined in this bitcode file
+
+
+
+C
+
+ Common (multiple definitions link together into one def)
+
+
+
+W
+
+ Weak reference (multiple definitions link together into zero or one definitions)
+
+
+
+t
+
+ Local function (text) object
+
+
+
+T
+
+ Global function (text) object
+
+
+
+d
+
+ Local data object
+
+
+
+D
+
+ Global data object
+
+
+
+?
+
+ Something unrecognizable
+
+
+
+Because LLVM bitcode files typically contain objects that are not considered to
+have addresses until they are linked into an executable image or dynamically
+compiled "just-in-time", :program:`llvm-nm` does not print an address for any
+symbol in a LLVM bitcode file, even symbols which are defined in the bitcode
+file.
+
+
+OPTIONS
+-------
+
+
+.. program:: llvm-nm
+
+
+.. option:: -B    (default)
+
+ Use BSD output format. Alias for :option:`--format=bsd`.
+
+
+.. option:: -P
+
+ Use POSIX.2 output format. Alias for :option:`--format=posix`.
+
+
+.. option:: --debug-syms, -a
+
+ Show all symbols, even debugger only.
+
+
+.. option:: --defined-only
+
+ Print only symbols defined in this file (as opposed to
+ symbols which may be referenced by objects in this file, but not
+ defined in this file.)
+
+
+.. option:: --dynamic, -D
+
+ Display dynamic symbols instead of normal symbols.
+
+
+.. option:: --extern-only, -g
+
+ Print only symbols whose definitions are external; that is, accessible
+ from other files.
+
+
+.. option:: --format=format, -f format
+
+ Select an output format; *format* may be *sysv*, *posix*, or *bsd*. The default
+ is *bsd*.
+
+
+.. option:: -help
+
+ Print a summary of command-line options and their meanings.
+
+
+.. option:: --no-sort, -p
+
+ Shows symbols in order encountered.
+
+
+.. option:: --numeric-sort, -n, -v
+
+ Sort symbols by address.
+
+
+.. option:: --print-file-name, -A, -o
+
+ Precede each symbol with the file it came from.
+
+
+.. option:: --print-size, -S
+
+ Show symbol size instead of address.
+
+
+.. option:: --size-sort
+
+ Sort symbols by size.
+
+
+.. option:: --undefined-only, -u
+
+ Print only symbols referenced but not defined in this file.
+
+
+BUGS
+----
+
+
+ * :program:`llvm-nm` cannot demangle C++ mangled names, like GNU :program:`nm`
+   can.
+
+ * :program:`llvm-nm` does not support the full set of arguments that GNU
+   :program:`nm` does.
+
+
+EXIT STATUS
+-----------
+
+
+:program:`llvm-nm` exits with an exit code of zero.
+
+
+SEE ALSO
+--------
+
+
+llvm-dis|llvm-dis, ar(1), nm(1)

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-prof.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-prof.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-prof.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-prof.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,63 @@
+llvm-prof - print execution profile of LLVM program
+===================================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-prof** [*options*] [*bitcode file*] [*llvmprof.out*]
+
+
+DESCRIPTION
+-----------
+
+
+The **llvm-prof** tool reads in an *llvmprof.out* file (which can
+optionally use a specific file with the third program argument), a bitcode file
+for the program, and produces a human readable report, suitable for determining
+where the program hotspots are.
+
+This program is often used in conjunction with the *utils/profile.pl*
+script.  This script automatically instruments a program, runs it with the JIT,
+then runs **llvm-prof** to format a report.  To get more information about
+*utils/profile.pl*, execute it with the **-help** option.
+
+
+OPTIONS
+-------
+
+
+
+**--annotated-llvm** or **-A**
+
+ In addition to the normal report printed, print out the code for the
+ program, annotated with execution frequency information. This can be
+ particularly useful when trying to visualize how frequently basic blocks
+ are executed.  This is most useful with basic block profiling
+ information or better.
+
+
+
+**--print-all-code**
+
+ Using this option enables the **--annotated-llvm** option, but it
+ prints the entire module, instead of just the most commonly executed
+ functions.
+
+
+
+**--time-passes**
+
+ Record the amount of time needed for each pass and print it to standard
+ error.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+**llvm-prof** returns 1 if it cannot load the bitcode file or the profile
+information. Otherwise, it exits with zero.

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-ranlib.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-ranlib.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-ranlib.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-ranlib.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,61 @@
+llvm-ranlib - Generate index for LLVM archive
+=============================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-ranlib** [--version] [-help] <archive-file>
+
+
+DESCRIPTION
+-----------
+
+
+The **llvm-ranlib** command is similar to the common Unix utility, ``ranlib``. It
+adds or updates the symbol table in an LLVM archive file. Note that using the
+**llvm-ar** modifier *s* is usually more efficient than running **llvm-ranlib**
+which is only provided only for completness and compatibility. Unlike other
+implementations of ``ranlib``, **llvm-ranlib** indexes LLVM bitcode files, not
+native object modules. You can list the contents of the symbol table with the
+``llvm-nm -s`` command.
+
+
+OPTIONS
+-------
+
+
+
+*archive-file*
+
+ Specifies the archive-file to which the symbol table is added or updated.
+
+
+
+*--version*
+
+ Print the version of **llvm-ranlib** and exit without building a symbol table.
+
+
+
+*-help*
+
+ Print usage help for **llvm-ranlib** and exit without building a symbol table.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **llvm-ranlib** succeeds, it will exit with 0.  If an error occurs, a non-zero
+exit code will be returned.
+
+
+SEE ALSO
+--------
+
+
+llvm-ar|llvm-ar, ranlib(1)

Added: www-releases/trunk/3.2/docs/CommandGuide/llvm-stress.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/llvm-stress.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/llvm-stress.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/llvm-stress.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,48 @@
+llvm-stress - generate random .ll files
+=======================================
+
+
+SYNOPSIS
+--------
+
+
+**llvm-stress** [-size=filesize] [-seed=initialseed] [-o=outfile]
+
+
+DESCRIPTION
+-----------
+
+
+The **llvm-stress** tool is used to generate random .ll files that can be used to
+test different components of LLVM.
+
+
+OPTIONS
+-------
+
+
+
+**-o** *filename*
+
+ Specify the output filename.
+
+
+
+**-size** *size*
+
+ Specify the size of the generated .ll file.
+
+
+
+**-seed** *seed*
+
+ Specify the seed to be used for the randomly generated instructions.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+**llvm-stress** returns 0.

Added: www-releases/trunk/3.2/docs/CommandGuide/opt.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/opt.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/opt.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/opt.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,183 @@
+opt - LLVM optimizer
+====================
+
+
+SYNOPSIS
+--------
+
+
+**opt** [*options*] [*filename*]
+
+
+DESCRIPTION
+-----------
+
+
+The **opt** command is the modular LLVM optimizer and analyzer.  It takes LLVM
+source files as input, runs the specified optimizations or analyses on it, and then
+outputs the optimized file or the analysis results.  The function of
+**opt** depends on whether the **-analyze** option is given.
+
+When **-analyze** is specified, **opt** performs various analyses of the input
+source.  It will usually print the results on standard output, but in a few
+cases, it will print output to standard error or generate a file with the
+analysis output, which is usually done when the output is meant for another
+program.
+
+While **-analyze** is *not* given, **opt** attempts to produce an optimized
+output file.  The optimizations available via **opt** depend upon what
+libraries were linked into it as well as any additional libraries that have
+been loaded with the **-load** option.  Use the **-help** option to determine
+what optimizations you can use.
+
+If *filename* is omitted from the command line or is *-*, **opt** reads its
+input from standard input. Inputs can be in either the LLVM assembly language
+format (.ll) or the LLVM bitcode format (.bc).
+
+If an output filename is not specified with the **-o** option, **opt**
+writes its output to the standard output.
+
+
+OPTIONS
+-------
+
+
+
+**-f**
+
+ Enable binary output on terminals.  Normally, **opt** will refuse to
+ write raw bitcode output if the output stream is a terminal. With this option,
+ **opt** will write raw bitcode regardless of the output device.
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**-o** *filename*
+
+ Specify the output filename.
+
+
+
+**-S**
+
+ Write output in LLVM intermediate language (instead of bitcode).
+
+
+
+**-{passname}**
+
+ **opt** provides the ability to run any of LLVM's optimization or analysis passes
+ in any order. The **-help** option lists all the passes available. The order in
+ which the options occur on the command line are the order in which they are
+ executed (within pass constraints).
+
+
+
+**-std-compile-opts**
+
+ This is short hand for a standard list of *compile time optimization* passes.
+ This is typically used to optimize the output from the llvm-gcc front end. It
+ might be useful for other front end compilers as well. To discover the full set
+ of options available, use the following command:
+
+
+ .. code-block:: sh
+
+     llvm-as < /dev/null | opt -std-compile-opts -disable-output -debug-pass=Arguments
+
+
+
+
+**-disable-inlining**
+
+ This option is only meaningful when **-std-compile-opts** is given. It simply
+ removes the inlining pass from the standard list.
+
+
+
+**-disable-opt**
+
+ This option is only meaningful when **-std-compile-opts** is given. It disables
+ most, but not all, of the **-std-compile-opts**. The ones that remain are
+ **-verify**, **-lower-setjmp**, and **-funcresolve**.
+
+
+
+**-strip-debug**
+
+ This option causes opt to strip debug information from the module before
+ applying other optimizations. It is essentially the same as **-strip** but it
+ ensures that stripping of debug information is done first.
+
+
+
+**-verify-each**
+
+ This option causes opt to add a verify pass after every pass otherwise specified
+ on the command line (including **-verify**).  This is useful for cases where it
+ is suspected that a pass is creating an invalid module but it is not clear which
+ pass is doing it. The combination of **-std-compile-opts** and **-verify-each**
+ can quickly track down this kind of problem.
+
+
+
+**-profile-info-file** *filename*
+
+ Specify the name of the file loaded by the -profile-loader option.
+
+
+
+**-stats**
+
+ Print statistics.
+
+
+
+**-time-passes**
+
+ Record the amount of time needed for each pass and print it to standard
+ error.
+
+
+
+**-debug**
+
+ If this is a debug build, this option will enable debug printouts
+ from passes which use the *DEBUG()* macro.  See the **LLVM Programmer's
+ Manual**, section *#DEBUG* for more information.
+
+
+
+**-load**\ =\ *plugin*
+
+ Load the dynamic object *plugin*.  This object should register new optimization
+ or analysis passes. Once loaded, the object will add new command line options to
+ enable various optimizations or analyses.  To see the new complete list of
+ optimizations, use the **-help** and **-load** options together. For example:
+
+
+ .. code-block:: sh
+
+     opt -load=plugin.so -help
+
+
+
+
+**-p**
+
+ Print module after each transformation.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **opt** succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.

Added: www-releases/trunk/3.2/docs/CommandGuide/tblgen.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandGuide/tblgen.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandGuide/tblgen.rst (added)
+++ www-releases/trunk/3.2/docs/CommandGuide/tblgen.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,186 @@
+tblgen - Target Description To C++ Code Generator
+=================================================
+
+
+SYNOPSIS
+--------
+
+
+**tblgen** [*options*] [*filename*]
+
+
+DESCRIPTION
+-----------
+
+
+**tblgen** translates from target description (.td) files into C++ code that can
+be included in the definition of an LLVM target library. Most users of LLVM will
+not need to use this program. It is only for assisting with writing an LLVM
+target backend.
+
+The input and output of **tblgen** is beyond the scope of this short
+introduction. Please see the *CodeGeneration* page in the LLVM documentation.
+
+The *filename* argument specifies the name of a Target Description (.td) file
+to read as input.
+
+
+OPTIONS
+-------
+
+
+
+**-help**
+
+ Print a summary of command line options.
+
+
+
+**-o** *filename*
+
+ Specify the output file name.  If *filename* is ``-``, then **tblgen**
+ sends its output to standard output.
+
+
+
+**-I** *directory*
+
+ Specify where to find other target description files for inclusion. The
+ *directory* value should be a full or partial path to a directory that contains
+ target description files.
+
+
+
+**-asmparsernum** *N*
+
+ Make -gen-asm-parser emit assembly writer number *N*.
+
+
+
+**-asmwriternum** *N*
+
+ Make -gen-asm-writer emit assembly writer number *N*.
+
+
+
+**-class** *class Name*
+
+ Print the enumeration list for this class.
+
+
+
+**-print-records**
+
+ Print all records to standard output (default).
+
+
+
+**-print-enums**
+
+ Print enumeration values for a class
+
+
+
+**-print-sets**
+
+ Print expanded sets for testing DAG exprs.
+
+
+
+**-gen-emitter**
+
+ Generate machine code emitter.
+
+
+
+**-gen-register-info**
+
+ Generate registers and register classes info.
+
+
+
+**-gen-instr-info**
+
+ Generate instruction descriptions.
+
+
+
+**-gen-asm-writer**
+
+ Generate the assembly writer.
+
+
+
+**-gen-disassembler**
+
+ Generate disassembler.
+
+
+
+**-gen-pseudo-lowering**
+
+ Generate pseudo instruction lowering.
+
+
+
+**-gen-dag-isel**
+
+ Generate a DAG (Directed Acycle Graph) instruction selector.
+
+
+
+**-gen-asm-matcher**
+
+ Generate assembly instruction matcher.
+
+
+
+**-gen-dfa-packetizer**
+
+ Generate DFA Packetizer for VLIW targets.
+
+
+
+**-gen-fast-isel**
+
+ Generate a "fast" instruction selector.
+
+
+
+**-gen-subtarget**
+
+ Generate subtarget enumerations.
+
+
+
+**-gen-intrinsic**
+
+ Generate intrinsic information.
+
+
+
+**-gen-tgt-intrinsic**
+
+ Generate target intrinsic information.
+
+
+
+**-gen-enhanced-disassembly-info**
+
+ Generate enhanced disassembly info.
+
+
+
+**-version**
+
+ Show the version number of this program.
+
+
+
+
+EXIT STATUS
+-----------
+
+
+If **tblgen** succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.

Added: www-releases/trunk/3.2/docs/CommandLine.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CommandLine.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CommandLine.rst (added)
+++ www-releases/trunk/3.2/docs/CommandLine.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,1615 @@
+.. _commandline:
+
+==============================
+CommandLine 2.0 Library Manual
+==============================
+
+Introduction
+============
+
+This document describes the CommandLine argument processing library.  It will
+show you how to use it, and what it can do.  The CommandLine library uses a
+declarative approach to specifying the command line options that your program
+takes.  By default, these options declarations implicitly hold the value parsed
+for the option declared (of course this `can be changed`_).
+
+Although there are a **lot** of command line argument parsing libraries out
+there in many different languages, none of them fit well with what I needed.  By
+looking at the features and problems of other libraries, I designed the
+CommandLine library to have the following features:
+
+#. Speed: The CommandLine library is very quick and uses little resources.  The
+   parsing time of the library is directly proportional to the number of
+   arguments parsed, not the number of options recognized.  Additionally,
+   command line argument values are captured transparently into user defined
+   global variables, which can be accessed like any other variable (and with the
+   same performance).
+
+#. Type Safe: As a user of CommandLine, you don't have to worry about
+   remembering the type of arguments that you want (is it an int?  a string? a
+   bool? an enum?) and keep casting it around.  Not only does this help prevent
+   error prone constructs, it also leads to dramatically cleaner source code.
+
+#. No subclasses required: To use CommandLine, you instantiate variables that
+   correspond to the arguments that you would like to capture, you don't
+   subclass a parser.  This means that you don't have to write **any**
+   boilerplate code.
+
+#. Globally accessible: Libraries can specify command line arguments that are
+   automatically enabled in any tool that links to the library.  This is
+   possible because the application doesn't have to keep a list of arguments to
+   pass to the parser.  This also makes supporting `dynamically loaded options`_
+   trivial.
+
+#. Cleaner: CommandLine supports enum and other types directly, meaning that
+   there is less error and more security built into the library.  You don't have
+   to worry about whether your integral command line argument accidentally got
+   assigned a value that is not valid for your enum type.
+
+#. Powerful: The CommandLine library supports many different types of arguments,
+   from simple `boolean flags`_ to `scalars arguments`_ (`strings`_,
+   `integers`_, `enums`_, `doubles`_), to `lists of arguments`_.  This is
+   possible because CommandLine is...
+
+#. Extensible: It is very simple to add a new argument type to CommandLine.
+   Simply specify the parser that you want to use with the command line option
+   when you declare it. `Custom parsers`_ are no problem.
+
+#. Labor Saving: The CommandLine library cuts down on the amount of grunt work
+   that you, the user, have to do.  For example, it automatically provides a
+   ``-help`` option that shows the available command line options for your tool.
+   Additionally, it does most of the basic correctness checking for you.
+
+#. Capable: The CommandLine library can handle lots of different forms of
+   options often found in real programs.  For example, `positional`_ arguments,
+   ``ls`` style `grouping`_ options (to allow processing '``ls -lad``'
+   naturally), ``ld`` style `prefix`_ options (to parse '``-lmalloc
+   -L/usr/lib``'), and interpreter style options.
+
+This document will hopefully let you jump in and start using CommandLine in your
+utility quickly and painlessly.  Additionally it should be a simple reference
+manual to figure out how stuff works.  If it is failing in some area (or you
+want an extension to the library), nag the author, `Chris
+Lattner <mailto:sabre at nondot.org>`_.
+
+Quick Start Guide
+=================
+
+This section of the manual runs through a simple CommandLine'ification of a
+basic compiler tool.  This is intended to show you how to jump into using the
+CommandLine library in your own program, and show you some of the cool things it
+can do.
+
+To start out, you need to include the CommandLine header file into your program:
+
+.. code-block:: c++
+
+  #include "llvm/Support/CommandLine.h"
+
+Additionally, you need to add this as the first line of your main program:
+
+.. code-block:: c++
+
+  int main(int argc, char **argv) {
+    cl::ParseCommandLineOptions(argc, argv);
+    ...
+  }
+
+... which actually parses the arguments and fills in the variable declarations.
+
+Now that you are ready to support command line arguments, we need to tell the
+system which ones we want, and what type of arguments they are.  The CommandLine
+library uses a declarative syntax to model command line arguments with the
+global variable declarations that capture the parsed values.  This means that
+for every command line option that you would like to support, there should be a
+global variable declaration to capture the result.  For example, in a compiler,
+we would like to support the Unix-standard '``-o <filename>``' option to specify
+where to put the output.  With the CommandLine library, this is represented like
+this:
+
+.. _scalars arguments:
+.. _here:
+
+.. code-block:: c++
+
+  cl::opt<string> OutputFilename("o", cl::desc("Specify output filename"), cl::value_desc("filename"));
+
+This declares a global variable "``OutputFilename``" that is used to capture the
+result of the "``o``" argument (first parameter).  We specify that this is a
+simple scalar option by using the "``cl::opt``" template (as opposed to the
+"``cl::list``" template), and tell the CommandLine library that the data
+type that we are parsing is a string.
+
+The second and third parameters (which are optional) are used to specify what to
+output for the "``-help``" option.  In this case, we get a line that looks like
+this:
+
+::
+
+  USAGE: compiler [options]
+
+  OPTIONS:
+    -help             - display available options (-help-hidden for more)
+    -o <filename>     - Specify output filename
+
+Because we specified that the command line option should parse using the
+``string`` data type, the variable declared is automatically usable as a real
+string in all contexts that a normal C++ string object may be used.  For
+example:
+
+.. code-block:: c++
+
+  ...
+  std::ofstream Output(OutputFilename.c_str());
+  if (Output.good()) ...
+  ...
+
+There are many different options that you can use to customize the command line
+option handling library, but the above example shows the general interface to
+these options.  The options can be specified in any order, and are specified
+with helper functions like `cl::desc(...)`_, so there are no positional
+dependencies to remember.  The available options are discussed in detail in the
+`Reference Guide`_.
+
+Continuing the example, we would like to have our compiler take an input
+filename as well as an output filename, but we do not want the input filename to
+be specified with a hyphen (ie, not ``-filename.c``).  To support this style of
+argument, the CommandLine library allows for `positional`_ arguments to be
+specified for the program.  These positional arguments are filled with command
+line parameters that are not in option form.  We use this feature like this:
+
+.. code-block:: c++
+
+
+  cl::opt<string> InputFilename(cl::Positional, cl::desc("<input file>"), cl::init("-"));
+
+This declaration indicates that the first positional argument should be treated
+as the input filename.  Here we use the `cl::init`_ option to specify an initial
+value for the command line option, which is used if the option is not specified
+(if you do not specify a `cl::init`_ modifier for an option, then the default
+constructor for the data type is used to initialize the value).  Command line
+options default to being optional, so if we would like to require that the user
+always specify an input filename, we would add the `cl::Required`_ flag, and we
+could eliminate the `cl::init`_ modifier, like this:
+
+.. code-block:: c++
+
+  cl::opt<string> InputFilename(cl::Positional, cl::desc("<input file>"), cl::Required);
+
+Again, the CommandLine library does not require the options to be specified in
+any particular order, so the above declaration is equivalent to:
+
+.. code-block:: c++
+
+  cl::opt<string> InputFilename(cl::Positional, cl::Required, cl::desc("<input file>"));
+
+By simply adding the `cl::Required`_ flag, the CommandLine library will
+automatically issue an error if the argument is not specified, which shifts all
+of the command line option verification code out of your application into the
+library.  This is just one example of how using flags can alter the default
+behaviour of the library, on a per-option basis.  By adding one of the
+declarations above, the ``-help`` option synopsis is now extended to:
+
+::
+
+  USAGE: compiler [options] <input file>
+
+  OPTIONS:
+    -help             - display available options (-help-hidden for more)
+    -o <filename>     - Specify output filename
+
+... indicating that an input filename is expected.
+
+Boolean Arguments
+-----------------
+
+In addition to input and output filenames, we would like the compiler example to
+support three boolean flags: "``-f``" to force writing binary output to a
+terminal, "``--quiet``" to enable quiet mode, and "``-q``" for backwards
+compatibility with some of our users.  We can support these by declaring options
+of boolean type like this:
+
+.. code-block:: c++
+
+  cl::opt<bool> Force ("f", cl::desc("Enable binary output on terminals"));
+  cl::opt<bool> Quiet ("quiet", cl::desc("Don't print informational messages"));
+  cl::opt<bool> Quiet2("q", cl::desc("Don't print informational messages"), cl::Hidden);
+
+This does what you would expect: it declares three boolean variables
+("``Force``", "``Quiet``", and "``Quiet2``") to recognize these options.  Note
+that the "``-q``" option is specified with the "`cl::Hidden`_" flag.  This
+modifier prevents it from being shown by the standard "``-help``" output (note
+that it is still shown in the "``-help-hidden``" output).
+
+The CommandLine library uses a `different parser`_ for different data types.
+For example, in the string case, the argument passed to the option is copied
+literally into the content of the string variable... we obviously cannot do that
+in the boolean case, however, so we must use a smarter parser.  In the case of
+the boolean parser, it allows no options (in which case it assigns the value of
+true to the variable), or it allows the values "``true``" or "``false``" to be
+specified, allowing any of the following inputs:
+
+::
+
+  compiler -f          # No value, 'Force' == true
+  compiler -f=true     # Value specified, 'Force' == true
+  compiler -f=TRUE     # Value specified, 'Force' == true
+  compiler -f=FALSE    # Value specified, 'Force' == false
+
+... you get the idea.  The `bool parser`_ just turns the string values into
+boolean values, and rejects things like '``compiler -f=foo``'.  Similarly, the
+`float`_, `double`_, and `int`_ parsers work like you would expect, using the
+'``strtol``' and '``strtod``' C library calls to parse the string value into the
+specified data type.
+
+With the declarations above, "``compiler -help``" emits this:
+
+::
+
+  USAGE: compiler [options] <input file>
+
+  OPTIONS:
+    -f     - Enable binary output on terminals
+    -o     - Override output filename
+    -quiet - Don't print informational messages
+    -help  - display available options (-help-hidden for more)
+
+and "``compiler -help-hidden``" prints this:
+
+::
+
+  USAGE: compiler [options] <input file>
+
+  OPTIONS:
+    -f     - Enable binary output on terminals
+    -o     - Override output filename
+    -q     - Don't print informational messages
+    -quiet - Don't print informational messages
+    -help  - display available options (-help-hidden for more)
+
+This brief example has shown you how to use the '`cl::opt`_' class to parse
+simple scalar command line arguments.  In addition to simple scalar arguments,
+the CommandLine library also provides primitives to support CommandLine option
+`aliases`_, and `lists`_ of options.
+
+.. _aliases:
+
+Argument Aliases
+----------------
+
+So far, the example works well, except for the fact that we need to check the
+quiet condition like this now:
+
+.. code-block:: c++
+
+  ...
+    if (!Quiet && !Quiet2) printInformationalMessage(...);
+  ...
+
+... which is a real pain!  Instead of defining two values for the same
+condition, we can use the "`cl::alias`_" class to make the "``-q``" option an
+**alias** for the "``-quiet``" option, instead of providing a value itself:
+
+.. code-block:: c++
+
+  cl::opt<bool> Force ("f", cl::desc("Overwrite output files"));
+  cl::opt<bool> Quiet ("quiet", cl::desc("Don't print informational messages"));
+  cl::alias     QuietA("q", cl::desc("Alias for -quiet"), cl::aliasopt(Quiet));
+
+The third line (which is the only one we modified from above) defines a "``-q``"
+alias that updates the "``Quiet``" variable (as specified by the `cl::aliasopt`_
+modifier) whenever it is specified.  Because aliases do not hold state, the only
+thing the program has to query is the ``Quiet`` variable now.  Another nice
+feature of aliases is that they automatically hide themselves from the ``-help``
+output (although, again, they are still visible in the ``-help-hidden output``).
+
+Now the application code can simply use:
+
+.. code-block:: c++
+
+  ...
+    if (!Quiet) printInformationalMessage(...);
+  ...
+
+... which is much nicer!  The "`cl::alias`_" can be used to specify an
+alternative name for any variable type, and has many uses.
+
+.. _unnamed alternatives using the generic parser:
+
+Selecting an alternative from a set of possibilities
+----------------------------------------------------
+
+So far we have seen how the CommandLine library handles builtin types like
+``std::string``, ``bool`` and ``int``, but how does it handle things it doesn't
+know about, like enums or '``int*``'s?
+
+The answer is that it uses a table-driven generic parser (unless you specify
+your own parser, as described in the `Extension Guide`_).  This parser maps
+literal strings to whatever type is required, and requires you to tell it what
+this mapping should be.
+
+Let's say that we would like to add four optimization levels to our optimizer,
+using the standard flags "``-g``", "``-O0``", "``-O1``", and "``-O2``".  We
+could easily implement this with boolean options like above, but there are
+several problems with this strategy:
+
+#. A user could specify more than one of the options at a time, for example,
+   "``compiler -O3 -O2``".  The CommandLine library would not be able to catch
+   this erroneous input for us.
+
+#. We would have to test 4 different variables to see which ones are set.
+
+#. This doesn't map to the numeric levels that we want... so we cannot easily
+   see if some level >= "``-O1``" is enabled.
+
+To cope with these problems, we can use an enum value, and have the CommandLine
+library fill it in with the appropriate level directly, which is used like this:
+
+.. code-block:: c++
+
+  enum OptLevel {
+    g, O1, O2, O3
+  };
+
+  cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),
+    cl::values(
+      clEnumVal(g , "No optimizations, enable debugging"),
+      clEnumVal(O1, "Enable trivial optimizations"),
+      clEnumVal(O2, "Enable default optimizations"),
+      clEnumVal(O3, "Enable expensive optimizations"),
+     clEnumValEnd));
+
+  ...
+    if (OptimizationLevel >= O2) doPartialRedundancyElimination(...);
+  ...
+
+This declaration defines a variable "``OptimizationLevel``" of the
+"``OptLevel``" enum type.  This variable can be assigned any of the values that
+are listed in the declaration (Note that the declaration list must be terminated
+with the "``clEnumValEnd``" argument!).  The CommandLine library enforces that
+the user can only specify one of the options, and it ensure that only valid enum
+values can be specified.  The "``clEnumVal``" macros ensure that the command
+line arguments matched the enum values.  With this option added, our help output
+now is:
+
+::
+
+  USAGE: compiler [options] <input file>
+
+  OPTIONS:
+    Choose optimization level:
+      -g          - No optimizations, enable debugging
+      -O1         - Enable trivial optimizations
+      -O2         - Enable default optimizations
+      -O3         - Enable expensive optimizations
+    -f            - Enable binary output on terminals
+    -help         - display available options (-help-hidden for more)
+    -o <filename> - Specify output filename
+    -quiet        - Don't print informational messages
+
+In this case, it is sort of awkward that flag names correspond directly to enum
+names, because we probably don't want a enum definition named "``g``" in our
+program.  Because of this, we can alternatively write this example like this:
+
+.. code-block:: c++
+
+  enum OptLevel {
+    Debug, O1, O2, O3
+  };
+
+  cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),
+    cl::values(
+     clEnumValN(Debug, "g", "No optimizations, enable debugging"),
+      clEnumVal(O1        , "Enable trivial optimizations"),
+      clEnumVal(O2        , "Enable default optimizations"),
+      clEnumVal(O3        , "Enable expensive optimizations"),
+     clEnumValEnd));
+
+  ...
+    if (OptimizationLevel == Debug) outputDebugInfo(...);
+  ...
+
+By using the "``clEnumValN``" macro instead of "``clEnumVal``", we can directly
+specify the name that the flag should get.  In general a direct mapping is nice,
+but sometimes you can't or don't want to preserve the mapping, which is when you
+would use it.
+
+Named Alternatives
+------------------
+
+Another useful argument form is a named alternative style.  We shall use this
+style in our compiler to specify different debug levels that can be used.
+Instead of each debug level being its own switch, we want to support the
+following options, of which only one can be specified at a time:
+"``--debug-level=none``", "``--debug-level=quick``",
+"``--debug-level=detailed``".  To do this, we use the exact same format as our
+optimization level flags, but we also specify an option name.  For this case,
+the code looks like this:
+
+.. code-block:: c++
+
+  enum DebugLev {
+    nodebuginfo, quick, detailed
+  };
+
+  // Enable Debug Options to be specified on the command line
+  cl::opt<DebugLev> DebugLevel("debug_level", cl::desc("Set the debugging level:"),
+    cl::values(
+      clEnumValN(nodebuginfo, "none", "disable debug information"),
+       clEnumVal(quick,               "enable quick debug information"),
+       clEnumVal(detailed,            "enable detailed debug information"),
+      clEnumValEnd));
+
+This definition defines an enumerated command line variable of type "``enum
+DebugLev``", which works exactly the same way as before.  The difference here is
+just the interface exposed to the user of your program and the help output by
+the "``-help``" option:
+
+::
+
+  USAGE: compiler [options] <input file>
+
+  OPTIONS:
+    Choose optimization level:
+      -g          - No optimizations, enable debugging
+      -O1         - Enable trivial optimizations
+      -O2         - Enable default optimizations
+      -O3         - Enable expensive optimizations
+    -debug_level  - Set the debugging level:
+      =none       - disable debug information
+      =quick      - enable quick debug information
+      =detailed   - enable detailed debug information
+    -f            - Enable binary output on terminals
+    -help         - display available options (-help-hidden for more)
+    -o <filename> - Specify output filename
+    -quiet        - Don't print informational messages
+
+Again, the only structural difference between the debug level declaration and
+the optimization level declaration is that the debug level declaration includes
+an option name (``"debug_level"``), which automatically changes how the library
+processes the argument.  The CommandLine library supports both forms so that you
+can choose the form most appropriate for your application.
+
+.. _lists:
+
+Parsing a list of options
+-------------------------
+
+Now that we have the standard run-of-the-mill argument types out of the way,
+lets get a little wild and crazy.  Lets say that we want our optimizer to accept
+a **list** of optimizations to perform, allowing duplicates.  For example, we
+might want to run: "``compiler -dce -constprop -inline -dce -strip``".  In this
+case, the order of the arguments and the number of appearances is very
+important.  This is what the "``cl::list``" template is for.  First, start by
+defining an enum of the optimizations that you would like to perform:
+
+.. code-block:: c++
+
+  enum Opts {
+    // 'inline' is a C++ keyword, so name it 'inlining'
+    dce, constprop, inlining, strip
+  };
+
+Then define your "``cl::list``" variable:
+
+.. code-block:: c++
+
+  cl::list<Opts> OptimizationList(cl::desc("Available Optimizations:"),
+    cl::values(
+      clEnumVal(dce               , "Dead Code Elimination"),
+      clEnumVal(constprop         , "Constant Propagation"),
+     clEnumValN(inlining, "inline", "Procedure Integration"),
+      clEnumVal(strip             , "Strip Symbols"),
+    clEnumValEnd));
+
+This defines a variable that is conceptually of the type
+"``std::vector<enum Opts>``".  Thus, you can access it with standard vector
+methods:
+
+.. code-block:: c++
+
+  for (unsigned i = 0; i != OptimizationList.size(); ++i)
+    switch (OptimizationList[i])
+       ...
+
+... to iterate through the list of options specified.
+
+Note that the "``cl::list``" template is completely general and may be used with
+any data types or other arguments that you can use with the "``cl::opt``"
+template.  One especially useful way to use a list is to capture all of the
+positional arguments together if there may be more than one specified.  In the
+case of a linker, for example, the linker takes several '``.o``' files, and
+needs to capture them into a list.  This is naturally specified as:
+
+.. code-block:: c++
+
+  ...
+  cl::list<std::string> InputFilenames(cl::Positional, cl::desc("<Input files>"), cl::OneOrMore);
+  ...
+
+This variable works just like a "``vector<string>``" object.  As such, accessing
+the list is simple, just like above.  In this example, we used the
+`cl::OneOrMore`_ modifier to inform the CommandLine library that it is an error
+if the user does not specify any ``.o`` files on our command line.  Again, this
+just reduces the amount of checking we have to do.
+
+Collecting options as a set of flags
+------------------------------------
+
+Instead of collecting sets of options in a list, it is also possible to gather
+information for enum values in a **bit vector**.  The representation used by the
+`cl::bits`_ class is an ``unsigned`` integer.  An enum value is represented by a
+0/1 in the enum's ordinal value bit position. 1 indicating that the enum was
+specified, 0 otherwise.  As each specified value is parsed, the resulting enum's
+bit is set in the option's bit vector:
+
+.. code-block:: c++
+
+  bits |= 1 << (unsigned)enum;
+
+Options that are specified multiple times are redundant.  Any instances after
+the first are discarded.
+
+Reworking the above list example, we could replace `cl::list`_ with `cl::bits`_:
+
+.. code-block:: c++
+
+  cl::bits<Opts> OptimizationBits(cl::desc("Available Optimizations:"),
+    cl::values(
+      clEnumVal(dce               , "Dead Code Elimination"),
+      clEnumVal(constprop         , "Constant Propagation"),
+     clEnumValN(inlining, "inline", "Procedure Integration"),
+      clEnumVal(strip             , "Strip Symbols"),
+    clEnumValEnd));
+
+To test to see if ``constprop`` was specified, we can use the ``cl:bits::isSet``
+function:
+
+.. code-block:: c++
+
+  if (OptimizationBits.isSet(constprop)) {
+    ...
+  }
+
+It's also possible to get the raw bit vector using the ``cl::bits::getBits``
+function:
+
+.. code-block:: c++
+
+  unsigned bits = OptimizationBits.getBits();
+
+Finally, if external storage is used, then the location specified must be of
+**type** ``unsigned``. In all other ways a `cl::bits`_ option is equivalent to a
+`cl::list`_ option.
+
+.. _additional extra text:
+
+Adding freeform text to help output
+-----------------------------------
+
+As our program grows and becomes more mature, we may decide to put summary
+information about what it does into the help output.  The help output is styled
+to look similar to a Unix ``man`` page, providing concise information about a
+program.  Unix ``man`` pages, however often have a description about what the
+program does.  To add this to your CommandLine program, simply pass a third
+argument to the `cl::ParseCommandLineOptions`_ call in main.  This additional
+argument is then printed as the overview information for your program, allowing
+you to include any additional information that you want.  For example:
+
+.. code-block:: c++
+
+  int main(int argc, char **argv) {
+    cl::ParseCommandLineOptions(argc, argv, " CommandLine compiler example\n\n"
+                                "  This program blah blah blah...\n");
+    ...
+  }
+
+would yield the help output:
+
+::
+
+  **OVERVIEW: CommandLine compiler example
+
+    This program blah blah blah...**
+
+  USAGE: compiler [options] <input file>
+
+  OPTIONS:
+    ...
+    -help             - display available options (-help-hidden for more)
+    -o <filename>     - Specify output filename
+
+.. _Reference Guide:
+
+Reference Guide
+===============
+
+Now that you know the basics of how to use the CommandLine library, this section
+will give you the detailed information you need to tune how command line options
+work, as well as information on more "advanced" command line option processing
+capabilities.
+
+.. _positional:
+.. _positional argument:
+.. _Positional Arguments:
+.. _Positional arguments section:
+.. _positional options:
+
+Positional Arguments
+--------------------
+
+Positional arguments are those arguments that are not named, and are not
+specified with a hyphen.  Positional arguments should be used when an option is
+specified by its position alone.  For example, the standard Unix ``grep`` tool
+takes a regular expression argument, and an optional filename to search through
+(which defaults to standard input if a filename is not specified).  Using the
+CommandLine library, this would be specified as:
+
+.. code-block:: c++
+
+  cl::opt<string> Regex   (cl::Positional, cl::desc("<regular expression>"), cl::Required);
+  cl::opt<string> Filename(cl::Positional, cl::desc("<input file>"), cl::init("-"));
+
+Given these two option declarations, the ``-help`` output for our grep
+replacement would look like this:
+
+::
+
+  USAGE: spiffygrep [options] <regular expression> <input file>
+
+  OPTIONS:
+    -help - display available options (-help-hidden for more)
+
+... and the resultant program could be used just like the standard ``grep``
+tool.
+
+Positional arguments are sorted by their order of construction.  This means that
+command line options will be ordered according to how they are listed in a .cpp
+file, but will not have an ordering defined if the positional arguments are
+defined in multiple .cpp files.  The fix for this problem is simply to define
+all of your positional arguments in one .cpp file.
+
+Specifying positional options with hyphens
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sometimes you may want to specify a value to your positional argument that
+starts with a hyphen (for example, searching for '``-foo``' in a file).  At
+first, you will have trouble doing this, because it will try to find an argument
+named '``-foo``', and will fail (and single quotes will not save you).  Note
+that the system ``grep`` has the same problem:
+
+::
+
+  $ spiffygrep '-foo' test.txt
+  Unknown command line argument '-foo'.  Try: spiffygrep -help'
+
+  $ grep '-foo' test.txt
+  grep: illegal option -- f
+  grep: illegal option -- o
+  grep: illegal option -- o
+  Usage: grep -hblcnsviw pattern file . . .
+
+The solution for this problem is the same for both your tool and the system
+version: use the '``--``' marker.  When the user specifies '``--``' on the
+command line, it is telling the program that all options after the '``--``'
+should be treated as positional arguments, not options.  Thus, we can use it
+like this:
+
+::
+
+  $ spiffygrep -- -foo test.txt
+    ...output...
+
+Determining absolute position with getPosition()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sometimes an option can affect or modify the meaning of another option. For
+example, consider ``gcc``'s ``-x LANG`` option. This tells ``gcc`` to ignore the
+suffix of subsequent positional arguments and force the file to be interpreted
+as if it contained source code in language ``LANG``. In order to handle this
+properly, you need to know the absolute position of each argument, especially
+those in lists, so their interaction(s) can be applied correctly. This is also
+useful for options like ``-llibname`` which is actually a positional argument
+that starts with a dash.
+
+So, generally, the problem is that you have two ``cl::list`` variables that
+interact in some way. To ensure the correct interaction, you can use the
+``cl::list::getPosition(optnum)`` method. This method returns the absolute
+position (as found on the command line) of the ``optnum`` item in the
+``cl::list``.
+
+The idiom for usage is like this:
+
+.. code-block:: c++
+
+  static cl::list<std::string> Files(cl::Positional, cl::OneOrMore);
+  static cl::list<std::string> Libraries("l", cl::ZeroOrMore);
+
+  int main(int argc, char**argv) {
+    // ...
+    std::vector<std::string>::iterator fileIt = Files.begin();
+    std::vector<std::string>::iterator libIt  = Libraries.begin();
+    unsigned libPos = 0, filePos = 0;
+    while ( 1 ) {
+      if ( libIt != Libraries.end() )
+        libPos = Libraries.getPosition( libIt - Libraries.begin() );
+      else
+        libPos = 0;
+      if ( fileIt != Files.end() )
+        filePos = Files.getPosition( fileIt - Files.begin() );
+      else
+        filePos = 0;
+
+      if ( filePos != 0 && (libPos == 0 || filePos < libPos) ) {
+        // Source File Is next
+        ++fileIt;
+      }
+      else if ( libPos != 0 && (filePos == 0 || libPos < filePos) ) {
+        // Library is next
+        ++libIt;
+      }
+      else
+        break; // we're done with the list
+    }
+  }
+
+Note that, for compatibility reasons, the ``cl::opt`` also supports an
+``unsigned getPosition()`` option that will provide the absolute position of
+that option. You can apply the same approach as above with a ``cl::opt`` and a
+``cl::list`` option as you can with two lists.
+
+.. _interpreter style options:
+.. _cl::ConsumeAfter:
+.. _this section for more information:
+
+The ``cl::ConsumeAfter`` modifier
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::ConsumeAfter`` `formatting option`_ is used to construct programs that
+use "interpreter style" option processing.  With this style of option
+processing, all arguments specified after the last positional argument are
+treated as special interpreter arguments that are not interpreted by the command
+line argument.
+
+As a concrete example, lets say we are developing a replacement for the standard
+Unix Bourne shell (``/bin/sh``).  To run ``/bin/sh``, first you specify options
+to the shell itself (like ``-x`` which turns on trace output), then you specify
+the name of the script to run, then you specify arguments to the script.  These
+arguments to the script are parsed by the Bourne shell command line option
+processor, but are not interpreted as options to the shell itself.  Using the
+CommandLine library, we would specify this as:
+
+.. code-block:: c++
+
+  cl::opt<string> Script(cl::Positional, cl::desc("<input script>"), cl::init("-"));
+  cl::list<string>  Argv(cl::ConsumeAfter, cl::desc("<program arguments>..."));
+  cl::opt<bool>    Trace("x", cl::desc("Enable trace output"));
+
+which automatically provides the help output:
+
+::
+
+  USAGE: spiffysh [options] <input script> <program arguments>...
+
+  OPTIONS:
+    -help - display available options (-help-hidden for more)
+    -x    - Enable trace output
+
+At runtime, if we run our new shell replacement as ```spiffysh -x test.sh -a -x
+-y bar``', the ``Trace`` variable will be set to true, the ``Script`` variable
+will be set to "``test.sh``", and the ``Argv`` list will contain ``["-a", "-x",
+"-y", "bar"]``, because they were specified after the last positional argument
+(which is the script name).
+
+There are several limitations to when ``cl::ConsumeAfter`` options can be
+specified.  For example, only one ``cl::ConsumeAfter`` can be specified per
+program, there must be at least one `positional argument`_ specified, there must
+not be any `cl::list`_ positional arguments, and the ``cl::ConsumeAfter`` option
+should be a `cl::list`_ option.
+
+.. _can be changed:
+.. _Internal vs External Storage:
+
+Internal vs External Storage
+----------------------------
+
+By default, all command line options automatically hold the value that they
+parse from the command line.  This is very convenient in the common case,
+especially when combined with the ability to define command line options in the
+files that use them.  This is called the internal storage model.
+
+Sometimes, however, it is nice to separate the command line option processing
+code from the storage of the value parsed.  For example, lets say that we have a
+'``-debug``' option that we would like to use to enable debug information across
+the entire body of our program.  In this case, the boolean value controlling the
+debug code should be globally accessible (in a header file, for example) yet the
+command line option processing code should not be exposed to all of these
+clients (requiring lots of .cpp files to ``#include CommandLine.h``).
+
+To do this, set up your .h file with your option, like this for example:
+
+.. code-block:: c++
+
+  // DebugFlag.h - Get access to the '-debug' command line option
+  //
+
+  // DebugFlag - This boolean is set to true if the '-debug' command line option
+  // is specified.  This should probably not be referenced directly, instead, use
+  // the DEBUG macro below.
+  //
+  extern bool DebugFlag;
+
+  // DEBUG macro - This macro should be used by code to emit debug information.
+  // In the '-debug' option is specified on the command line, and if this is a
+  // debug build, then the code specified as the option to the macro will be
+  // executed.  Otherwise it will not be.
+  #ifdef NDEBUG
+  #define DEBUG(X)
+  #else
+  #define DEBUG(X) do { if (DebugFlag) { X; } } while (0)
+  #endif
+
+This allows clients to blissfully use the ``DEBUG()`` macro, or the
+``DebugFlag`` explicitly if they want to.  Now we just need to be able to set
+the ``DebugFlag`` boolean when the option is set.  To do this, we pass an
+additional argument to our command line argument processor, and we specify where
+to fill in with the `cl::location`_ attribute:
+
+.. code-block:: c++
+
+  bool DebugFlag;                  // the actual value
+  static cl::opt<bool, true>       // The parser
+  Debug("debug", cl::desc("Enable debug output"), cl::Hidden, cl::location(DebugFlag));
+
+In the above example, we specify "``true``" as the second argument to the
+`cl::opt`_ template, indicating that the template should not maintain a copy of
+the value itself.  In addition to this, we specify the `cl::location`_
+attribute, so that ``DebugFlag`` is automatically set.
+
+Option Attributes
+-----------------
+
+This section describes the basic attributes that you can specify on options.
+
+* The option name attribute (which is required for all options, except
+  `positional options`_) specifies what the option name is.  This option is
+  specified in simple double quotes:
+
+  .. code-block:: c++
+
+    cl::opt<**bool**> Quiet("quiet");
+
+.. _cl::desc(...):
+
+* The **cl::desc** attribute specifies a description for the option to be
+  shown in the ``-help`` output for the program.
+
+.. _cl::value_desc:
+
+* The **cl::value_desc** attribute specifies a string that can be used to
+  fine tune the ``-help`` output for a command line option.  Look `here`_ for an
+  example.
+
+.. _cl::init:
+
+* The **cl::init** attribute specifies an initial value for a `scalar`_
+  option.  If this attribute is not specified then the command line option value
+  defaults to the value created by the default constructor for the
+  type.
+
+  .. warning::
+
+    If you specify both **cl::init** and **cl::location** for an option, you
+    must specify **cl::location** first, so that when the command-line parser
+    sees **cl::init**, it knows where to put the initial value. (You will get an
+    error at runtime if you don't put them in the right order.)
+
+.. _cl::location:
+
+* The **cl::location** attribute where to store the value for a parsed command
+  line option if using external storage.  See the section on `Internal vs
+  External Storage`_ for more information.
+
+.. _cl::aliasopt:
+
+* The **cl::aliasopt** attribute specifies which option a `cl::alias`_ option is
+  an alias for.
+
+.. _cl::values:
+
+* The **cl::values** attribute specifies the string-to-value mapping to be used
+  by the generic parser.  It takes a **clEnumValEnd terminated** list of
+  (option, value, description) triplets that specify the option name, the value
+  mapped to, and the description shown in the ``-help`` for the tool.  Because
+  the generic parser is used most frequently with enum values, two macros are
+  often useful:
+
+  #. The **clEnumVal** macro is used as a nice simple way to specify a triplet
+     for an enum.  This macro automatically makes the option name be the same as
+     the enum name.  The first option to the macro is the enum, the second is
+     the description for the command line option.
+
+  #. The **clEnumValN** macro is used to specify macro options where the option
+     name doesn't equal the enum name.  For this macro, the first argument is
+     the enum value, the second is the flag name, and the second is the
+     description.
+
+  You will get a compile time error if you try to use cl::values with a parser
+  that does not support it.
+
+.. _cl::multi_val:
+
+* The **cl::multi_val** attribute specifies that this option takes has multiple
+  values (example: ``-sectalign segname sectname sectvalue``). This attribute
+  takes one unsigned argument - the number of values for the option. This
+  attribute is valid only on ``cl::list`` options (and will fail with compile
+  error if you try to use it with other option types). It is allowed to use all
+  of the usual modifiers on multi-valued options (besides
+  ``cl::ValueDisallowed``, obviously).
+
+Option Modifiers
+----------------
+
+Option modifiers are the flags and expressions that you pass into the
+constructors for `cl::opt`_ and `cl::list`_.  These modifiers give you the
+ability to tweak how options are parsed and how ``-help`` output is generated to
+fit your application well.
+
+These options fall into five main categories:
+
+#. Hiding an option from ``-help`` output
+
+#. Controlling the number of occurrences required and allowed
+
+#. Controlling whether or not a value must be specified
+
+#. Controlling other formatting options
+
+#. Miscellaneous option modifiers
+
+It is not possible to specify two options from the same category (you'll get a
+runtime error) to a single option, except for options in the miscellaneous
+category.  The CommandLine library specifies defaults for all of these settings
+that are the most useful in practice and the most common, which mean that you
+usually shouldn't have to worry about these.
+
+Hiding an option from ``-help`` output
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::NotHidden``, ``cl::Hidden``, and ``cl::ReallyHidden`` modifiers are
+used to control whether or not an option appears in the ``-help`` and
+``-help-hidden`` output for the compiled program:
+
+.. _cl::NotHidden:
+
+* The **cl::NotHidden** modifier (which is the default for `cl::opt`_ and
+  `cl::list`_ options) indicates the option is to appear in both help
+  listings.
+
+.. _cl::Hidden:
+
+* The **cl::Hidden** modifier (which is the default for `cl::alias`_ options)
+  indicates that the option should not appear in the ``-help`` output, but
+  should appear in the ``-help-hidden`` output.
+
+.. _cl::ReallyHidden:
+
+* The **cl::ReallyHidden** modifier indicates that the option should not appear
+  in any help output.
+
+Controlling the number of occurrences required and allowed
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This group of options is used to control how many time an option is allowed (or
+required) to be specified on the command line of your program.  Specifying a
+value for this setting allows the CommandLine library to do error checking for
+you.
+
+The allowed values for this option group are:
+
+.. _cl::Optional:
+
+* The **cl::Optional** modifier (which is the default for the `cl::opt`_ and
+  `cl::alias`_ classes) indicates that your program will allow either zero or
+  one occurrence of the option to be specified.
+
+.. _cl::ZeroOrMore:
+
+* The **cl::ZeroOrMore** modifier (which is the default for the `cl::list`_
+  class) indicates that your program will allow the option to be specified zero
+  or more times.
+
+.. _cl::Required:
+
+* The **cl::Required** modifier indicates that the specified option must be
+  specified exactly one time.
+
+.. _cl::OneOrMore:
+
+* The **cl::OneOrMore** modifier indicates that the option must be specified at
+  least one time.
+
+* The **cl::ConsumeAfter** modifier is described in the `Positional arguments
+  section`_.
+
+If an option is not specified, then the value of the option is equal to the
+value specified by the `cl::init`_ attribute.  If the ``cl::init`` attribute is
+not specified, the option value is initialized with the default constructor for
+the data type.
+
+If an option is specified multiple times for an option of the `cl::opt`_ class,
+only the last value will be retained.
+
+Controlling whether or not a value must be specified
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This group of options is used to control whether or not the option allows a
+value to be present.  In the case of the CommandLine library, a value is either
+specified with an equal sign (e.g. '``-index-depth=17``') or as a trailing
+string (e.g. '``-o a.out``').
+
+The allowed values for this option group are:
+
+.. _cl::ValueOptional:
+
+* The **cl::ValueOptional** modifier (which is the default for ``bool`` typed
+  options) specifies that it is acceptable to have a value, or not.  A boolean
+  argument can be enabled just by appearing on the command line, or it can have
+  an explicit '``-foo=true``'.  If an option is specified with this mode, it is
+  illegal for the value to be provided without the equal sign.  Therefore
+  '``-foo true``' is illegal.  To get this behavior, you must use
+  the `cl::ValueRequired`_ modifier.
+
+.. _cl::ValueRequired:
+
+* The **cl::ValueRequired** modifier (which is the default for all other types
+  except for `unnamed alternatives using the generic parser`_) specifies that a
+  value must be provided.  This mode informs the command line library that if an
+  option is not provides with an equal sign, that the next argument provided
+  must be the value.  This allows things like '``-o a.out``' to work.
+
+.. _cl::ValueDisallowed:
+
+* The **cl::ValueDisallowed** modifier (which is the default for `unnamed
+  alternatives using the generic parser`_) indicates that it is a runtime error
+  for the user to specify a value.  This can be provided to disallow users from
+  providing options to boolean options (like '``-foo=true``').
+
+In general, the default values for this option group work just like you would
+want them to.  As mentioned above, you can specify the `cl::ValueDisallowed`_
+modifier to a boolean argument to restrict your command line parser.  These
+options are mostly useful when `extending the library`_.
+
+.. _formatting option:
+
+Controlling other formatting options
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The formatting option group is used to specify that the command line option has
+special abilities and is otherwise different from other command line arguments.
+As usual, you can only specify one of these arguments at most.
+
+.. _cl::NormalFormatting:
+
+* The **cl::NormalFormatting** modifier (which is the default all options)
+  specifies that this option is "normal".
+
+.. _cl::Positional:
+
+* The **cl::Positional** modifier specifies that this is a positional argument
+  that does not have a command line option associated with it.  See the
+  `Positional Arguments`_ section for more information.
+
+* The **cl::ConsumeAfter** modifier specifies that this option is used to
+  capture "interpreter style" arguments.  See `this section for more
+  information`_.
+
+.. _prefix:
+.. _cl::Prefix:
+
+* The **cl::Prefix** modifier specifies that this option prefixes its value.
+  With 'Prefix' options, the equal sign does not separate the value from the
+  option name specified. Instead, the value is everything after the prefix,
+  including any equal sign if present. This is useful for processing odd
+  arguments like ``-lmalloc`` and ``-L/usr/lib`` in a linker tool or
+  ``-DNAME=value`` in a compiler tool.  Here, the '``l``', '``D``' and '``L``'
+  options are normal string (or list) options, that have the **cl::Prefix**
+  modifier added to allow the CommandLine library to recognize them.  Note that
+  **cl::Prefix** options must not have the **cl::ValueDisallowed** modifier
+  specified.
+
+.. _grouping:
+.. _cl::Grouping:
+
+* The **cl::Grouping** modifier is used to implement Unix-style tools (like
+  ``ls``) that have lots of single letter arguments, but only require a single
+  dash.  For example, the '``ls -labF``' command actually enables four different
+  options, all of which are single letters.  Note that **cl::Grouping** options
+  cannot have values.
+
+The CommandLine library does not restrict how you use the **cl::Prefix** or
+**cl::Grouping** modifiers, but it is possible to specify ambiguous argument
+settings.  Thus, it is possible to have multiple letter options that are prefix
+or grouping options, and they will still work as designed.
+
+To do this, the CommandLine library uses a greedy algorithm to parse the input
+option into (potentially multiple) prefix and grouping options.  The strategy
+basically looks like this:
+
+::
+
+  parse(string OrigInput) {
+
+  1. string input = OrigInput;
+  2. if (isOption(input)) return getOption(input).parse();  // Normal option
+  3. while (!isOption(input) && !input.empty()) input.pop_back();  // Remove the last letter
+  4. if (input.empty()) return error();  // No matching option
+  5. if (getOption(input).isPrefix())
+       return getOption(input).parse(input);
+  6. while (!input.empty()) {  // Must be grouping options
+       getOption(input).parse();
+       OrigInput.erase(OrigInput.begin(), OrigInput.begin()+input.length());
+       input = OrigInput;
+       while (!isOption(input) && !input.empty()) input.pop_back();
+     }
+  7. if (!OrigInput.empty()) error();
+
+  }
+
+Miscellaneous option modifiers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The miscellaneous option modifiers are the only flags where you can specify more
+than one flag from the set: they are not mutually exclusive.  These flags
+specify boolean properties that modify the option.
+
+.. _cl::CommaSeparated:
+
+* The **cl::CommaSeparated** modifier indicates that any commas specified for an
+  option's value should be used to split the value up into multiple values for
+  the option.  For example, these two options are equivalent when
+  ``cl::CommaSeparated`` is specified: "``-foo=a -foo=b -foo=c``" and
+  "``-foo=a,b,c``".  This option only makes sense to be used in a case where the
+  option is allowed to accept one or more values (i.e. it is a `cl::list`_
+  option).
+
+.. _cl::PositionalEatsArgs:
+
+* The **cl::PositionalEatsArgs** modifier (which only applies to positional
+  arguments, and only makes sense for lists) indicates that positional argument
+  should consume any strings after it (including strings that start with a "-")
+  up until another recognized positional argument.  For example, if you have two
+  "eating" positional arguments, "``pos1``" and "``pos2``", the string "``-pos1
+  -foo -bar baz -pos2 -bork``" would cause the "``-foo -bar -baz``" strings to
+  be applied to the "``-pos1``" option and the "``-bork``" string to be applied
+  to the "``-pos2``" option.
+
+.. _cl::Sink:
+
+* The **cl::Sink** modifier is used to handle unknown options. If there is at
+  least one option with ``cl::Sink`` modifier specified, the parser passes
+  unrecognized option strings to it as values instead of signaling an error. As
+  with ``cl::CommaSeparated``, this modifier only makes sense with a `cl::list`_
+  option.
+
+So far, these are the only three miscellaneous option modifiers.
+
+.. _response files:
+
+Response files
+^^^^^^^^^^^^^^
+
+Some systems, such as certain variants of Microsoft Windows and some older
+Unices have a relatively low limit on command-line length. It is therefore
+customary to use the so-called 'response files' to circumvent this
+restriction. These files are mentioned on the command-line (using the "@file")
+syntax. The program reads these files and inserts the contents into argv,
+thereby working around the command-line length limits. Response files are
+enabled by an optional fourth argument to `cl::ParseEnvironmentOptions`_ and
+`cl::ParseCommandLineOptions`_.
+
+Top-Level Classes and Functions
+-------------------------------
+
+Despite all of the built-in flexibility, the CommandLine option library really
+only consists of one function `cl::ParseCommandLineOptions`_) and three main
+classes: `cl::opt`_, `cl::list`_, and `cl::alias`_.  This section describes
+these three classes in detail.
+
+.. _cl::ParseCommandLineOptions:
+
+The ``cl::ParseCommandLineOptions`` function
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::ParseCommandLineOptions`` function is designed to be called directly
+from ``main``, and is used to fill in the values of all of the command line
+option variables once ``argc`` and ``argv`` are available.
+
+The ``cl::ParseCommandLineOptions`` function requires two parameters (``argc``
+and ``argv``), but may also take an optional third parameter which holds
+`additional extra text`_ to emit when the ``-help`` option is invoked, and a
+fourth boolean parameter that enables `response files`_.
+
+.. _cl::ParseEnvironmentOptions:
+
+The ``cl::ParseEnvironmentOptions`` function
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::ParseEnvironmentOptions`` function has mostly the same effects as
+`cl::ParseCommandLineOptions`_, except that it is designed to take values for
+options from an environment variable, for those cases in which reading the
+command line is not convenient or desired. It fills in the values of all the
+command line option variables just like `cl::ParseCommandLineOptions`_ does.
+
+It takes four parameters: the name of the program (since ``argv`` may not be
+available, it can't just look in ``argv[0]``), the name of the environment
+variable to examine, the optional `additional extra text`_ to emit when the
+``-help`` option is invoked, and the boolean switch that controls whether
+`response files`_ should be read.
+
+``cl::ParseEnvironmentOptions`` will break the environment variable's value up
+into words and then process them using `cl::ParseCommandLineOptions`_.
+**Note:** Currently ``cl::ParseEnvironmentOptions`` does not support quoting, so
+an environment variable containing ``-option "foo bar"`` will be parsed as three
+words, ``-option``, ``"foo``, and ``bar"``, which is different from what you
+would get from the shell with the same input.
+
+The ``cl::SetVersionPrinter`` function
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::SetVersionPrinter`` function is designed to be called directly from
+``main`` and *before* ``cl::ParseCommandLineOptions``. Its use is optional. It
+simply arranges for a function to be called in response to the ``--version``
+option instead of having the ``CommandLine`` library print out the usual version
+string for LLVM. This is useful for programs that are not part of LLVM but wish
+to use the ``CommandLine`` facilities. Such programs should just define a small
+function that takes no arguments and returns ``void`` and that prints out
+whatever version information is appropriate for the program. Pass the address of
+that function to ``cl::SetVersionPrinter`` to arrange for it to be called when
+the ``--version`` option is given by the user.
+
+.. _cl::opt:
+.. _scalar:
+
+The ``cl::opt`` class
+^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::opt`` class is the class used to represent scalar command line
+options, and is the one used most of the time.  It is a templated class which
+can take up to three arguments (all except for the first have default values
+though):
+
+.. code-block:: c++
+
+  namespace cl {
+    template <class DataType, bool ExternalStorage = false,
+              class ParserClass = parser<DataType> >
+    class opt;
+  }
+
+The first template argument specifies what underlying data type the command line
+argument is, and is used to select a default parser implementation.  The second
+template argument is used to specify whether the option should contain the
+storage for the option (the default) or whether external storage should be used
+to contain the value parsed for the option (see `Internal vs External Storage`_
+for more information).
+
+The third template argument specifies which parser to use.  The default value
+selects an instantiation of the ``parser`` class based on the underlying data
+type of the option.  In general, this default works well for most applications,
+so this option is only used when using a `custom parser`_.
+
+.. _lists of arguments:
+.. _cl::list:
+
+The ``cl::list`` class
+^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::list`` class is the class used to represent a list of command line
+options.  It too is a templated class which can take up to three arguments:
+
+.. code-block:: c++
+
+  namespace cl {
+    template <class DataType, class Storage = bool,
+              class ParserClass = parser<DataType> >
+    class list;
+  }
+
+This class works the exact same as the `cl::opt`_ class, except that the second
+argument is the **type** of the external storage, not a boolean value.  For this
+class, the marker type '``bool``' is used to indicate that internal storage
+should be used.
+
+.. _cl::bits:
+
+The ``cl::bits`` class
+^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::bits`` class is the class used to represent a list of command line
+options in the form of a bit vector.  It is also a templated class which can
+take up to three arguments:
+
+.. code-block:: c++
+
+  namespace cl {
+    template <class DataType, class Storage = bool,
+              class ParserClass = parser<DataType> >
+    class bits;
+  }
+
+This class works the exact same as the `cl::list`_ class, except that the second
+argument must be of **type** ``unsigned`` if external storage is used.
+
+.. _cl::alias:
+
+The ``cl::alias`` class
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::alias`` class is a nontemplated class that is used to form aliases for
+other arguments.
+
+.. code-block:: c++
+
+  namespace cl {
+    class alias;
+  }
+
+The `cl::aliasopt`_ attribute should be used to specify which option this is an
+alias for.  Alias arguments default to being `cl::Hidden`_, and use the aliased
+options parser to do the conversion from string to data.
+
+.. _cl::extrahelp:
+
+The ``cl::extrahelp`` class
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``cl::extrahelp`` class is a nontemplated class that allows extra help text
+to be printed out for the ``-help`` option.
+
+.. code-block:: c++
+
+  namespace cl {
+    struct extrahelp;
+  }
+
+To use the extrahelp, simply construct one with a ``const char*`` parameter to
+the constructor. The text passed to the constructor will be printed at the
+bottom of the help message, verbatim. Note that multiple ``cl::extrahelp``
+**can** be used, but this practice is discouraged. If your tool needs to print
+additional help information, put all that help into a single ``cl::extrahelp``
+instance.
+
+For example:
+
+.. code-block:: c++
+
+  cl::extrahelp("\nADDITIONAL HELP:\n\n  This is the extra help\n");
+
+.. _different parser:
+.. _discussed previously:
+
+Builtin parsers
+---------------
+
+Parsers control how the string value taken from the command line is translated
+into a typed value, suitable for use in a C++ program.  By default, the
+CommandLine library uses an instance of ``parser<type>`` if the command line
+option specifies that it uses values of type '``type``'.  Because of this,
+custom option processing is specified with specializations of the '``parser``'
+class.
+
+The CommandLine library provides the following builtin parser specializations,
+which are sufficient for most applications. It can, however, also be extended to
+work with new data types and new ways of interpreting the same data.  See the
+`Writing a Custom Parser`_ for more details on this type of library extension.
+
+.. _enums:
+.. _cl::parser:
+
+* The generic ``parser<t>`` parser can be used to map strings values to any data
+  type, through the use of the `cl::values`_ property, which specifies the
+  mapping information.  The most common use of this parser is for parsing enum
+  values, which allows you to use the CommandLine library for all of the error
+  checking to make sure that only valid enum values are specified (as opposed to
+  accepting arbitrary strings).  Despite this, however, the generic parser class
+  can be used for any data type.
+
+.. _boolean flags:
+.. _bool parser:
+
+* The **parser<bool> specialization** is used to convert boolean strings to a
+  boolean value.  Currently accepted strings are "``true``", "``TRUE``",
+  "``True``", "``1``", "``false``", "``FALSE``", "``False``", and "``0``".
+
+* The **parser<boolOrDefault> specialization** is used for cases where the value
+  is boolean, but we also need to know whether the option was specified at all.
+  boolOrDefault is an enum with 3 values, BOU_UNSET, BOU_TRUE and BOU_FALSE.
+  This parser accepts the same strings as **``parser<bool>``**.
+
+.. _strings:
+
+* The **parser<string> specialization** simply stores the parsed string into the
+  string value specified.  No conversion or modification of the data is
+  performed.
+
+.. _integers:
+.. _int:
+
+* The **parser<int> specialization** uses the C ``strtol`` function to parse the
+  string input.  As such, it will accept a decimal number (with an optional '+'
+  or '-' prefix) which must start with a non-zero digit.  It accepts octal
+  numbers, which are identified with a '``0``' prefix digit, and hexadecimal
+  numbers with a prefix of '``0x``' or '``0X``'.
+
+.. _doubles:
+.. _float:
+.. _double:
+
+* The **parser<double>** and **parser<float> specializations** use the standard
+  C ``strtod`` function to convert floating point strings into floating point
+  values.  As such, a broad range of string formats is supported, including
+  exponential notation (ex: ``1.7e15``) and properly supports locales.
+
+.. _Extension Guide:
+.. _extending the library:
+
+Extension Guide
+===============
+
+Although the CommandLine library has a lot of functionality built into it
+already (as discussed previously), one of its true strengths lie in its
+extensibility.  This section discusses how the CommandLine library works under
+the covers and illustrates how to do some simple, common, extensions.
+
+.. _Custom parsers:
+.. _custom parser:
+.. _Writing a Custom Parser:
+
+Writing a custom parser
+-----------------------
+
+One of the simplest and most common extensions is the use of a custom parser.
+As `discussed previously`_, parsers are the portion of the CommandLine library
+that turns string input from the user into a particular parsed data type,
+validating the input in the process.
+
+There are two ways to use a new parser:
+
+#. Specialize the `cl::parser`_ template for your custom data type.
+
+   This approach has the advantage that users of your custom data type will
+   automatically use your custom parser whenever they define an option with a
+   value type of your data type.  The disadvantage of this approach is that it
+   doesn't work if your fundamental data type is something that is already
+   supported.
+
+#. Write an independent class, using it explicitly from options that need it.
+
+   This approach works well in situations where you would line to parse an
+   option using special syntax for a not-very-special data-type.  The drawback
+   of this approach is that users of your parser have to be aware that they are
+   using your parser instead of the builtin ones.
+
+To guide the discussion, we will discuss a custom parser that accepts file
+sizes, specified with an optional unit after the numeric size.  For example, we
+would like to parse "102kb", "41M", "1G" into the appropriate integer value.  In
+this case, the underlying data type we want to parse into is '``unsigned``'.  We
+choose approach #2 above because we don't want to make this the default for all
+``unsigned`` options.
+
+To start out, we declare our new ``FileSizeParser`` class:
+
+.. code-block:: c++
+
+  struct FileSizeParser : public cl::basic_parser<unsigned> {
+    // parse - Return true on error.
+    bool parse(cl::Option &O, const char *ArgName, const std::string &ArgValue,
+               unsigned &Val);
+  };
+
+Our new class inherits from the ``cl::basic_parser`` template class to fill in
+the default, boiler plate code for us.  We give it the data type that we parse
+into, the last argument to the ``parse`` method, so that clients of our custom
+parser know what object type to pass in to the parse method.  (Here we declare
+that we parse into '``unsigned``' variables.)
+
+For most purposes, the only method that must be implemented in a custom parser
+is the ``parse`` method.  The ``parse`` method is called whenever the option is
+invoked, passing in the option itself, the option name, the string to parse, and
+a reference to a return value.  If the string to parse is not well-formed, the
+parser should output an error message and return true.  Otherwise it should
+return false and set '``Val``' to the parsed value.  In our example, we
+implement ``parse`` as:
+
+.. code-block:: c++
+
+  bool FileSizeParser::parse(cl::Option &O, const char *ArgName,
+                             const std::string &Arg, unsigned &Val) {
+    const char *ArgStart = Arg.c_str();
+    char *End;
+
+    // Parse integer part, leaving 'End' pointing to the first non-integer char
+    Val = (unsigned)strtol(ArgStart, &End, 0);
+
+    while (1) {
+      switch (*End++) {
+      case 0: return false;   // No error
+      case 'i':               // Ignore the 'i' in KiB if people use that
+      case 'b': case 'B':     // Ignore B suffix
+        break;
+
+      case 'g': case 'G': Val *= 1024*1024*1024; break;
+      case 'm': case 'M': Val *= 1024*1024;      break;
+      case 'k': case 'K': Val *= 1024;           break;
+
+      default:
+        // Print an error message if unrecognized character!
+        return O.error("'" + Arg + "' value invalid for file size argument!");
+      }
+    }
+  }
+
+This function implements a very simple parser for the kinds of strings we are
+interested in.  Although it has some holes (it allows "``123KKK``" for example),
+it is good enough for this example.  Note that we use the option itself to print
+out the error message (the ``error`` method always returns true) in order to get
+a nice error message (shown below).  Now that we have our parser class, we can
+use it like this:
+
+.. code-block:: c++
+
+  static cl::opt<unsigned, false, FileSizeParser>
+  MFS("max-file-size", cl::desc("Maximum file size to accept"),
+      cl::value_desc("size"));
+
+Which adds this to the output of our program:
+
+::
+
+  OPTIONS:
+    -help                 - display available options (-help-hidden for more)
+    ...
+   -max-file-size=<size> - Maximum file size to accept
+
+And we can test that our parse works correctly now (the test program just prints
+out the max-file-size argument value):
+
+::
+
+  $ ./test
+  MFS: 0
+  $ ./test -max-file-size=123MB
+  MFS: 128974848
+  $ ./test -max-file-size=3G
+  MFS: 3221225472
+  $ ./test -max-file-size=dog
+  -max-file-size option: 'dog' value invalid for file size argument!
+
+It looks like it works.  The error message that we get is nice and helpful, and
+we seem to accept reasonable file sizes.  This wraps up the "custom parser"
+tutorial.
+
+Exploiting external storage
+---------------------------
+
+Several of the LLVM libraries define static ``cl::opt`` instances that will
+automatically be included in any program that links with that library.  This is
+a feature. However, sometimes it is necessary to know the value of the command
+line option outside of the library. In these cases the library does or should
+provide an external storage location that is accessible to users of the
+library. Examples of this include the ``llvm::DebugFlag`` exported by the
+``lib/Support/Debug.cpp`` file and the ``llvm::TimePassesIsEnabled`` flag
+exported by the ``lib/VMCore/PassManager.cpp`` file.
+
+.. todo::
+
+  TODO: complete this section
+
+.. _dynamically loaded options:
+
+Dynamically adding command line options
+
+.. todo::
+
+  TODO: fill in this section

Added: www-releases/trunk/3.2/docs/CompilerWriterInfo.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/CompilerWriterInfo.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/CompilerWriterInfo.rst (added)
+++ www-releases/trunk/3.2/docs/CompilerWriterInfo.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,118 @@
+.. _compiler_writer_info:
+
+========================================================
+Architecture & Platform Information for Compiler Writers
+========================================================
+
+.. contents::
+   :local:
+
+.. note::
+
+  This document is a work-in-progress.  Additions and clarifications are
+  welcome.
+
+  Compiled by `Misha Brukman <http://misha.brukman.net>`_.
+
+Hardware
+========
+
+ARM
+---
+
+* `ARM documentation <http://www.arm.com/documentation/>`_ (`Processor Cores <http://www.arm.com/documentation/ARMProcessor_Cores/>`_ Cores)
+
+* `ABI <http://www.arm.com/products/DevTools/ABI.html>`_
+
+Itanium (ia64)
+--------------
+
+* `Itanium documentation <http://developer.intel.com/design/itanium2/documentation.htm>`_
+
+MIPS
+----
+
+* `MIPS Processor Architecture <http://mips.com/content/Documentation/MIPSDocumentation/ProcessorArchitecture/doclibrary>`_
+
+PowerPC
+-------
+
+IBM - Official manuals and docs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* `PowerPC Architecture Book <http://www-106.ibm.com/developerworks/eserver/articles/archguide.html>`_
+
+  * Book I: `PowerPC User Instruction Set Architecture <http://www-106.ibm.com/developerworks/eserver/pdfs/archpub1.pdf>`_
+
+  * Book II: `PowerPC Virtual Environment Architecture <http://www-106.ibm.com/developerworks/eserver/pdfs/archpub2.pdf>`_
+
+  * Book III: `PowerPC Operating Environment Architecture <http://www-106.ibm.com/developerworks/eserver/pdfs/archpub3.pdf>`_
+
+* `PowerPC Compiler Writer's Guide <http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996007558C6>`_
+
+* `PowerPC Processor Manuals <http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC>`_
+
+* `Intro to PowerPC Architecture <http://www-106.ibm.com/developerworks/linux/library/l-powarch/>`_
+
+* `IBM AIX/5L for POWER Assembly Reference <http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/alangreftfrm.htm>`_
+
+Other documents, collections, notes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* `PowerPC ABI documents <http://penguinppc.org/dev/#library>`_
+* `PowerPC64 alignment of long doubles (from GCC) <http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00997.html>`_
+* `Long branch stubs for powerpc64-linux (from binutils) <http://sources.redhat.com/ml/binutils/2002-04/msg00573.html>`_
+
+SPARC
+-----
+
+* `SPARC resources <http://www.sparc.org/resource.htm>`_
+* `SPARC standards <http://www.sparc.org/standards.html>`_
+
+X86
+---
+
+AMD - Official manuals and docs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* `AMD processor manuals <http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.html>`_
+* `X86-64 ABI <http://www.x86-64.org/documentation>`_
+
+Intel - Official manuals and docs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* `IA-32 manuals <http://developer.intel.com/design/pentium4/manuals/index_new.htm>`_
+* `Intel Itanium documentation <http://www.intel.com/design/itanium/documentation.htm?iid=ipp_srvr_proc_itanium2+techdocs>`_
+
+Other x86-specific information
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* `Calling conventions for different C++ compilers and operating systems  <http://www.agner.org/assem/calling_conventions.pdf>`_
+
+Other relevant lists
+--------------------
+
+* `GCC reading list <http://gcc.gnu.org/readings.html>`_
+
+ABI
+===
+
+Linux
+-----
+
+* `PowerPC 64-bit ELF ABI Supplement <http://www.linuxbase.org/spec/ELF/ppc64/>`_
+
+OS X
+----
+
+* `Mach-O Runtime Architecture <http://developer.apple.com/documentation/Darwin/RuntimeArchitecture-date.html>`_
+* `Notes on Mach-O ABI <http://www.unsanity.org/archives/000044.php>`_
+
+Miscellaneous Resources
+=======================
+
+* `Executable File Format library <http://www.nondot.org/sabre/os/articles/ExecutableFileFormats/>`_
+
+* `GCC prefetch project <http://gcc.gnu.org/projects/prefetch.html>`_ page has a
+  good survey of the prefetching capabilities of a variety of modern
+  processors.

Added: www-releases/trunk/3.2/docs/DebuggingJITedCode.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/DebuggingJITedCode.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/DebuggingJITedCode.rst (added)
+++ www-releases/trunk/3.2/docs/DebuggingJITedCode.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,147 @@
+.. _debugging-jited-code:
+
+==============================
+Debugging JIT-ed Code With GDB
+==============================
+
+.. sectionauthor:: Reid Kleckner and Eli Bendersky
+
+Background
+==========
+
+Without special runtime support, debugging dynamically generated code with
+GDB (as well as most debuggers) can be quite painful.  Debuggers generally
+read debug information from the object file of the code, but for JITed
+code, there is no such file to look for.
+
+In order to communicate the necessary debug info to GDB, an interface for
+registering JITed code with debuggers has been designed and implemented for
+GDB and LLVM MCJIT.  At a high level, whenever MCJIT generates new machine code,
+it does so in an in-memory object file that contains the debug information in
+DWARF format.  MCJIT then adds this in-memory object file to a global list of
+dynamically generated object files and calls a special function
+(``__jit_debug_register_code``) marked noinline that GDB knows about.  When
+GDB attaches to a process, it puts a breakpoint in this function and loads all
+of the object files in the global list.  When MCJIT calls the registration
+function, GDB catches the breakpoint signal, loads the new object file from
+the inferior's memory, and resumes the execution.  In this way, GDB can get the
+necessary debug information.
+
+GDB Version
+===========
+
+In order to debug code JIT-ed by LLVM, you need GDB 7.0 or newer, which is
+available on most modern distributions of Linux.  The version of GDB that
+Apple ships with Xcode has been frozen at 6.3 for a while.  LLDB may be a
+better option for debugging JIT-ed code on Mac OS X.
+
+
+Debugging MCJIT-ed code
+=======================
+
+The emerging MCJIT component of LLVM allows full debugging of JIT-ed code with
+GDB.  This is due to MCJIT's ability to use the MC emitter to provide full
+DWARF debugging information to GDB.
+
+Note that lli has to be passed the ``-use-mcjit`` flag to JIT the code with
+MCJIT instead of the old JIT.
+
+Example
+-------
+
+Consider the following C code (with line numbers added to make the example
+easier to follow):
+
+..
+   FIXME:
+   Sphinx has the ability to automatically number these lines by adding
+   :linenos: on the line immediately following the `.. code-block:: c`, but
+   it looks like garbage; the line numbers don't even line up with the
+   lines. Is this a Sphinx bug, or is it a CSS problem?
+
+.. code-block:: c
+
+   1   int compute_factorial(int n)
+   2   {
+   3       if (n <= 1)
+   4           return 1;
+   5
+   6       int f = n;
+   7       while (--n > 1)
+   8           f *= n;
+   9       return f;
+   10  }
+   11
+   12
+   13  int main(int argc, char** argv)
+   14  {
+   15      if (argc < 2)
+   16          return -1;
+   17      char firstletter = argv[1][0];
+   18      int result = compute_factorial(firstletter - '0');
+   19
+   20      // Returned result is clipped at 255...
+   21      return result;
+   22  }
+
+Here is a sample command line session that shows how to build and run this
+code via ``lli`` inside GDB:
+
+.. code-block:: bash
+
+   $ $BINPATH/clang -cc1 -O0 -g -emit-llvm showdebug.c
+   $ gdb --quiet --args $BINPATH/lli -use-mcjit showdebug.ll 5
+   Reading symbols from $BINPATH/lli...done.
+   (gdb) b showdebug.c:6
+   No source file named showdebug.c.
+   Make breakpoint pending on future shared library load? (y or [n]) y
+   Breakpoint 1 (showdebug.c:6) pending.
+   (gdb) r
+   Starting program: $BINPATH/lli -use-mcjit showdebug.ll 5
+   [Thread debugging using libthread_db enabled]
+
+   Breakpoint 1, compute_factorial (n=5) at showdebug.c:6
+   6	    int f = n;
+   (gdb) p n
+   $1 = 5
+   (gdb) p f
+   $2 = 0
+   (gdb) n
+   7	    while (--n > 1)
+   (gdb) p f
+   $3 = 5
+   (gdb) b showdebug.c:9
+   Breakpoint 2 at 0x7ffff7ed404c: file showdebug.c, line 9.
+   (gdb) c
+   Continuing.
+
+   Breakpoint 2, compute_factorial (n=1) at showdebug.c:9
+   9	    return f;
+   (gdb) p f
+   $4 = 120
+   (gdb) bt
+   #0  compute_factorial (n=1) at showdebug.c:9
+   #1  0x00007ffff7ed40a9 in main (argc=2, argv=0x16677e0) at showdebug.c:18
+   #2  0x3500000001652748 in ?? ()
+   #3  0x00000000016677e0 in ?? ()
+   #4  0x0000000000000002 in ?? ()
+   #5  0x0000000000d953b3 in llvm::MCJIT::runFunction (this=0x16151f0, F=0x1603020, ArgValues=...) at /home/ebenders_test/llvm_svn_rw/lib/ExecutionEngine/MCJIT/MCJIT.cpp:161
+   #6  0x0000000000dc8872 in llvm::ExecutionEngine::runFunctionAsMain (this=0x16151f0, Fn=0x1603020, argv=..., envp=0x7fffffffe040)
+       at /home/ebenders_test/llvm_svn_rw/lib/ExecutionEngine/ExecutionEngine.cpp:397
+   #7  0x000000000059c583 in main (argc=4, argv=0x7fffffffe018, envp=0x7fffffffe040) at /home/ebenders_test/llvm_svn_rw/tools/lli/lli.cpp:324
+   (gdb) finish
+   Run till exit from #0  compute_factorial (n=1) at showdebug.c:9
+   0x00007ffff7ed40a9 in main (argc=2, argv=0x16677e0) at showdebug.c:18
+   18	    int result = compute_factorial(firstletter - '0');
+   Value returned is $5 = 120
+   (gdb) p result
+   $6 = 23406408
+   (gdb) n
+   21	    return result;
+   (gdb) p result
+   $7 = 120
+   (gdb) c
+   Continuing.
+
+   Program exited with code 0170.
+   (gdb)

Added: www-releases/trunk/3.2/docs/DeveloperPolicy.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/DeveloperPolicy.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/DeveloperPolicy.rst (added)
+++ www-releases/trunk/3.2/docs/DeveloperPolicy.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,511 @@
+.. _developer_policy:
+
+=====================
+LLVM Developer Policy
+=====================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+This document contains the LLVM Developer Policy which defines the project's
+policy towards developers and their contributions. The intent of this policy is
+to eliminate miscommunication, rework, and confusion that might arise from the
+distributed nature of LLVM's development.  By stating the policy in clear terms,
+we hope each developer can know ahead of time what to expect when making LLVM
+contributions.  This policy covers all llvm.org subprojects, including Clang,
+LLDB, libc++, etc.
+
+This policy is also designed to accomplish the following objectives:
+
+#. Attract both users and developers to the LLVM project.
+
+#. Make life as simple and easy for contributors as possible.
+
+#. Keep the top of Subversion trees as stable as possible.
+
+#. Establish awareness of the project's `copyright, license, and patent
+   policies`_ with contributors to the project.
+
+This policy is aimed at frequent contributors to LLVM. People interested in
+contributing one-off patches can do so in an informal way by sending them to the
+`llvm-commits mailing list
+<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_ and engaging another
+developer to see it through the process.
+
+Developer Policies
+==================
+
+This section contains policies that pertain to frequent LLVM developers.  We
+always welcome `one-off patches`_ from people who do not routinely contribute to
+LLVM, but we expect more from frequent contributors to keep the system as
+efficient as possible for everyone.  Frequent LLVM contributors are expected to
+meet the following requirements in order for LLVM to maintain a high standard of
+quality.
+
+Stay Informed
+-------------
+
+Developers should stay informed by reading at least the "dev" mailing list for
+the projects you are interested in, such as `llvmdev
+<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ for LLVM, `cfe-dev
+<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>`_ for Clang, or `lldb-dev
+<http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>`_ for LLDB.  If you are
+doing anything more than just casual work on LLVM, it is suggested that you also
+subscribe to the "commits" mailing list for the subproject you're interested in,
+such as `llvm-commits
+<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_, `cfe-commits
+<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>`_, or `lldb-commits
+<http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits>`_.  Reading the
+"commits" list and paying attention to changes being made by others is a good
+way to see what other people are interested in and watching the flow of the
+project as a whole.
+
+We recommend that active developers register an email account with `LLVM
+Bugzilla <http://llvm.org/bugs/>`_ and preferably subscribe to the `llvm-bugs
+<http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs>`_ email list to keep track
+of bugs and enhancements occurring in LLVM.  We really appreciate people who are
+proactive at catching incoming bugs in their components and dealing with them
+promptly.
+
+.. _patch:
+.. _one-off patches:
+
+Making a Patch
+--------------
+
+When making a patch for review, the goal is to make it as easy for the reviewer
+to read it as possible.  As such, we recommend that you:
+
+#. Make your patch against the Subversion trunk, not a branch, and not an old
+   version of LLVM.  This makes it easy to apply the patch.  For information on
+   how to check out SVN trunk, please see the `Getting Started
+   Guide <GettingStarted.html#checkout>`_.
+
+#. Similarly, patches should be submitted soon after they are generated.  Old
+   patches may not apply correctly if the underlying code changes between the
+   time the patch was created and the time it is applied.
+
+#. Patches should be made with ``svn diff``, or similar. If you use a
+   different tool, make sure it uses the ``diff -u`` format and that it
+   doesn't contain clutter which makes it hard to read.
+
+#. If you are modifying generated files, such as the top-level ``configure``
+   script, please separate out those changes into a separate patch from the rest
+   of your changes.
+
+When sending a patch to a mailing list, it is a good idea to send it as an
+*attachment* to the message, not embedded into the text of the message.  This
+ensures that your mailer will not mangle the patch when it sends it (e.g. by
+making whitespace changes or by wrapping lines).
+
+*For Thunderbird users:* Before submitting a patch, please open *Preferences >
+Advanced > General > Config Editor*, find the key
+``mail.content_disposition_type``, and set its value to ``1``. Without this
+setting, Thunderbird sends your attachment using ``Content-Disposition: inline``
+rather than ``Content-Disposition: attachment``. Apple Mail gamely displays such
+a file inline, making it difficult to work with for reviewers using that
+program.
+
+.. _code review:
+
+Code Reviews
+------------
+
+LLVM has a code review policy. Code review is one way to increase the quality of
+software. We generally follow these policies:
+
+#. All developers are required to have significant changes reviewed before they
+   are committed to the repository.
+
+#. Code reviews are conducted by email, usually on the llvm-commits list.
+
+#. Code can be reviewed either before it is committed or after.  We expect major
+   changes to be reviewed before being committed, but smaller changes (or
+   changes where the developer owns the component) can be reviewed after commit.
+
+#. The developer responsible for a code change is also responsible for making
+   all necessary review-related changes.
+
+#. Code review can be an iterative process, which continues until the patch is
+   ready to be committed.
+
+Developers should participate in code reviews as both reviewers and
+reviewees. If someone is kind enough to review your code, you should return the
+favor for someone else.  Note that anyone is welcome to review and give feedback
+on a patch, but only people with Subversion write access can approve it.
+
+There is a web based code review tool that can optionally be used
+for code reviews. See :doc:`Phabricator`.
+
+Code Owners
+-----------
+
+The LLVM Project relies on two features of its process to maintain rapid
+development in addition to the high quality of its source base: the combination
+of code review plus post-commit review for trusted maintainers.  Having both is
+a great way for the project to take advantage of the fact that most people do
+the right thing most of the time, and only commit patches without pre-commit
+review when they are confident they are right.
+
+The trick to this is that the project has to guarantee that all patches that are
+committed are reviewed after they go in: you don't want everyone to assume
+someone else will review it, allowing the patch to go unreviewed.  To solve this
+problem, we have a notion of an 'owner' for a piece of the code.  The sole
+responsibility of a code owner is to ensure that a commit to their area of the
+code is appropriately reviewed, either by themself or by someone else.  The list
+of current code owners can be found in the file
+`CODE_OWNERS.TXT <http://llvm.org/viewvc/llvm-project/llvm/trunk/CODE_OWNERS.TXT?view=markup>`_
+in the root of the LLVM source tree.
+
+Note that code ownership is completely different than reviewers: anyone can
+review a piece of code, and we welcome code review from anyone who is
+interested.  Code owners are the "last line of defense" to guarantee that all
+patches that are committed are actually reviewed.
+
+Being a code owner is a somewhat unglamorous position, but it is incredibly
+important for the ongoing success of the project.  Because people get busy,
+interests change, and unexpected things happen, code ownership is purely opt-in,
+and anyone can choose to resign their "title" at any time. For now, we do not
+have an official policy on how one gets elected to be a code owner.
+
+.. _include a testcase:
+
+Test Cases
+----------
+
+Developers are required to create test cases for any bugs fixed and any new
+features added.  Some tips for getting your testcase approved:
+
+* All feature and regression test cases are added to the ``llvm/test``
+  directory. The appropriate sub-directory should be selected (see the `Testing
+  Guide <TestingGuide.html>`_ for details).
+
+* Test cases should be written in `LLVM assembly language <LangRef.html>`_
+  unless the feature or regression being tested requires another language
+  (e.g. the bug being fixed or feature being implemented is in the llvm-gcc C++
+  front-end, in which case it must be written in C++).
+
+* Test cases, especially for regressions, should be reduced as much as possible,
+  by `bugpoint <Bugpoint.html>`_ or manually. It is unacceptable to place an
+  entire failing program into ``llvm/test`` as this creates a *time-to-test*
+  burden on all developers. Please keep them short.
+
+Note that llvm/test and clang/test are designed for regression and small feature
+tests only. More extensive test cases (e.g., entire applications, benchmarks,
+etc) should be added to the ``llvm-test`` test suite.  The llvm-test suite is
+for coverage (correctness, performance, etc) testing, not feature or regression
+testing.
+
+Quality
+-------
+
+The minimum quality standards that any change must satisfy before being
+committed to the main development branch are:
+
+#. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
+
+#. Code must compile cleanly (no errors, no warnings) on at least one platform.
+
+#. Bug fixes and new features should `include a testcase`_ so we know if the
+   fix/feature ever regresses in the future.
+
+#. Code must pass the ``llvm/test`` test suite.
+
+#. The code must not cause regressions on a reasonable subset of llvm-test,
+   where "reasonable" depends on the contributor's judgement and the scope of
+   the change (more invasive changes require more testing). A reasonable subset
+   might be something like "``llvm-test/MultiSource/Benchmarks``".
+
+Additionally, the committer is responsible for addressing any problems found in
+the future that the change is responsible for.  For example:
+
+* The code should compile cleanly on all supported platforms.
+
+* The changes should not cause any correctness regressions in the ``llvm-test``
+  suite and must not cause any major performance regressions.
+
+* The change set should not cause performance or correctness regressions for the
+  LLVM tools.
+
+* The changes should not cause performance or correctness regressions in code
+  compiled by LLVM on all applicable targets.
+
+* You are expected to address any `Bugzilla bugs <http://llvm.org/bugs/>`_ that
+  result from your change.
+
+We prefer for this to be handled before submission but understand that it isn't
+possible to test all of this for every submission.  Our build bots and nightly
+testing infrastructure normally finds these problems.  A good rule of thumb is
+to check the nightly testers for regressions the day after your change.  Build
+bots will directly email you if a group of commits that included yours caused a
+failure.  You are expected to check the build bot messages to see if they are
+your fault and, if so, fix the breakage.
+
+Commits that violate these quality standards (e.g. are very broken) may be
+reverted. This is necessary when the change blocks other developers from making
+progress. The developer is welcome to re-commit the change after the problem has
+been fixed.
+
+Obtaining Commit Access
+-----------------------
+
+We grant commit access to contributors with a track record of submitting high
+quality patches.  If you would like commit access, please send an email to
+`Chris <mailto:sabre at nondot.org>`_ with the following information:
+
+#. The user name you want to commit with, e.g. "hacker".
+
+#. The full name and email address you want message to llvm-commits to come
+   from, e.g. "J. Random Hacker <hacker at yoyodyne.com>".
+
+#. A "password hash" of the password you want to use, e.g. "``2ACR96qjUqsyM``".
+   Note that you don't ever tell us what your password is, you just give it to
+   us in an encrypted form.  To get this, run "``htpasswd``" (a utility that
+   comes with apache) in crypt mode (often enabled with "``-d``"), or find a web
+   page that will do it for you.
+
+Once you've been granted commit access, you should be able to check out an LLVM
+tree with an SVN URL of "https://username@llvm.org/..." instead of the normal
+anonymous URL of "http://llvm.org/...".  The first time you commit you'll have
+to type in your password.  Note that you may get a warning from SVN about an
+untrusted key, you can ignore this.  To verify that your commit access works,
+please do a test commit (e.g. change a comment or add a blank line).  Your first
+commit to a repository may require the autogenerated email to be approved by a
+mailing list.  This is normal, and will be done when the mailing list owner has
+time.
+
+If you have recently been granted commit access, these policies apply:
+
+#. You are granted *commit-after-approval* to all parts of LLVM.  To get
+   approval, submit a `patch`_ to `llvm-commits
+   <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_. When approved
+   you may commit it yourself.
+
+#. You are allowed to commit patches without approval which you think are
+   obvious. This is clearly a subjective decision --- we simply expect you to
+   use good judgement.  Examples include: fixing build breakage, reverting
+   obviously broken patches, documentation/comment changes, any other minor
+   changes.
+
+#. You are allowed to commit patches without approval to those portions of LLVM
+   that you have contributed or maintain (i.e., have been assigned
+   responsibility for), with the proviso that such commits must not break the
+   build.  This is a "trust but verify" policy and commits of this nature are
+   reviewed after they are committed.
+
+#. Multiple violations of these policies or a single egregious violation may
+   cause commit access to be revoked.
+
+In any case, your changes are still subject to `code review`_ (either before or
+after they are committed, depending on the nature of the change).  You are
+encouraged to review other peoples' patches as well, but you aren't required
+to.
+
+.. _discuss the change/gather consensus:
+
+Making a Major Change
+---------------------
+
+When a developer begins a major new project with the aim of contributing it back
+to LLVM, s/he should inform the community with an email to the `llvmdev
+<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ email list, to the extent
+possible. The reason for this is to:
+
+#. keep the community informed about future changes to LLVM,
+
+#. avoid duplication of effort by preventing multiple parties working on the
+   same thing and not knowing about it, and
+
+#. ensure that any technical issues around the proposed work are discussed and
+   resolved before any significant work is done.
+
+The design of LLVM is carefully controlled to ensure that all the pieces fit
+together well and are as consistent as possible. If you plan to make a major
+change to the way LLVM works or want to add a major new extension, it is a good
+idea to get consensus with the development community before you start working on
+it.
+
+Once the design of the new feature is finalized, the work itself should be done
+as a series of `incremental changes`_, not as a long-term development branch.
+
+.. _incremental changes:
+
+Incremental Development
+-----------------------
+
+In the LLVM project, we do all significant changes as a series of incremental
+patches.  We have a strong dislike for huge changes or long-term development
+branches.  Long-term development branches have a number of drawbacks:
+
+#. Branches must have mainline merged into them periodically.  If the branch
+   development and mainline development occur in the same pieces of code,
+   resolving merge conflicts can take a lot of time.
+
+#. Other people in the community tend to ignore work on branches.
+
+#. Huge changes (produced when a branch is merged back onto mainline) are
+   extremely difficult to `code review`_.
+
+#. Branches are not routinely tested by our nightly tester infrastructure.
+
+#. Changes developed as monolithic large changes often don't work until the
+   entire set of changes is done.  Breaking it down into a set of smaller
+   changes increases the odds that any of the work will be committed to the main
+   repository.
+
+To address these problems, LLVM uses an incremental development style and we
+require contributors to follow this practice when making a large/invasive
+change.  Some tips:
+
+* Large/invasive changes usually have a number of secondary changes that are
+  required before the big change can be made (e.g. API cleanup, etc).  These
+  sorts of changes can often be done before the major change is done,
+  independently of that work.
+
+* The remaining inter-related work should be decomposed into unrelated sets of
+  changes if possible.  Once this is done, define the first increment and get
+  consensus on what the end goal of the change is.
+
+* Each change in the set can be stand alone (e.g. to fix a bug), or part of a
+  planned series of changes that works towards the development goal.
+
+* Each change should be kept as small as possible. This simplifies your work
+  (into a logical progression), simplifies code review and reduces the chance
+  that you will get negative feedback on the change. Small increments also
+  facilitate the maintenance of a high quality code base.
+
+* Often, an independent precursor to a big change is to add a new API and slowly
+  migrate clients to use the new API.  Each change to use the new API is often
+  "obvious" and can be committed without review.  Once the new API is in place
+  and used, it is much easier to replace the underlying implementation of the
+  API.  This implementation change is logically separate from the API
+  change.
+
+If you are interested in making a large change, and this scares you, please make
+sure to first `discuss the change/gather consensus`_ then ask about the best way
+to go about making the change.
+
+Attribution of Changes
+----------------------
+
+We believe in correct attribution of contributions to their contributors.
+However, we do not want the source code to be littered with random attributions
+"this code written by J. Random Hacker" (this is noisy and distracting).  In
+practice, the revision control system keeps a perfect history of who changed
+what, and the CREDITS.txt file describes higher-level contributions.  If you
+commit a patch for someone else, please say "patch contributed by J. Random
+Hacker!" in the commit message.
+
+Overall, please do not add contributor names to the source code.
+
+.. _copyright, license, and patent policies:
+
+Copyright, License, and Patents
+===============================
+
+.. note::
+
+   This section deals with legal matters but does not provide legal advice.  We
+   are not lawyers --- please seek legal counsel from an attorney.
+
+This section addresses the issues of copyright, license and patents for the LLVM
+project.  The copyright for the code is held by the individual contributors of
+the code and the terms of its license to LLVM users and developers is the
+`University of Illinois/NCSA Open Source License
+<http://www.opensource.org/licenses/UoI-NCSA.php>`_ (with portions dual licensed
+under the `MIT License <http://www.opensource.org/licenses/mit-license.php>`_,
+see below).  As contributor to the LLVM project, you agree to allow any
+contributions to the project to licensed under these terms.
+
+Copyright
+---------
+
+The LLVM project does not require copyright assignments, which means that the
+copyright for the code in the project is held by its respective contributors who
+have each agreed to release their contributed code under the terms of the `LLVM
+License`_.
+
+An implication of this is that the LLVM license is unlikely to ever change:
+changing it would require tracking down all the contributors to LLVM and getting
+them to agree that a license change is acceptable for their contribution.  Since
+there are no plans to change the license, this is not a cause for concern.
+
+As a contributor to the project, this means that you (or your company) retain
+ownership of the code you contribute, that it cannot be used in a way that
+contradicts the license (which is a liberal BSD-style license), and that the
+license for your contributions won't change without your approval in the
+future.
+
+.. _LLVM License:
+
+License
+-------
+
+We intend to keep LLVM perpetually open source and to use a liberal open source
+license. **As a contributor to the project, you agree that any contributions be
+licensed under the terms of the corresponding subproject.** All of the code in
+LLVM is available under the `University of Illinois/NCSA Open Source License
+<http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to
+this:
+
+* You can freely distribute LLVM.
+* You must retain the copyright notice if you redistribute LLVM.
+* Binaries derived from LLVM must reproduce the copyright notice (e.g. in an
+  included readme file).
+* You can't use our names to promote your LLVM derived products.
+* There's no warranty on LLVM at all.
+
+We believe this fosters the widest adoption of LLVM because it **allows
+commercial products to be derived from LLVM** with few restrictions and without
+a requirement for making any derived works also open source (i.e.  LLVM's
+license is not a "copyleft" license like the GPL). We suggest that you read the
+`License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
+clarification is needed.
+
+In addition to the UIUC license, the runtime library components of LLVM
+(**compiler_rt, libc++, and libclc**) are also licensed under the `MIT License
+<http://www.opensource.org/licenses/mit-license.php>`_, which does not contain
+the binary redistribution clause.  As a user of these runtime libraries, it
+means that you can choose to use the code under either license (and thus don't
+need the binary redistribution clause), and as a contributor to the code that
+you agree that any contributions to these libraries be licensed under both
+licenses.  We feel that this is important for runtime libraries, because they
+are implicitly linked into applications and therefore should not subject those
+applications to the binary redistribution clause. This also means that it is ok
+to move code from (e.g.)  libc++ to the LLVM core without concern, but that code
+cannot be moved from the LLVM core to libc++ without the copyright owner's
+permission.
+
+Note that the LLVM Project does distribute llvm-gcc and dragonegg, **which are
+GPL.** This means that anything "linked" into llvm-gcc must itself be compatible
+with the GPL, and must be releasable under the terms of the GPL.  This implies
+that **any code linked into llvm-gcc and distributed to others may be subject to
+the viral aspects of the GPL** (for example, a proprietary code generator linked
+into llvm-gcc must be made available under the GPL).  This is not a problem for
+code already distributed under a more liberal license (like the UIUC license),
+and GPL-containing subprojects are kept in separate SVN repositories whose
+LICENSE.txt files specifically indicate that they contain GPL code.
+
+We have no plans to change the license of LLVM.  If you have questions or
+comments about the license, please contact the `LLVM Developer's Mailing
+List <mailto:llvmdev at cs.uiuc.edu>`_.
+
+Patents
+-------
+
+To the best of our knowledge, LLVM does not infringe on any patents (we have
+actually removed code from LLVM in the past that was found to infringe).  Having
+code in LLVM that infringes on patents would violate an important goal of the
+project by making it hard or impossible to reuse the code for arbitrary purposes
+(including commercial use).
+
+When contributing code, we expect contributors to notify us of any potential for
+patent-related trouble with their changes (including from third parties).  If
+you or your employer own the rights to a patent and would like to contribute
+code to LLVM that relies on it, we require that the copyright owner sign an
+agreement that allows any other user of LLVM to freely use your patent.  Please
+contact the `oversight group <mailto:llvm-oversight at cs.uiuc.edu>`_ for more
+details.

Added: www-releases/trunk/3.2/docs/ExceptionHandling.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/ExceptionHandling.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/ExceptionHandling.rst (added)
+++ www-releases/trunk/3.2/docs/ExceptionHandling.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,367 @@
+.. _exception_handling:
+
+==========================
+Exception Handling in LLVM
+==========================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+This document is the central repository for all information pertaining to
+exception handling in LLVM.  It describes the format that LLVM exception
+handling information takes, which is useful for those interested in creating
+front-ends or dealing directly with the information.  Further, this document
+provides specific examples of what exception handling information is used for in
+C and C++.
+
+Itanium ABI Zero-cost Exception Handling
+----------------------------------------
+
+Exception handling for most programming languages is designed to recover from
+conditions that rarely occur during general use of an application.  To that end,
+exception handling should not interfere with the main flow of an application's
+algorithm by performing checkpointing tasks, such as saving the current pc or
+register state.
+
+The Itanium ABI Exception Handling Specification defines a methodology for
+providing outlying data in the form of exception tables without inlining
+speculative exception handling code in the flow of an application's main
+algorithm.  Thus, the specification is said to add "zero-cost" to the normal
+execution of an application.
+
+A more complete description of the Itanium ABI exception handling runtime
+support of can be found at `Itanium C++ ABI: Exception Handling
+<http://www.codesourcery.com/cxx-abi/abi-eh.html>`_. A description of the
+exception frame format can be found at `Exception Frames
+<http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html>`_,
+with details of the DWARF 4 specification at `DWARF 4 Standard
+<http://dwarfstd.org/Dwarf4Std.php>`_.  A description for the C++ exception
+table formats can be found at `Exception Handling Tables
+<http://www.codesourcery.com/cxx-abi/exceptions.pdf>`_.
+
+Setjmp/Longjmp Exception Handling
+---------------------------------
+
+Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics
+`llvm.eh.sjlj.setjmp`_ and `llvm.eh.sjlj.longjmp`_ to handle control flow for
+exception handling.
+
+For each function which does exception processing --- be it ``try``/``catch``
+blocks or cleanups --- that function registers itself on a global frame
+list. When exceptions are unwinding, the runtime uses this list to identify
+which functions need processing.
+
+Landing pad selection is encoded in the call site entry of the function
+context. The runtime returns to the function via `llvm.eh.sjlj.longjmp`_, where
+a switch table transfers control to the appropriate landing pad based on the
+index stored in the function context.
+
+In contrast to DWARF exception handling, which encodes exception regions and
+frame information in out-of-line tables, SJLJ exception handling builds and
+removes the unwind frame context at runtime. This results in faster exception
+handling at the expense of slower execution when no exceptions are thrown. As
+exceptions are, by their nature, intended for uncommon code paths, DWARF
+exception handling is generally preferred to SJLJ.
+
+Overview
+--------
+
+When an exception is thrown in LLVM code, the runtime does its best to find a
+handler suited to processing the circumstance.
+
+The runtime first attempts to find an *exception frame* corresponding to the
+function where the exception was thrown.  If the programming language supports
+exception handling (e.g. C++), the exception frame contains a reference to an
+exception table describing how to process the exception.  If the language does
+not support exception handling (e.g. C), or if the exception needs to be
+forwarded to a prior activation, the exception frame contains information about
+how to unwind the current activation and restore the state of the prior
+activation.  This process is repeated until the exception is handled. If the
+exception is not handled and no activations remain, then the application is
+terminated with an appropriate error message.
+
+Because different programming languages have different behaviors when handling
+exceptions, the exception handling ABI provides a mechanism for
+supplying *personalities*. An exception handling personality is defined by
+way of a *personality function* (e.g. ``__gxx_personality_v0`` in C++),
+which receives the context of the exception, an *exception structure*
+containing the exception object type and value, and a reference to the exception
+table for the current function.  The personality function for the current
+compile unit is specified in a *common exception frame*.
+
+The organization of an exception table is language dependent. For C++, an
+exception table is organized as a series of code ranges defining what to do if
+an exception occurs in that range. Typically, the information associated with a
+range defines which types of exception objects (using C++ *type info*) that are
+handled in that range, and an associated action that should take place. Actions
+typically pass control to a *landing pad*.
+
+A landing pad corresponds roughly to the code found in the ``catch`` portion of
+a ``try``/``catch`` sequence. When execution resumes at a landing pad, it
+receives an *exception structure* and a *selector value* corresponding to the
+*type* of exception thrown. The selector is then used to determine which *catch*
+should actually process the exception.
+
+LLVM Code Generation
+====================
+
+From a C++ developer's perspective, exceptions are defined in terms of the
+``throw`` and ``try``/``catch`` statements. In this section we will describe the
+implementation of LLVM exception handling in terms of C++ examples.
+
+Throw
+-----
+
+Languages that support exception handling typically provide a ``throw``
+operation to initiate the exception process. Internally, a ``throw`` operation
+breaks down into two steps.
+
+#. A request is made to allocate exception space for an exception structure.
+   This structure needs to survive beyond the current activation. This structure
+   will contain the type and value of the object being thrown.
+
+#. A call is made to the runtime to raise the exception, passing the exception
+   structure as an argument.
+
+In C++, the allocation of the exception structure is done by the
+``__cxa_allocate_exception`` runtime function. The exception raising is handled
+by ``__cxa_throw``. The type of the exception is represented using a C++ RTTI
+structure.
+
+Try/Catch
+---------
+
+A call within the scope of a *try* statement can potentially raise an
+exception. In those circumstances, the LLVM C++ front-end replaces the call with
+an ``invoke`` instruction. Unlike a call, the ``invoke`` has two potential
+continuation points:
+
+#. where to continue when the call succeeds as per normal, and
+
+#. where to continue if the call raises an exception, either by a throw or the
+   unwinding of a throw
+
+The term used to define a the place where an ``invoke`` continues after an
+exception is called a *landing pad*. LLVM landing pads are conceptually
+alternative function entry points where an exception structure reference and a
+type info index are passed in as arguments. The landing pad saves the exception
+structure reference and then proceeds to select the catch block that corresponds
+to the type info of the exception object.
+
+The LLVM `landingpad instruction <LangRef.html#i_landingpad>`_ is used to convey
+information about the landing pad to the back end. For C++, the ``landingpad``
+instruction returns a pointer and integer pair corresponding to the pointer to
+the *exception structure* and the *selector value* respectively.
+
+The ``landingpad`` instruction takes a reference to the personality function to
+be used for this ``try``/``catch`` sequence. The remainder of the instruction is
+a list of *cleanup*, *catch*, and *filter* clauses. The exception is tested
+against the clauses sequentially from first to last. The selector value is a
+positive number if the exception matched a type info, a negative number if it
+matched a filter, and zero if it matched a cleanup. If nothing is matched, the
+behavior of the program is `undefined`_. If a type info matched, then the
+selector value is the index of the type info in the exception table, which can
+be obtained using the `llvm.eh.typeid.for`_ intrinsic.
+
+Once the landing pad has the type info selector, the code branches to the code
+for the first catch. The catch then checks the value of the type info selector
+against the index of type info for that catch.  Since the type info index is not
+known until all the type infos have been gathered in the backend, the catch code
+must call the `llvm.eh.typeid.for`_ intrinsic to determine the index for a given
+type info. If the catch fails to match the selector then control is passed on to
+the next catch.
+
+Finally, the entry and exit of catch code is bracketed with calls to
+``__cxa_begin_catch`` and ``__cxa_end_catch``.
+
+* ``__cxa_begin_catch`` takes an exception structure reference as an argument
+  and returns the value of the exception object.
+
+* ``__cxa_end_catch`` takes no arguments. This function:
+
+  #. Locates the most recently caught exception and decrements its handler
+     count,
+
+  #. Removes the exception from the *caught* stack if the handler count goes to
+     zero, and
+
+  #. Destroys the exception if the handler count goes to zero and the exception
+     was not re-thrown by throw.
+
+  .. note::
+
+    a rethrow from within the catch may replace this call with a
+    ``__cxa_rethrow``.
+
+Cleanups
+--------
+
+A cleanup is extra code which needs to be run as part of unwinding a scope.  C++
+destructors are a typical example, but other languages and language extensions
+provide a variety of different kinds of cleanups. In general, a landing pad may
+need to run arbitrary amounts of cleanup code before actually entering a catch
+block. To indicate the presence of cleanups, a `landingpad
+instruction <LangRef.html#i_landingpad>`_ should have a *cleanup*
+clause. Otherwise, the unwinder will not stop at the landing pad if there are no
+catches or filters that require it to.
+
+.. note::
+
+  Do not allow a new exception to propagate out of the execution of a
+  cleanup. This can corrupt the internal state of the unwinder.  Different
+  languages describe different high-level semantics for these situations: for
+  example, C++ requires that the process be terminated, whereas Ada cancels both
+  exceptions and throws a third.
+
+When all cleanups are finished, if the exception is not handled by the current
+function, resume unwinding by calling the `resume
+instruction <LangRef.html#i_resume>`_, passing in the result of the
+``landingpad`` instruction for the original landing pad.
+
+Throw Filters
+-------------
+
+C++ allows the specification of which exception types may be thrown from a
+function. To represent this, a top level landing pad may exist to filter out
+invalid types. To express this in LLVM code the `landingpad
+instruction <LangRef.html#i_landingpad>`_ will have a filter clause. The clause
+consists of an array of type infos.  ``landingpad`` will return a negative value
+if the exception does not match any of the type infos. If no match is found then
+a call to ``__cxa_call_unexpected`` should be made, otherwise
+``_Unwind_Resume``.  Each of these functions requires a reference to the
+exception structure.  Note that the most general form of a ``landingpad``
+instruction can have any number of catch, cleanup, and filter clauses (though
+having more than one cleanup is pointless). The LLVM C++ front-end can generate
+such ``landingpad`` instructions due to inlining creating nested exception
+handling scopes.
+
+.. _undefined:
+
+Restrictions
+------------
+
+The unwinder delegates the decision of whether to stop in a call frame to that
+call frame's language-specific personality function. Not all unwinders guarantee
+that they will stop to perform cleanups. For example, the GNU C++ unwinder
+doesn't do so unless the exception is actually caught somewhere further up the
+stack.
+
+In order for inlining to behave correctly, landing pads must be prepared to
+handle selector results that they did not originally advertise. Suppose that a
+function catches exceptions of type ``A``, and it's inlined into a function that
+catches exceptions of type ``B``. The inliner will update the ``landingpad``
+instruction for the inlined landing pad to include the fact that ``B`` is also
+caught. If that landing pad assumes that it will only be entered to catch an
+``A``, it's in for a rude awakening.  Consequently, landing pads must test for
+the selector results they understand and then resume exception propagation with
+the `resume instruction <LangRef.html#i_resume>`_ if none of the conditions
+match.
+
+Exception Handling Intrinsics
+=============================
+
+In addition to the ``landingpad`` and ``resume`` instructions, LLVM uses several
+intrinsic functions (name prefixed with ``llvm.eh``) to provide exception
+handling information at various points in generated code.
+
+.. _llvm.eh.typeid.for:
+
+llvm.eh.typeid.for
+------------------
+
+.. code-block:: llvm
+
+  i32 @llvm.eh.typeid.for(i8* %type_info)
+
+
+This intrinsic returns the type info index in the exception table of the current
+function.  This value can be used to compare against the result of
+``landingpad`` instruction.  The single argument is a reference to a type info.
+
+.. _llvm.eh.sjlj.setjmp:
+
+llvm.eh.sjlj.setjmp
+-------------------
+
+.. code-block:: llvm
+
+  i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
+
+For SJLJ based exception handling, this intrinsic forces register saving for the
+current function and stores the address of the following instruction for use as
+a destination address by `llvm.eh.sjlj.longjmp`_. The buffer format and the
+overall functioning of this intrinsic is compatible with the GCC
+``__builtin_setjmp`` implementation allowing code built with the clang and GCC
+to interoperate.
+
+The single parameter is a pointer to a five word buffer in which the calling
+context is saved. The front end places the frame pointer in the first word, and
+the target implementation of this intrinsic should place the destination address
+for a `llvm.eh.sjlj.longjmp`_ in the second word. The following three words are
+available for use in a target-specific manner.
+
+.. _llvm.eh.sjlj.longjmp:
+
+llvm.eh.sjlj.longjmp
+--------------------
+
+.. code-block:: llvm
+
+  void @llvm.eh.sjlj.longjmp(i8* %setjmp_buf)
+
+For SJLJ based exception handling, the ``llvm.eh.sjlj.longjmp`` intrinsic is
+used to implement ``__builtin_longjmp()``. The single parameter is a pointer to
+a buffer populated by `llvm.eh.sjlj.setjmp`_. The frame pointer and stack
+pointer are restored from the buffer, then control is transferred to the
+destination address.
+
+llvm.eh.sjlj.lsda
+-----------------
+
+.. code-block:: llvm
+
+  i8* @llvm.eh.sjlj.lsda()
+
+For SJLJ based exception handling, the ``llvm.eh.sjlj.lsda`` intrinsic returns
+the address of the Language Specific Data Area (LSDA) for the current
+function. The SJLJ front-end code stores this address in the exception handling
+function context for use by the runtime.
+
+llvm.eh.sjlj.callsite
+---------------------
+
+.. code-block:: llvm
+
+  void @llvm.eh.sjlj.callsite(i32 %call_site_num)
+
+For SJLJ based exception handling, the ``llvm.eh.sjlj.callsite`` intrinsic
+identifies the callsite value associated with the following ``invoke``
+instruction. This is used to ensure that landing pad entries in the LSDA are
+generated in matching order.
+
+Asm Table Formats
+=================
+
+There are two tables that are used by the exception handling runtime to
+determine which actions should be taken when an exception is thrown.
+
+Exception Handling Frame
+------------------------
+
+An exception handling frame ``eh_frame`` is very similar to the unwind frame
+used by DWARF debug info. The frame contains all the information necessary to
+tear down the current frame and restore the state of the prior frame. There is
+an exception handling frame for each function in a compile unit, plus a common
+exception handling frame that defines information common to all functions in the
+unit.
+
+Exception Tables
+----------------
+
+An exception table contains information about what actions to take when an
+exception is thrown in a particular part of a function's code. There is one
+exception table per function, except leaf functions and functions that have
+calls only to non-throwing functions. They do not need an exception table.

Added: www-releases/trunk/3.2/docs/ExtendedIntegerResults.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/ExtendedIntegerResults.txt?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/ExtendedIntegerResults.txt (added)
+++ www-releases/trunk/3.2/docs/ExtendedIntegerResults.txt Fri Dec 21 00:57:24 2012
@@ -0,0 +1,133 @@
+//===----------------------------------------------------------------------===//
+// Representing sign/zero extension of function results
+//===----------------------------------------------------------------------===//
+
+Mar 25, 2009  - Initial Revision
+
+Most ABIs specify that functions which return small integers do so in a
+specific integer GPR.  This is an efficient way to go, but raises the question:
+if the returned value is smaller than the register, what do the high bits hold?
+
+There are three (interesting) possible answers: undefined, zero extended, or
+sign extended.  The number of bits in question depends on the data-type that
+the front-end is referencing (typically i1/i8/i16/i32).
+
+Knowing the answer to this is important for two reasons: 1) we want to be able
+to implement the ABI correctly.  If we need to sign extend the result according
+to the ABI, we really really do need to do this to preserve correctness.  2)
+this information is often useful for optimization purposes, and we want the
+mid-level optimizers to be able to process this (e.g. eliminate redundant
+extensions).
+
+For example, lets pretend that X86 requires the caller to properly extend the
+result of a return (I'm not sure this is the case, but the argument doesn't
+depend on this).  Given this, we should compile this:
+
+int a();
+short b() { return a(); }
+
+into:
+
+_b:
+	subl	$12, %esp
+	call	L_a$stub
+	addl	$12, %esp
+	cwtl
+	ret
+
+An optimization example is that we should be able to eliminate the explicit
+sign extension in this example:
+
+short y();
+int z() {
+  return ((int)y() << 16) >> 16;
+}
+
+_z:
+	subl	$12, %esp
+	call	_y
+	;;  movswl %ax, %eax   -> not needed because eax is already sext'd
+	addl	$12, %esp
+	ret
+
+//===----------------------------------------------------------------------===//
+// What we have right now.
+//===----------------------------------------------------------------------===//
+
+Currently, these sorts of things are modelled by compiling a function to return
+the small type and a signext/zeroext marker is used.  For example, we compile
+Z into:
+
+define i32 @z() nounwind {
+entry:
+	%0 = tail call signext i16 (...)* @y() nounwind
+	%1 = sext i16 %0 to i32
+	ret i32 %1
+}
+
+and b into:
+
+define signext i16 @b() nounwind {
+entry:
+	%0 = tail call i32 (...)* @a() nounwind		; <i32> [#uses=1]
+	%retval12 = trunc i32 %0 to i16		; <i16> [#uses=1]
+	ret i16 %retval12
+}
+
+This has some problems: 1) the actual precise semantics are really poorly
+defined (see PR3779).  2) some targets might want the caller to extend, some
+might want the callee to extend 3) the mid-level optimizer doesn't know the
+size of the GPR, so it doesn't know that %0 is sign extended up to 32-bits 
+here, and even if it did, it could not eliminate the sext. 4) the code
+generator has historically assumed that the result is extended to i32, which is
+a problem on PIC16 (and is also probably wrong on alpha and other 64-bit
+targets).
+
+//===----------------------------------------------------------------------===//
+// The proposal
+//===----------------------------------------------------------------------===//
+
+I suggest that we have the front-end fully lower out the ABI issues here to
+LLVM IR.  This makes it 100% explicit what is going on and means that there is
+no cause for confusion.  For example, the cases above should compile into:
+
+define i32 @z() nounwind {
+entry:
+        %0 = tail call i32 (...)* @y() nounwind
+	%1 = trunc i32 %0 to i16
+        %2 = sext i16 %1 to i32
+        ret i32 %2
+}
+define i32 @b() nounwind {
+entry:
+	%0 = tail call i32 (...)* @a() nounwind
+	%retval12 = trunc i32 %0 to i16
+	%tmp = sext i16 %retval12 to i32
+	ret i32 %tmp
+}
+
+In this model, no functions will return an i1/i8/i16 (and on a x86-64 target
+that extends results to i64, no i32).  This solves the ambiguity issue, allows us 
+to fully describe all possible ABIs, and now allows the optimizers to reason
+about and eliminate these extensions.
+
+The one thing that is missing is the ability for the front-end and optimizer to
+specify/infer the guarantees provided by the ABI to allow other optimizations.
+For example, in the y/z case, since y is known to return a sign extended value,
+the trunc/sext in z should be eliminable.
+
+This can be done by introducing new sext/zext attributes which mean "I know
+that the result of the function is sign extended at least N bits.  Given this,
+and given that it is stuck on the y function, the mid-level optimizer could
+easily eliminate the extensions etc with existing functionality.
+
+The major disadvantage of doing this sort of thing is that it makes the ABI
+lowering stuff even more explicit in the front-end, and that we would like to
+eventually move to having the code generator do more of this work.  However,
+the sad truth of the matter is that this is a) unlikely to happen anytime in
+the near future, and b) this is no worse than we have now with the existing
+attributes.
+
+C compilers fundamentally have to reason about the target in many ways.  
+This is ugly and horrible, but a fact of life.
+

Added: www-releases/trunk/3.2/docs/ExtendingLLVM.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/ExtendingLLVM.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/ExtendingLLVM.rst (added)
+++ www-releases/trunk/3.2/docs/ExtendingLLVM.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,306 @@
+.. _extending_llvm:
+
+============================================================
+Extending LLVM: Adding instructions, intrinsics, types, etc.
+============================================================
+
+Introduction and Warning
+========================
+
+
+During the course of using LLVM, you may wish to customize it for your research
+project or for experimentation. At this point, you may realize that you need to
+add something to LLVM, whether it be a new fundamental type, a new intrinsic
+function, or a whole new instruction.
+
+When you come to this realization, stop and think. Do you really need to extend
+LLVM? Is it a new fundamental capability that LLVM does not support at its
+current incarnation or can it be synthesized from already pre-existing LLVM
+elements? If you are not sure, ask on the `LLVM-dev
+<http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ list. The reason is that
+extending LLVM will get involved as you need to update all the different passes
+that you intend to use with your extension, and there are ``many`` LLVM analyses
+and transformations, so it may be quite a bit of work.
+
+Adding an `intrinsic function`_ is far easier than adding an
+instruction, and is transparent to optimization passes.  If your added
+functionality can be expressed as a function call, an intrinsic function is the
+method of choice for LLVM extension.
+
+Before you invest a significant amount of effort into a non-trivial extension,
+**ask on the list** if what you are looking to do can be done with
+already-existing infrastructure, or if maybe someone else is already working on
+it. You will save yourself a lot of time and effort by doing so.
+
+.. _intrinsic function:
+
+Adding a new intrinsic function
+===============================
+
+Adding a new intrinsic function to LLVM is much easier than adding a new
+instruction.  Almost all extensions to LLVM should start as an intrinsic
+function and then be turned into an instruction if warranted.
+
+#. ``llvm/docs/LangRef.html``:
+
+   Document the intrinsic.  Decide whether it is code generator specific and
+   what the restrictions are.  Talk to other people about it so that you are
+   sure it's a good idea.
+
+#. ``llvm/include/llvm/Intrinsics*.td``:
+
+   Add an entry for your intrinsic.  Describe its memory access characteristics
+   for optimization (this controls whether it will be DCE'd, CSE'd, etc). Note
+   that any intrinsic using the ``llvm_int_ty`` type for an argument will
+   be deemed by ``tblgen`` as overloaded and the corresponding suffix will
+   be required on the intrinsic's name.
+
+#. ``llvm/lib/Analysis/ConstantFolding.cpp``:
+
+   If it is possible to constant fold your intrinsic, add support to it in the
+   ``canConstantFoldCallTo`` and ``ConstantFoldCall`` functions.
+
+#. ``llvm/test/Regression/*``:
+
+   Add test cases for your test cases to the test suite
+
+Once the intrinsic has been added to the system, you must add code generator
+support for it.  Generally you must do the following steps:
+
+Add support to the .td file for the target(s) of your choice in
+``lib/Target/*/*.td``.
+
+  This is usually a matter of adding a pattern to the .td file that matches the
+  intrinsic, though it may obviously require adding the instructions you want to
+  generate as well.  There are lots of examples in the PowerPC and X86 backend
+  to follow.
+
+Adding a new SelectionDAG node
+==============================
+
+As with intrinsics, adding a new SelectionDAG node to LLVM is much easier than
+adding a new instruction.  New nodes are often added to help represent
+instructions common to many targets.  These nodes often map to an LLVM
+instruction (add, sub) or intrinsic (byteswap, population count).  In other
+cases, new nodes have been added to allow many targets to perform a common task
+(converting between floating point and integer representation) or capture more
+complicated behavior in a single node (rotate).
+
+#. ``include/llvm/CodeGen/ISDOpcodes.h``:
+
+   Add an enum value for the new SelectionDAG node.
+
+#. ``lib/CodeGen/SelectionDAG/SelectionDAG.cpp``:
+
+   Add code to print the node to ``getOperationName``.  If your new node can be
+    evaluated at compile time when given constant arguments (such as an add of a
+    constant with another constant), find the ``getNode`` method that takes the
+    appropriate number of arguments, and add a case for your node to the switch
+    statement that performs constant folding for nodes that take the same number
+    of arguments as your new node.
+
+#. ``lib/CodeGen/SelectionDAG/LegalizeDAG.cpp``:
+
+   Add code to `legalize, promote, and expand
+   <CodeGenerator.html#selectiondag_legalize>`_ the node as necessary.  At a
+   minimum, you will need to add a case statement for your node in
+   ``LegalizeOp`` which calls LegalizeOp on the node's operands, and returns a
+   new node if any of the operands changed as a result of being legalized.  It
+   is likely that not all targets supported by the SelectionDAG framework will
+   natively support the new node.  In this case, you must also add code in your
+   node's case statement in ``LegalizeOp`` to Expand your node into simpler,
+   legal operations.  The case for ``ISD::UREM`` for expanding a remainder into
+   a divide, multiply, and a subtract is a good example.
+
+#. ``lib/CodeGen/SelectionDAG/LegalizeDAG.cpp``:
+
+   If targets may support the new node being added only at certain sizes, you
+    will also need to add code to your node's case statement in ``LegalizeOp``
+    to Promote your node's operands to a larger size, and perform the correct
+    operation.  You will also need to add code to ``PromoteOp`` to do this as
+    well.  For a good example, see ``ISD::BSWAP``, which promotes its operand to
+    a wider size, performs the byteswap, and then shifts the correct bytes right
+    to emulate the narrower byteswap in the wider type.
+
+#. ``lib/CodeGen/SelectionDAG/LegalizeDAG.cpp``:
+
+   Add a case for your node in ``ExpandOp`` to teach the legalizer how to
+   perform the action represented by the new node on a value that has been split
+   into high and low halves.  This case will be used to support your node with a
+   64 bit operand on a 32 bit target.
+
+#. ``lib/CodeGen/SelectionDAG/DAGCombiner.cpp``:
+
+   If your node can be combined with itself, or other existing nodes in a
+   peephole-like fashion, add a visit function for it, and call that function
+   from. There are several good examples for simple combines you can do;
+   ``visitFABS`` and ``visitSRL`` are good starting places.
+
+#. ``lib/Target/PowerPC/PPCISelLowering.cpp``:
+
+   Each target has an implementation of the ``TargetLowering`` class, usually in
+   its own file (although some targets include it in the same file as the
+   DAGToDAGISel).  The default behavior for a target is to assume that your new
+   node is legal for all types that are legal for that target.  If this target
+   does not natively support your node, then tell the target to either Promote
+   it (if it is supported at a larger type) or Expand it.  This will cause the
+   code you wrote in ``LegalizeOp`` above to decompose your new node into other
+   legal nodes for this target.
+
+#. ``lib/Target/TargetSelectionDAG.td``:
+
+   Most current targets supported by LLVM generate code using the DAGToDAG
+   method, where SelectionDAG nodes are pattern matched to target-specific
+   nodes, which represent individual instructions.  In order for the targets to
+   match an instruction to your new node, you must add a def for that node to
+   the list in this file, with the appropriate type constraints. Look at
+   ``add``, ``bswap``, and ``fadd`` for examples.
+
+#. ``lib/Target/PowerPC/PPCInstrInfo.td``:
+
+   Each target has a tablegen file that describes the target's instruction set.
+   For targets that use the DAGToDAG instruction selection framework, add a
+   pattern for your new node that uses one or more target nodes.  Documentation
+   for this is a bit sparse right now, but there are several decent examples.
+   See the patterns for ``rotl`` in ``PPCInstrInfo.td``.
+
+#. TODO: document complex patterns.
+
+#. ``llvm/test/Regression/CodeGen/*``:
+
+   Add test cases for your new node to the test suite.
+   ``llvm/test/Regression/CodeGen/X86/bswap.ll`` is a good example.
+
+Adding a new instruction
+========================
+
+.. warning::
+
+  Adding instructions changes the bitcode format, and it will take some effort
+  to maintain compatibility with the previous version. Only add an instruction
+  if it is absolutely necessary.
+
+#. ``llvm/include/llvm/Instruction.def``:
+
+   add a number for your instruction and an enum name
+
+#. ``llvm/include/llvm/Instructions.h``:
+
+   add a definition for the class that will represent your instruction
+
+#. ``llvm/include/llvm/Support/InstVisitor.h``:
+
+   add a prototype for a visitor to your new instruction type
+
+#. ``llvm/lib/AsmParser/Lexer.l``:
+
+   add a new token to parse your instruction from assembly text file
+
+#. ``llvm/lib/AsmParser/llvmAsmParser.y``:
+
+   add the grammar on how your instruction can be read and what it will
+   construct as a result
+
+#. ``llvm/lib/Bitcode/Reader/Reader.cpp``:
+
+   add a case for your instruction and how it will be parsed from bitcode
+
+#. ``llvm/lib/VMCore/Instruction.cpp``:
+
+   add a case for how your instruction will be printed out to assembly
+
+#. ``llvm/lib/VMCore/Instructions.cpp``:
+
+   implement the class you defined in ``llvm/include/llvm/Instructions.h``
+
+#. Test your instruction
+
+#. ``llvm/lib/Target/*``: 
+
+   add support for your instruction to code generators, or add a lowering pass.
+
+#. ``llvm/test/Regression/*``:
+
+   add your test cases to the test suite.
+
+Also, you need to implement (or modify) any analyses or passes that you want to
+understand this new instruction.
+
+Adding a new type
+=================
+
+.. warning::
+
+  Adding new types changes the bitcode format, and will break compatibility with
+  currently-existing LLVM installations. Only add new types if it is absolutely
+  necessary.
+
+Adding a fundamental type
+-------------------------
+
+#. ``llvm/include/llvm/Type.h``:
+
+   add enum for the new type; add static ``Type*`` for this type
+
+#. ``llvm/lib/VMCore/Type.cpp``:
+
+   add mapping from ``TypeID`` => ``Type*``; initialize the static ``Type*``
+
+#. ``llvm/lib/AsmReader/Lexer.l``:
+
+   add ability to parse in the type from text assembly
+
+#. ``llvm/lib/AsmReader/llvmAsmParser.y``:
+
+   add a token for that type
+
+Adding a derived type
+---------------------
+
+#. ``llvm/include/llvm/Type.h``:
+
+   add enum for the new type; add a forward declaration of the type also
+
+#. ``llvm/include/llvm/DerivedTypes.h``:
+
+   add new class to represent new class in the hierarchy; add forward
+   declaration to the TypeMap value type
+
+#. ``llvm/lib/VMCore/Type.cpp``:
+
+   add support for derived type to:
+
+   .. code-block:: c++
+
+     std::string getTypeDescription(const Type &Ty,
+                                    std::vector<const Type*> &TypeStack)
+     bool TypesEqual(const Type *Ty, const Type *Ty2,
+                     std::map<const Type*, const Type*> &EqTypes)
+
+   add necessary member functions for type, and factory methods
+
+#. ``llvm/lib/AsmReader/Lexer.l``:
+
+   add ability to parse in the type from text assembly
+
+#. ``llvm/lib/BitCode/Writer/Writer.cpp``:
+
+   modify ``void BitcodeWriter::outputType(const Type *T)`` to serialize your
+   type
+
+#. ``llvm/lib/BitCode/Reader/Reader.cpp``:
+
+   modify ``const Type *BitcodeReader::ParseType()`` to read your data type
+
+#. ``llvm/lib/VMCore/AsmWriter.cpp``:
+
+   modify
+
+   .. code-block:: c++
+
+     void calcTypeName(const Type *Ty,
+                       std::vector<const Type*> &TypeStack,
+                       std::map<const Type*,std::string> &TypeNames,
+                       std::string &Result)
+
+   to output the new derived type

Added: www-releases/trunk/3.2/docs/FAQ.rst
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/FAQ.rst?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/FAQ.rst (added)
+++ www-releases/trunk/3.2/docs/FAQ.rst Fri Dec 21 00:57:24 2012
@@ -0,0 +1,464 @@
+.. _faq:
+
+================================
+Frequently Asked Questions (FAQ)
+================================
+
+.. contents::
+   :local:
+
+
+License
+=======
+
+Does the University of Illinois Open Source License really qualify as an "open source" license?
+-----------------------------------------------------------------------------------------------
+Yes, the license is `certified
+<http://www.opensource.org/licenses/UoI-NCSA.php>`_ by the Open Source
+Initiative (OSI).
+
+
+Can I modify LLVM source code and redistribute the modified source?
+-------------------------------------------------------------------
+Yes.  The modified source distribution must retain the copyright notice and
+follow the three bulletted conditions listed in the `LLVM license
+<http://llvm.org/svn/llvm-project/llvm/trunk/LICENSE.TXT>`_.
+
+
+Can I modify the LLVM source code and redistribute binaries or other tools based on it, without redistributing the source?
+--------------------------------------------------------------------------------------------------------------------------
+Yes. This is why we distribute LLVM under a less restrictive license than GPL,
+as explained in the first question above.
+
+
+Source Code
+===========
+
+In what language is LLVM written?
+---------------------------------
+All of the LLVM tools and libraries are written in C++ with extensive use of
+the STL.
+
+
+How portable is the LLVM source code?
+-------------------------------------
+The LLVM source code should be portable to most modern Unix-like operating
+systems.  Most of the code is written in standard C++ with operating system
+services abstracted to a support library.  The tools required to build and
+test LLVM have been ported to a plethora of platforms.
+
+Some porting problems may exist in the following areas:
+
+* The autoconf/makefile build system relies heavily on UNIX shell tools,
+  like the Bourne Shell and sed.  Porting to systems without these tools
+  (MacOS 9, Plan 9) will require more effort.
+
+
+Build Problems
+==============
+
+When I run configure, it finds the wrong C compiler.
+----------------------------------------------------
+The ``configure`` script attempts to locate first ``gcc`` and then ``cc``,
+unless it finds compiler paths set in ``CC`` and ``CXX`` for the C and C++
+compiler, respectively.
+
+If ``configure`` finds the wrong compiler, either adjust your ``PATH``
+environment variable or set ``CC`` and ``CXX`` explicitly.
+
+
+The ``configure`` script finds the right C compiler, but it uses the LLVM tools from a previous build.  What do I do?
+---------------------------------------------------------------------------------------------------------------------
+The ``configure`` script uses the ``PATH`` to find executables, so if it's
+grabbing the wrong linker/assembler/etc, there are two ways to fix it:
+
+#. Adjust your ``PATH`` environment variable so that the correct program
+   appears first in the ``PATH``.  This may work, but may not be convenient
+   when you want them *first* in your path for other work.
+
+#. Run ``configure`` with an alternative ``PATH`` that is correct. In a
+   Bourne compatible shell, the syntax would be:
+
+.. code-block:: bash
+
+   % PATH=[the path without the bad program] ./configure ...
+
+This is still somewhat inconvenient, but it allows ``configure`` to do its
+work without having to adjust your ``PATH`` permanently.
+
+
+When creating a dynamic library, I get a strange GLIBC error.
+-------------------------------------------------------------
+Under some operating systems (i.e. Linux), libtool does not work correctly if
+GCC was compiled with the ``--disable-shared option``.  To work around this,
+install your own version of GCC that has shared libraries enabled by default.
+
+
+I've updated my source tree from Subversion, and now my build is trying to use a file/directory that doesn't exist.
+-------------------------------------------------------------------------------------------------------------------
+You need to re-run configure in your object directory.  When new Makefiles
+are added to the source tree, they have to be copied over to the object tree
+in order to be used by the build.
+
+
+I've modified a Makefile in my source tree, but my build tree keeps using the old version.  What do I do?
+---------------------------------------------------------------------------------------------------------
+If the Makefile already exists in your object tree, you can just run the
+following command in the top level directory of your object tree:
+
+.. code-block:: bash
+
+   % ./config.status <relative path to Makefile>;
+
+If the Makefile is new, you will have to modify the configure script to copy
+it over.
+
+
+I've upgraded to a new version of LLVM, and I get strange build errors.
+-----------------------------------------------------------------------
+Sometimes, changes to the LLVM source code alters how the build system works.
+Changes in ``libtool``, ``autoconf``, or header file dependencies are
+especially prone to this sort of problem.
+
+The best thing to try is to remove the old files and re-build.  In most cases,
+this takes care of the problem.  To do this, just type ``make clean`` and then
+``make`` in the directory that fails to build.
+
+
+I've built LLVM and am testing it, but the tests freeze.
+--------------------------------------------------------
+This is most likely occurring because you built a profile or release
+(optimized) build of LLVM and have not specified the same information on the
+``gmake`` command line.
+
+For example, if you built LLVM with the command:
+
+.. code-block:: bash
+
+   % gmake ENABLE_PROFILING=1
+
+...then you must run the tests with the following commands:
+
+.. code-block:: bash
+
+   % cd llvm/test
+   % gmake ENABLE_PROFILING=1
+
+Why do test results differ when I perform different types of builds?
+--------------------------------------------------------------------
+The LLVM test suite is dependent upon several features of the LLVM tools and
+libraries.
+
+First, the debugging assertions in code are not enabled in optimized or
+profiling builds.  Hence, tests that used to fail may pass.
+
+Second, some tests may rely upon debugging options or behavior that is only
+available in the debug build.  These tests will fail in an optimized or
+profile build.
+
+
+Compiling LLVM with GCC 3.3.2 fails, what should I do?
+------------------------------------------------------
+This is `a bug in GCC <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13392>`_,
+and affects projects other than LLVM.  Try upgrading or downgrading your GCC.
+
+
+Compiling LLVM with GCC succeeds, but the resulting tools do not work, what can be wrong?
+-----------------------------------------------------------------------------------------
+Several versions of GCC have shown a weakness in miscompiling the LLVM
+codebase.  Please consult your compiler version (``gcc --version``) to find
+out whether it is `broken <GettingStarted.html#brokengcc>`_.  If so, your only
+option is to upgrade GCC to a known good version.
+
+
+After Subversion update, rebuilding gives the error "No rule to make target".
+-----------------------------------------------------------------------------
+If the error is of the form:
+
+.. code-block:: bash
+
+   gmake[2]: *** No rule to make target `/path/to/somefile',
+   needed by `/path/to/another/file.d'.
+   Stop.
+
+This may occur anytime files are moved within the Subversion repository or
+removed entirely.  In this case, the best solution is to erase all ``.d``
+files, which list dependencies for source files, and rebuild:
+
+.. code-block:: bash
+
+   % cd $LLVM_OBJ_DIR
+   % rm -f `find . -name \*\.d`
+   % gmake
+
+In other cases, it may be necessary to run ``make clean`` before rebuilding.
+
+
+Source Languages
+================
+
+What source languages are supported?
+------------------------------------
+LLVM currently has full support for C and C++ source languages. These are
+available through both `Clang <http://clang.llvm.org/>`_ and `DragonEgg
+<http://dragonegg.llvm.org/>`_.
+
+The PyPy developers are working on integrating LLVM into the PyPy backend so
+that PyPy language can translate to LLVM.
+
+
+I'd like to write a self-hosting LLVM compiler. How should I interface with the LLVM middle-end optimizers and back-end code generators?
+----------------------------------------------------------------------------------------------------------------------------------------
+Your compiler front-end will communicate with LLVM by creating a module in the
+LLVM intermediate representation (IR) format. Assuming you want to write your
+language's compiler in the language itself (rather than C++), there are 3
+major ways to tackle generating LLVM IR from a front-end:
+
+1. **Call into the LLVM libraries code using your language's FFI (foreign
+   function interface).**
+
+  * *for:* best tracks changes to the LLVM IR, .ll syntax, and .bc format
+
+  * *for:* enables running LLVM optimization passes without a emit/parse
+    overhead
+
+  * *for:* adapts well to a JIT context
+
+  * *against:* lots of ugly glue code to write
+
+2. **Emit LLVM assembly from your compiler's native language.**
+
+  * *for:* very straightforward to get started
+
+  * *against:* the .ll parser is slower than the bitcode reader when
+    interfacing to the middle end
+
+  * *against:* it may be harder to track changes to the IR
+
+3. **Emit LLVM bitcode from your compiler's native language.**
+
+  * *for:* can use the more-efficient bitcode reader when interfacing to the
+    middle end
+
+  * *against:* you'll have to re-engineer the LLVM IR object model and bitcode
+    writer in your language
+
+  * *against:* it may be harder to track changes to the IR
+
+If you go with the first option, the C bindings in include/llvm-c should help
+a lot, since most languages have strong support for interfacing with C. The
+most common hurdle with calling C from managed code is interfacing with the
+garbage collector. The C interface was designed to require very little memory
+management, and so is straightforward in this regard.
+
+What support is there for a higher level source language constructs for building a compiler?
+--------------------------------------------------------------------------------------------
+Currently, there isn't much. LLVM supports an intermediate representation
+which is useful for code representation but will not support the high level
+(abstract syntax tree) representation needed by most compilers. There are no
+facilities for lexical nor semantic analysis.
+
+
+I don't understand the ``GetElementPtr`` instruction. Help!
+-----------------------------------------------------------
+See `The Often Misunderstood GEP Instruction <GetElementPtr.html>`_.
+
+
+Using the C and C++ Front Ends
+==============================
+
+Can I compile C or C++ code to platform-independent LLVM bitcode?
+-----------------------------------------------------------------
+No. C and C++ are inherently platform-dependent languages. The most obvious
+example of this is the preprocessor. A very common way that C code is made
+portable is by using the preprocessor to include platform-specific code. In
+practice, information about other platforms is lost after preprocessing, so
+the result is inherently dependent on the platform that the preprocessing was
+targeting.
+
+Another example is ``sizeof``. It's common for ``sizeof(long)`` to vary
+between platforms. In most C front-ends, ``sizeof`` is expanded to a
+constant immediately, thus hard-wiring a platform-specific detail.
+
+Also, since many platforms define their ABIs in terms of C, and since LLVM is
+lower-level than C, front-ends currently must emit platform-specific IR in
+order to have the result conform to the platform ABI.
+
+
+Questions about code generated by the demo page
+===============================================
+
+What is this ``llvm.global_ctors`` and ``_GLOBAL__I_a...`` stuff that happens when I ``#include <iostream>``?
+-------------------------------------------------------------------------------------------------------------
+If you ``#include`` the ``<iostream>`` header into a C++ translation unit,
+the file will probably use the ``std::cin``/``std::cout``/... global objects.
+However, C++ does not guarantee an order of initialization between static
+objects in different translation units, so if a static ctor/dtor in your .cpp
+file used ``std::cout``, for example, the object would not necessarily be
+automatically initialized before your use.
+
+To make ``std::cout`` and friends work correctly in these scenarios, the STL
+that we use declares a static object that gets created in every translation
+unit that includes ``<iostream>``.  This object has a static constructor
+and destructor that initializes and destroys the global iostream objects
+before they could possibly be used in the file.  The code that you see in the
+``.ll`` file corresponds to the constructor and destructor registration code.
+
+If you would like to make it easier to *understand* the LLVM code generated
+by the compiler in the demo page, consider using ``printf()`` instead of
+``iostream``\s to print values.
+
+
+Where did all of my code go??
+-----------------------------
+If you are using the LLVM demo page, you may often wonder what happened to
+all of the code that you typed in.  Remember that the demo script is running
+the code through the LLVM optimizers, so if your code doesn't actually do
+anything useful, it might all be deleted.
+
+To prevent this, make sure that the code is actually needed.  For example, if
+you are computing some expression, return the value from the function instead
+of leaving it in a local variable.  If you really want to constrain the
+optimizer, you can read from and assign to ``volatile`` global variables.
+
+
+What is this "``undef``" thing that shows up in my code?
+--------------------------------------------------------
+``undef`` is the LLVM way of representing a value that is not defined.  You
+can get these if you do not initialize a variable before you use it.  For
+example, the C function:
+
+.. code-block:: c
+
+   int X() { int i; return i; }
+
+Is compiled to "``ret i32 undef``" because "``i``" never has a value specified
+for it.
+
+
+Why does instcombine + simplifycfg turn a call to a function with a mismatched calling convention into "unreachable"? Why not make the verifier reject it?
+----------------------------------------------------------------------------------------------------------------------------------------------------------
+This is a common problem run into by authors of front-ends that are using
+custom calling conventions: you need to make sure to set the right calling
+convention on both the function and on each call to the function.  For
+example, this code:
+
+.. code-block:: llvm
+
+   define fastcc void @foo() {
+       ret void
+   }
+   define void @bar() {
+       call void @foo()
+       ret void
+   }
+
+Is optimized to:
+
+.. code-block:: llvm
+
+   define fastcc void @foo() {
+       ret void
+   }
+   define void @bar() {
+       unreachable
+   }
+
+... with "``opt -instcombine -simplifycfg``".  This often bites people because
+"all their code disappears".  Setting the calling convention on the caller and
+callee is required for indirect calls to work, so people often ask why not
+make the verifier reject this sort of thing.
+
+The answer is that this code has undefined behavior, but it is not illegal.
+If we made it illegal, then every transformation that could potentially create
+this would have to ensure that it doesn't, and there is valid code that can
+create this sort of construct (in dead code).  The sorts of things that can
+cause this to happen are fairly contrived, but we still need to accept them.
+Here's an example:
+
+.. code-block:: llvm
+
+   define fastcc void @foo() {
+       ret void
+   }
+   define internal void @bar(void()* %FP, i1 %cond) {
+       br i1 %cond, label %T, label %F
+   T:
+       call void %FP()
+       ret void
+   F:
+       call fastcc void %FP()
+       ret void
+   }
+   define void @test() {
+       %X = or i1 false, false
+       call void @bar(void()* @foo, i1 %X)
+       ret void
+   }
+
+In this example, "test" always passes ``@foo``/``false`` into ``bar``, which
+ensures that it is dynamically called with the right calling conv (thus, the
+code is perfectly well defined).  If you run this through the inliner, you
+get this (the explicit "or" is there so that the inliner doesn't dead code
+eliminate a bunch of stuff):
+
+.. code-block:: llvm
+
+   define fastcc void @foo() {
+       ret void
+   }
+   define void @test() {
+       %X = or i1 false, false
+       br i1 %X, label %T.i, label %F.i
+   T.i:
+       call void @foo()
+       br label %bar.exit
+   F.i:
+       call fastcc void @foo()
+       br label %bar.exit
+   bar.exit:
+       ret void
+   }
+
+Here you can see that the inlining pass made an undefined call to ``@foo``
+with the wrong calling convention.  We really don't want to make the inliner
+have to know about this sort of thing, so it needs to be valid code.  In this
+case, dead code elimination can trivially remove the undefined code.  However,
+if ``%X`` was an input argument to ``@test``, the inliner would produce this:
+
+.. code-block:: llvm
+
+   define fastcc void @foo() {
+       ret void
+   }
+
+   define void @test(i1 %X) {
+       br i1 %X, label %T.i, label %F.i
+   T.i:
+       call void @foo()
+       br label %bar.exit
+   F.i:
+       call fastcc void @foo()
+       br label %bar.exit
+   bar.exit:
+       ret void
+   }
+
+The interesting thing about this is that ``%X`` *must* be false for the
+code to be well-defined, but no amount of dead code elimination will be able
+to delete the broken call as unreachable.  However, since
+``instcombine``/``simplifycfg`` turns the undefined call into unreachable, we
+end up with a branch on a condition that goes to unreachable: a branch to
+unreachable can never happen, so "``-inline -instcombine -simplifycfg``" is
+able to produce:
+
+.. code-block:: llvm
+
+   define fastcc void @foo() {
+      ret void
+   }
+   define void @test(i1 %X) {
+   F.i:
+      call fastcc void @foo()
+      ret void
+   }

Added: www-releases/trunk/3.2/docs/GCCFEBuildInstrs.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/GCCFEBuildInstrs.html?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/GCCFEBuildInstrs.html (added)
+++ www-releases/trunk/3.2/docs/GCCFEBuildInstrs.html Fri Dec 21 00:57:24 2012
@@ -0,0 +1,279 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+                      "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+  <link rel="stylesheet" href="_static/llvm.css" type="text/css" media="screen">
+  <title>Building the LLVM GCC Front-End</title>
+</head>
+<body>
+
+<h1>
+  Building the LLVM GCC Front-End
+</h1>
+
+<ol>
+  <li><a href="#instructions">Building llvm-gcc from Source</a></li>
+  <li><a href="#ada">Building the Ada front-end</a></li>
+  <li><a href="#fortran">Building the Fortran front-end</a></li>
+  <li><a href="#license">License Information</a></li>
+</ol>
+
+<div class="doc_author">    
+  <p>Written by the LLVM Team</p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="instructions">Building llvm-gcc from Source</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>This section describes how to acquire and build llvm-gcc 4.2, which is based
+on the GCC 4.2.1 front-end.  Supported languages are Ada, C, C++, Fortran,
+Objective-C and Objective-C++.  Note that the instructions for building these
+front-ends are completely different (and much easier!) than those for building
+llvm-gcc3 in the past.</p>
+
+<ol>
+  <li><p>Retrieve the appropriate llvm-gcc-4.2-<i>version</i>.source.tar.gz
+         archive from the <a href="http://llvm.org/releases/">LLVM web
+         site</a>.</p>
+
+      <p>It is also possible to download the sources of the llvm-gcc front end
+         from a read-only mirror using subversion.  To check out the 4.2 code
+         for first time use:</p>
+
+<div class="doc_code">
+<pre>
+svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk <i>dst-directory</i>
+</pre>
+</div>
+
+      <p>After that, the code can be be updated in the destination directory
+         using:</p>
+
+<div class="doc_code">
+<pre>svn update</pre>
+</div>
+
+      <p>The mirror is brought up to date every evening.</p></li>
+
+  <li>Follow the directions in the top-level <tt>README.LLVM</tt> file for
+      up-to-date instructions on how to build llvm-gcc.  See below for building
+      with support for Ada or Fortran.
+</ol>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="ada">Building the Ada front-end</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+<p>Building with support for Ada amounts to following the directions in the
+top-level <tt>README.LLVM</tt> file, adding ",ada" to EXTRALANGS, for example:
+<tt>EXTRALANGS=,ada</tt></p>
+
+<p>There are some complications however:</p>
+
+<ol>
+  <li><p>The only platform for which the Ada front-end is known to build is
+      32 bit intel x86 running linux.  It is unlikely to build for other
+      systems without some work.</p></li>
+  <li><p>The build requires having a compiler that supports Ada, C and C++.
+      The Ada front-end is written in Ada so an Ada compiler is needed to
+      build it.  Compilers known to work with the
+      <a href="http://llvm.org/releases/download.html">LLVM 2.7 release</a>
+      are <a href="http://gcc.gnu.org/releases.html">gcc-4.2</a> and the
+      2005, 2006 and 2007 versions of the
+      <a href="http://libre.adacore.com/">GNAT GPL Edition</a>.
+      <b>GNAT GPL 2008, gcc-4.3 and later will not work</b>.
+      The LLVM parts of llvm-gcc are written in C++ so a C++ compiler is
+      needed to build them.  The rest of gcc is written in C.
+      Some linux distributions provide a version of gcc that supports all
+      three languages (the Ada part often comes as an add-on package to
+      the rest of gcc).  Otherwise it is possible to combine two versions
+      of gcc, one that supports Ada and C (such as the
+      <a href="http://libre.adacore.com/">2007 GNAT GPL Edition</a>)
+      and another which supports C++, see below.</p></li>
+  <li><p>Because the Ada front-end is experimental, it is wise to build the
+      compiler with checking enabled.  This causes it to run much slower, but
+      helps catch mistakes in the compiler (please report any problems using
+      <a href="http://llvm.org/bugs/">LLVM bugzilla</a>).</p></li>
+  <li><p>The Ada front-end <a href="http://llvm.org/PR2007">fails to
+      bootstrap</a>, due to lack of LLVM support for
+      <tt>setjmp</tt>/<tt>longjmp</tt> style exception handling (used
+      internally by the compiler), so you must specify
+      <tt>--disable-bootstrap</tt>.</p></li>
+</ol>
+
+<p>Supposing appropriate compilers are available, llvm-gcc with Ada support can
+   be built on an x86-32 linux box using the following recipe:</p>
+
+<ol>
+  <li><p>Download the <a href="http://llvm.org/releases/download.html">LLVM source</a>
+      and unpack it:</p>
+
+<pre class="doc_code">
+wget http://llvm.org/releases/2.7/llvm-2.7.tgz
+tar xzf llvm-2.7.tgz
+mv llvm-2.7 llvm
+</pre>
+
+      <p>or <a href="GettingStarted.html#checkout">check out the
+      latest version from subversion</a>:</p>
+
+<pre class="doc_code">svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm</pre>
+
+      </li>
+
+  <li><p>Download the
+      <a href="http://llvm.org/releases/download.html">llvm-gcc-4.2 source</a>
+      and unpack it:</p>
+
+<pre class="doc_code">
+wget http://llvm.org/releases/2.7/llvm-gcc-4.2-2.7.source.tgz
+tar xzf llvm-gcc-4.2-2.7.source.tgz
+mv llvm-gcc-4.2-2.7.source llvm-gcc-4.2
+</pre>
+
+      <p>or <a href="GettingStarted.html#checkout">check out the
+      latest version from subversion</a>:</p>
+
+<pre class="doc_code">
+svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk llvm-gcc-4.2
+</pre>
+      </li>
+
+  <li><p>Make a build directory <tt>llvm-objects</tt> for llvm and make it the
+      current directory:</p>
+
+<pre class="doc_code">
+mkdir llvm-objects
+cd llvm-objects
+</pre>
+      </li>
+
+  <li><p>Configure LLVM (here it is configured to install into <tt>/usr/local</tt>):</p>
+
+<pre class="doc_code">
+../llvm/configure --prefix=<b>/usr/local</b> --enable-optimized --enable-assertions
+</pre>
+
+      <p>If you have a multi-compiler setup and the C++ compiler is not the
+      default, then you can configure like this:</p>
+
+<pre class="doc_code">
+CXX=<b>PATH_TO_C++_COMPILER</b> ../llvm/configure --prefix=<b>/usr/local</b> --enable-optimized --enable-assertions
+</pre>
+
+      <p>To compile without checking (not recommended), replace
+      <tt>--enable-assertions</tt> with <tt>--disable-assertions</tt>.</p>
+
+      </li>
+
+  <li><p>Build LLVM:</p>
+
+<pre class="doc_code">
+make
+</pre>
+      </li>
+
+  <li><p>Install LLVM (optional):</p>
+
+<pre class="doc_code">
+make install
+</pre>
+      </li>
+
+  <li><p>Make a build directory <tt>llvm-gcc-4.2-objects</tt> for llvm-gcc and make it the
+      current directory:</p>
+
+<pre class="doc_code">
+cd ..
+mkdir llvm-gcc-4.2-objects
+cd llvm-gcc-4.2-objects
+</pre>
+      </li>
+
+  <li><p>Configure llvm-gcc (here it is configured to install into <tt>/usr/local</tt>).
+      The <tt>--enable-checking</tt> flag turns on sanity checks inside the compiler.
+      To turn off these checks (not recommended), replace <tt>--enable-checking</tt>
+      with <tt>--disable-checking</tt>.
+      Additional languages can be appended to the <tt>--enable-languages</tt> switch,
+      for example <tt>--enable-languages=ada,c,c++</tt>.</p>
+
+<pre class="doc_code">
+../llvm-gcc-4.2/configure --prefix=<b>/usr/local</b> --enable-languages=ada,c \
+                          --enable-checking --enable-llvm=$PWD/../llvm-objects \
+			  --disable-bootstrap --disable-multilib
+</pre>
+
+      <p>If you have a multi-compiler setup, then you can configure like this:</p>
+
+<pre class="doc_code">
+export CC=<b>PATH_TO_C_AND_ADA_COMPILER</b>
+export CXX=<b>PATH_TO_C++_COMPILER</b>
+../llvm-gcc-4.2/configure --prefix=<b>/usr/local</b> --enable-languages=ada,c \
+                          --enable-checking --enable-llvm=$PWD/../llvm-objects \
+			  --disable-bootstrap --disable-multilib
+</pre>
+      </li>
+
+  <li><p>Build and install the compiler:</p>
+
+<pre class="doc_code">
+make
+make install
+</pre>
+      </li>
+</ol>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="fortran">Building the Fortran front-end</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+<p>To build with support for Fortran, follow the directions in the top-level
+<tt>README.LLVM</tt> file, adding ",fortran" to EXTRALANGS, for example:</p>
+
+<pre class="doc_code">
+EXTRALANGS=,fortran
+</pre>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="license">License Information</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+<p>
+The LLVM GCC frontend is licensed to you under the GNU General Public License
+and the GNU Lesser General Public License.  Please see the files COPYING and
+COPYING.LIB for more details.
+</p>
+
+<p>
+More information is <a href="FAQ.html#license">available in the FAQ</a>.
+</p>
+</div>
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+  src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+  <a href="http://validator.w3.org/check/referer"><img
+  src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+  <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+  Last modified: $Date: 2012-04-19 15:20:34 -0500 (Thu, 19 Apr 2012) $
+</address>
+
+</body>
+</html>

Added: www-releases/trunk/3.2/docs/GarbageCollection.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.2/docs/GarbageCollection.html?rev=170845&view=auto
==============================================================================
--- www-releases/trunk/3.2/docs/GarbageCollection.html (added)
+++ www-releases/trunk/3.2/docs/GarbageCollection.html Fri Dec 21 00:57:24 2012
@@ -0,0 +1,1389 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+                      "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+  <meta http-equiv="Content-Type" Content="text/html; charset=UTF-8" >
+  <title>Accurate Garbage Collection with LLVM</title>
+  <link rel="stylesheet" href="_static/llvm.css" type="text/css">
+  <style type="text/css">
+    .rowhead { text-align: left; background: inherit; }
+    .indent { padding-left: 1em; }
+    .optl { color: #BFBFBF; }
+  </style>
+</head>
+<body>
+
+<h1>
+  Accurate Garbage Collection with LLVM
+</h1>
+
+<ol>
+  <li><a href="#introduction">Introduction</a>
+    <ul>
+    <li><a href="#feature">Goals and non-goals</a></li>
+    </ul>
+  </li>
+
+  <li><a href="#quickstart">Getting started</a>
+    <ul>
+    <li><a href="#quickstart-compiler">In your compiler</a></li>
+    <li><a href="#quickstart-runtime">In your runtime library</a></li>
+    <li><a href="#shadow-stack">About the shadow stack</a></li>
+    </ul>
+  </li>
+
+  <li><a href="#core">Core support</a>
+    <ul>
+    <li><a href="#gcattr">Specifying GC code generation:
+      <tt>gc "..."</tt></a></li>
+    <li><a href="#gcroot">Identifying GC roots on the stack:
+      <tt>llvm.gcroot</tt></a></li>
+    <li><a href="#barriers">Reading and writing references in the heap</a>
+      <ul>
+      <li><a href="#gcwrite">Write barrier: <tt>llvm.gcwrite</tt></a></li>
+      <li><a href="#gcread">Read barrier: <tt>llvm.gcread</tt></a></li>
+      </ul>
+    </li>
+    </ul>
+  </li>
+  
+  <li><a href="#plugin">Compiler plugin interface</a>
+    <ul>
+    <li><a href="#collector-algos">Overview of available features</a></li>
+    <li><a href="#stack-map">Computing stack maps</a></li>
+    <li><a href="#init-roots">Initializing roots to null:
+      <tt>InitRoots</tt></a></li>
+    <li><a href="#custom">Custom lowering of intrinsics: <tt>CustomRoots</tt>, 
+      <tt>CustomReadBarriers</tt>, and <tt>CustomWriteBarriers</tt></a></li>
+    <li><a href="#safe-points">Generating safe points:
+      <tt>NeededSafePoints</tt></a></li>
+    <li><a href="#assembly">Emitting assembly code:
+      <tt>GCMetadataPrinter</tt></a></li>
+    </ul>
+  </li>
+
+  <li><a href="#runtime-impl">Implementing a collector runtime</a>
+    <ul>
+      <li><a href="#gcdescriptors">Tracing GC pointers from heap
+      objects</a></li>
+    </ul>
+  </li>
+  
+  <li><a href="#references">References</a></li>
+  
+</ol>
+
+<div class="doc_author">
+  <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a> and
+     Gordon Henriksen</p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+  <a name="introduction">Introduction</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Garbage collection is a widely used technique that frees the programmer from
+having to know the lifetimes of heap objects, making software easier to produce
+and maintain. Many programming languages rely on garbage collection for
+automatic memory management. There are two primary forms of garbage collection:
+conservative and accurate.</p>
+
+<p>Conservative garbage collection often does not require any special support
+from either the language or the compiler: it can handle non-type-safe
+programming languages (such as C/C++) and does not require any special
+information from the compiler. The
+<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm collector</a> is
+an example of a state-of-the-art conservative collector.</p>
+
+<p>Accurate garbage collection requires the ability to identify all pointers in
+the program at run-time (which requires that the source-language be type-safe in
+most cases). Identifying pointers at run-time requires compiler support to
+locate all places that hold live pointer variables at run-time, including the
+<a href="#gcroot">processor stack and registers</a>.</p>
+
+<p>Conservative garbage collection is attractive because it does not require any
+special compiler support, but it does have problems. In particular, because the
+conservative garbage collector cannot <i>know</i> that a particular word in the
+machine is a pointer, it cannot move live objects in the heap (preventing the
+use of compacting and generational GC algorithms) and it can occasionally suffer
+from memory leaks due to integer values that happen to point to objects in the
+program. In addition, some aggressive compiler transformations can break
+conservative garbage collectors (though these seem rare in practice).</p>
+
+<p>Accurate garbage collectors do not suffer from any of these problems, but
+they can suffer from degraded scalar optimization of the program. In particular,
+because the runtime must be able to identify and update all pointers active in
+the program, some optimizations are less effective. In practice, however, the
+locality and performance benefits of using aggressive garbage collection
+techniques dominates any low-level losses.</p>
+
+<p>This document describes the mechanisms and interfaces provided by LLVM to
+support accurate garbage collection.</p>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="feature">Goals and non-goals</a>
+</h3>
+
+<div>
+
+<p>LLVM's intermediate representation provides <a href="#intrinsics">garbage
+collection intrinsics</a> that offer support for a broad class of
+collector models. For instance, the intrinsics permit:</p>
+
+<ul>
+  <li>semi-space collectors</li>
+  <li>mark-sweep collectors</li>
+  <li>generational collectors</li>
+  <li>reference counting</li>
+  <li>incremental collectors</li>
+  <li>concurrent collectors</li>
+  <li>cooperative collectors</li>
+</ul>
+
+<p>We hope that the primitive support built into the LLVM IR is sufficient to
+support a broad class of garbage collected languages including Scheme, ML, Java,
+C#, Perl, Python, Lua, Ruby, other scripting languages, and more.</p>
+
+<p>However, LLVM does not itself provide a garbage collector—this should
+be part of your language's runtime library. LLVM provides a framework for
+compile time <a href="#plugin">code generation plugins</a>. The role of these
+plugins is to generate code and data structures which conforms to the <em>binary
+interface</em> specified by the <em>runtime library</em>. This is similar to the
+relationship between LLVM and DWARF debugging info, for example. The
+difference primarily lies in the lack of an established standard in the domain
+of garbage collection—thus the plugins.</p>
+
+<p>The aspects of the binary interface with which LLVM's GC support is
+concerned are:</p>
+
+<ul>
+  <li>Creation of GC-safe points within code where collection is allowed to
+      execute safely.</li>
+  <li>Computation of the stack map. For each safe point in the code, object
+      references within the stack frame must be identified so that the
+      collector may traverse and perhaps update them.</li>
+  <li>Write barriers when storing object references to the heap. These are
+      commonly used to optimize incremental scans in generational
+      collectors.</li>
+  <li>Emission of read barriers when loading object references. These are
+      useful for interoperating with concurrent collectors.</li>
+</ul>
+
+<p>There are additional areas that LLVM does not directly address:</p>
+
+<ul>
+  <li>Registration of global roots with the runtime.</li>
+  <li>Registration of stack map entries with the runtime.</li>
+  <li>The functions used by the program to allocate memory, trigger a
+      collection, etc.</li>
+  <li>Computation or compilation of type maps, or registration of them with
+      the runtime. These are used to crawl the heap for object
+      references.</li>
+</ul>
+
+<p>In general, LLVM's support for GC does not include features which can be
+adequately addressed with other features of the IR and does not specify a
+particular binary interface. On the plus side, this means that you should be
+able to integrate LLVM with an existing runtime. On the other hand, it leaves
+a lot of work for the developer of a novel language. However, it's easy to get
+started quickly and scale up to a more sophisticated implementation as your
+compiler matures.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+  <a name="quickstart">Getting started</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Using a GC with LLVM implies many things, for example:</p>
+
+<ul>
+  <li>Write a runtime library or find an existing one which implements a GC
+      heap.<ol>
+    <li>Implement a memory allocator.</li>
+    <li>Design a binary interface for the stack map, used to identify
+        references within a stack frame on the machine stack.*</li>
+    <li>Implement a stack crawler to discover functions on the call stack.*</li>
+    <li>Implement a registry for global roots.</li>
+    <li>Design a binary interface for type maps, used to identify references
+        within heap objects.</li>
+    <li>Implement a collection routine bringing together all of the above.</li>
+  </ol></li>
+  <li>Emit compatible code from your compiler.<ul>
+    <li>Initialization in the main function.</li>
+    <li>Use the <tt>gc "..."</tt> attribute to enable GC code generation
+        (or <tt>F.setGC("...")</tt>).</li>
+    <li>Use <tt>@llvm.gcroot</tt> to mark stack roots.</li>
+    <li>Use <tt>@llvm.gcread</tt> and/or <tt>@llvm.gcwrite</tt> to
+        manipulate GC references, if necessary.</li>
+    <li>Allocate memory using the GC allocation routine provided by the
+        runtime library.</li>
+    <li>Generate type maps according to your runtime's binary interface.</li>
+  </ul></li>
+  <li>Write a compiler plugin to interface LLVM with the runtime library.*<ul>
+    <li>Lower <tt>@llvm.gcread</tt> and <tt>@llvm.gcwrite</tt> to appropriate
+        code sequences.*</li>
+    <li>Compile LLVM's stack map to the binary form expected by the
+        runtime.</li>
+  </ul></li>
+  <li>Load the plugin into the compiler. Use <tt>llc -load</tt> or link the
+      plugin statically with your language's compiler.*</li>
+  <li>Link program executables with the runtime.</li>
+</ul>
+
+<p>To help with several of these tasks (those indicated with a *), LLVM
+includes a highly portable, built-in ShadowStack code generator. It is compiled
+into <tt>llc</tt> and works even with the interpreter and C backends.</p>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="quickstart-compiler">In your compiler</a>
+</h3>
+
+<div>
+
+<p>To turn the shadow stack on for your functions, first call:</p>
+
+<div class="doc_code"><pre
+>F.setGC("shadow-stack");</pre></div>
+
+<p>for each function your compiler emits. Since the shadow stack is built into
+LLVM, you do not need to load a plugin.</p>
+
+<p>Your compiler must also use <tt>@llvm.gcroot</tt> as documented.
+Don't forget to create a root for each intermediate value that is generated
+when evaluating an expression. In <tt>h(f(), g())</tt>, the result of
+<tt>f()</tt> could easily be collected if evaluating <tt>g()</tt> triggers a
+collection.</p>
+
+<p>There's no need to use <tt>@llvm.gcread</tt> and <tt>@llvm.gcwrite</tt> over
+plain <tt>load</tt> and <tt>store</tt> for now. You will need them when
+switching to a more advanced GC.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="quickstart-runtime">In your runtime</a>
+</h3>
+
+<div>
+
+<p>The shadow stack doesn't imply a memory allocation algorithm. A semispace
+collector or building atop <tt>malloc</tt> are great places to start, and can
+be implemented with very little code.</p>
+
+<p>When it comes time to collect, however, your runtime needs to traverse the
+stack roots, and for this it needs to integrate with the shadow stack. Luckily,
+doing so is very simple. (This code is heavily commented to help you
+understand the data structure, but there are only 20 lines of meaningful
+code.)</p>
+
+<pre class="doc_code">
+/// @brief The map for a single function's stack frame. One of these is
+///        compiled as constant data into the executable for each function.
+/// 
+/// Storage of metadata values is elided if the %metadata parameter to
+/// @llvm.gcroot is null.
+struct FrameMap {
+  int32_t NumRoots;    //< Number of roots in stack frame.
+  int32_t NumMeta;     //< Number of metadata entries. May be < NumRoots.
+  const void *Meta[0]; //< Metadata for each root.
+};
+
+/// @brief A link in the dynamic shadow stack. One of these is embedded in the
+///        stack frame of each function on the call stack.
+struct StackEntry {
+  StackEntry *Next;    //< Link to next stack entry (the caller's).
+  const FrameMap *Map; //< Pointer to constant FrameMap.
+  void *Roots[0];      //< Stack roots (in-place array).
+};
+
+/// @brief The head of the singly-linked list of StackEntries. Functions push
+///        and pop onto this in their prologue and epilogue.
+/// 
+/// Since there is only a global list, this technique is not threadsafe.
+StackEntry *llvm_gc_root_chain;
+
+/// @brief Calls Visitor(root, meta) for each GC root on the stack.
+///        root and meta are exactly the values passed to
+///        <tt>@llvm.gcroot</tt>.
+/// 
+/// Visitor could be a function to recursively mark live objects. Or it
+/// might copy them to another heap or generation.
+/// 
+/// @param Visitor A function to invoke for every GC root on the stack.
+void visitGCRoots(void (*Visitor)(void **Root, const void *Meta)) {
+  for (StackEntry *R = llvm_gc_root_chain; R; R = R->Next) {
+    unsigned i = 0;
+    
+    // For roots [0, NumMeta), the metadata pointer is in the FrameMap.
+    for (unsigned e = R->Map->NumMeta; i != e; ++i)
+      Visitor(&R->Roots[i], R->Map->Meta[i]);
+    
+    // For roots [NumMeta, NumRoots), the metadata pointer is null.
+    for (unsigned e = R->Map->NumRoots; i != e; ++i)
+      Visitor(&R->Roots[i], NULL);
+  }
+}</pre>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="shadow-stack">About the shadow stack</a>
+</h3>
+
+<div>
+
+<p>Unlike many GC algorithms which rely on a cooperative code generator to
+compile stack maps, this algorithm carefully maintains a linked list of stack
+roots [<a href="#henderson02">Henderson2002</a>]. This so-called "shadow stack"
+mirrors the machine stack. Maintaining this data structure is slower than using
+a stack map compiled into the executable as constant data, but has a significant
+portability advantage because it requires no special support from the target
+code generator, and does not require tricky platform-specific code to crawl
+the machine stack.</p>
+
+<p>The tradeoff for this simplicity and portability is:</p>
+
+<ul>
+  <li>High overhead per function call.</li>
+  <li>Not thread-safe.</li>
+</ul>
+
+<p>Still, it's an easy way to get started. After your compiler and runtime are
+up and running, writing a <a href="#plugin">plugin</a> will allow you to take
+advantage of <a href="#collector-algos">more advanced GC features</a> of LLVM
+in order to improve performance.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+  <a name="core">IR features</a><a name="intrinsics"></a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>This section describes the garbage collection facilities provided by the
+<a href="LangRef.html">LLVM intermediate representation</a>. The exact behavior
+of these IR features is specified by the binary interface implemented by a
+<a href="#plugin">code generation plugin</a>, not by this document.</p>
+
+<p>These facilities are limited to those strictly necessary; they are not
+intended to be a complete interface to any garbage collector. A program will
+need to interface with the GC library using the facilities provided by that
+program.</p>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="gcattr">Specifying GC code generation: <tt>gc "..."</tt></a>
+</h3>
+
+<div>
+
+<div class="doc_code"><tt>
+  define <i>ty</i> @<i>name</i>(...) <span style="text-decoration: underline">gc "<i>name</i>"</span> { ...
+</tt></div>
+
+<p>The <tt>gc</tt> function attribute is used to specify the desired GC style
+to the compiler. Its programmatic equivalent is the <tt>setGC</tt> method of
+<tt>Function</tt>.</p>
+
+<p>Setting <tt>gc "<i>name</i>"</tt> on a function triggers a search for a
+matching code generation plugin "<i>name</i>"; it is that plugin which defines
+the exact nature of the code generated to support GC. If none is found, the
+compiler will raise an error.</p>
+
+<p>Specifying the GC style on a per-function basis allows LLVM to link together
+programs that use different garbage collection algorithms (or none at all).</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="gcroot">Identifying GC roots on the stack: <tt>llvm.gcroot</tt></a>
+</h3>
+
+<div>
+
+<div class="doc_code"><tt>
+  void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
+</tt></div>
+
+<p>The <tt>llvm.gcroot</tt> intrinsic is used to inform LLVM that a stack
+variable references an object on the heap and is to be tracked for garbage
+collection. The exact impact on generated code is specified by a <a
+href="#plugin">compiler plugin</a>. All calls to <tt>llvm.gcroot</tt> <b>must</b> reside
+ inside the first basic block.</p>
+
+<p>A compiler which uses mem2reg to raise imperative code using <tt>alloca</tt>
+into SSA form need only add a call to <tt>@llvm.gcroot</tt> for those variables
+which a pointers into the GC heap.</p>
+
+<p>It is also important to mark intermediate values with <tt>llvm.gcroot</tt>.
+For example, consider <tt>h(f(), g())</tt>. Beware leaking the result of
+<tt>f()</tt> in the case that <tt>g()</tt> triggers a collection. Note, that
+stack variables must be initialized and marked with <tt>llvm.gcroot</tt> in
+function's prologue.</p>
+
+<p>The first argument <b>must</b> be a value referring to an alloca instruction
+or a bitcast of an alloca. The second contains a pointer to metadata that
+should be associated with the pointer, and <b>must</b> be a constant or global
+value address. If your target collector uses tags, use a null pointer for
+metadata.</p>
+
+<p>The <tt>%metadata</tt> argument can be used to avoid requiring heap objects
+to have 'isa' pointers or tag bits. [<a href="#appel89">Appel89</a>, <a
+href="#goldberg91">Goldberg91</a>, <a href="#tolmach94">Tolmach94</a>] If
+specified, its value will be tracked along with the location of the pointer in
+the stack frame.</p>
+
+<p>Consider the following fragment of Java code:</p>
+
+<pre class="doc_code">
+       {
+         Object X;   // A null-initialized reference to an object
+         ...
+       }
+</pre>
+
+<p>This block (which may be located in the middle of a function or in a loop
+nest), could be compiled to this LLVM code:</p>
+
+<pre class="doc_code">
+Entry:
+   ;; In the entry block for the function, allocate the
+   ;; stack space for X, which is an LLVM pointer.
+   %X = alloca %Object*
+   
+   ;; Tell LLVM that the stack space is a stack root.
+   ;; Java has type-tags on objects, so we pass null as metadata.
+   %tmp = bitcast %Object** %X to i8**
+   call void @llvm.gcroot(i8** %tmp, i8* null)
+   ...
+
+   ;; "CodeBlock" is the block corresponding to the start
+   ;;  of the scope above.
+CodeBlock:
+   ;; Java null-initializes pointers.
+   store %Object* null, %Object** %X
+
+   ...
+
+   ;; As the pointer goes out of scope, store a null value into
+   ;; it, to indicate that the value is no longer live.
+   store %Object* null, %Object** %X
+   ...
+</pre>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="barriers">Reading and writing references in the heap</a>
+</h3>
+
+<div>
+
+<p>Some collectors need to be informed when the mutator (the program that needs
+garbage collection) either reads a pointer from or writes a pointer to a field
+of a heap object. The code fragments inserted at these points are called
+<em>read barriers</em> and <em>write barriers</em>, respectively. The amount of
+code that needs to be executed is usually quite small and not on the critical
+path of any computation, so the overall performance impact of the barrier is
+tolerable.</p>
+
+<p>Barriers often require access to the <em>object pointer</em> rather than the
+<em>derived pointer</em> (which is a pointer to the field within the
+object). Accordingly, these intrinsics take both pointers as separate arguments
+for completeness. In this snippet, <tt>%object</tt> is the object pointer, and 
+<tt>%derived</tt> is the derived pointer:</p>
+
+<blockquote><pre>
+    ;; An array type.
+    %class.Array = type { %class.Object, i32, [0 x %class.Object*] }
+    ...
+
+    ;; Load the object pointer from a gcroot.
+    %object = load %class.Array** %object_addr
+
+    ;; Compute the derived pointer.
+    %derived = getelementptr %object, i32 0, i32 2, i32 %n</pre></blockquote>
+
+<p>LLVM does not enforce this relationship between the object and derived
+pointer (although a <a href="#plugin">plugin</a> might). However, it would be
+an unusual collector that violated it.</p>
+
+<p>The use of these intrinsics is naturally optional if the target GC does
+require the corresponding barrier. Such a GC plugin will replace the intrinsic
+calls with the corresponding <tt>load</tt> or <tt>store</tt> instruction if they
+are used.</p>
+
+<!-- ======================================================================= -->
+<h4>
+  <a name="gcwrite">Write barrier: <tt>llvm.gcwrite</tt></a>
+</h4>
+
+<div>
+
+<div class="doc_code"><tt>
+void @llvm.gcwrite(i8* %value, i8* %object, i8** %derived)
+</tt></div>
+
+<p>For write barriers, LLVM provides the <tt>llvm.gcwrite</tt> intrinsic
+function. It has exactly the same semantics as a non-volatile <tt>store</tt> to
+the derived pointer (the third argument). The exact code generated is specified
+by a <a href="#plugin">compiler plugin</a>.</p>
+
+<p>Many important algorithms require write barriers, including generational
+and concurrent collectors. Additionally, write barriers could be used to
+implement reference counting.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h4>
+  <a name="gcread">Read barrier: <tt>llvm.gcread</tt></a>
+</h4>
+
+<div>
+
+<div class="doc_code"><tt>
+i8* @llvm.gcread(i8* %object, i8** %derived)<br>
+</tt></div>
+
+<p>For read barriers, LLVM provides the <tt>llvm.gcread</tt> intrinsic function.
+It has exactly the same semantics as a non-volatile <tt>load</tt> from the
+derived pointer (the second argument). The exact code generated is specified by
+a <a href="#plugin">compiler plugin</a>.</p>
+
+<p>Read barriers are needed by fewer algorithms than write barriers, and may
+have a greater performance impact since pointer reads are more frequent than
+writes.</p>
+
+</div>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+  <a name="plugin">Implementing a collector plugin</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>User code specifies which GC code generation to use with the <tt>gc</tt>
+function attribute or, equivalently, with the <tt>setGC</tt> method of
+<tt>Function</tt>.</p>
+
+<p>To implement a GC plugin, it is necessary to subclass
+<tt>llvm::GCStrategy</tt>, which can be accomplished in a few lines of
+boilerplate code. LLVM's infrastructure provides access to several important
+algorithms. For an uncontroversial collector, all that remains may be to
+compile LLVM's computed stack map to assembly code (using the binary
+representation expected by the runtime library). This can be accomplished in
+about 100 lines of code.</p>
+
+<p>This is not the appropriate place to implement a garbage collected heap or a
+garbage collector itself. That code should exist in the language's runtime
+library. The compiler plugin is responsible for generating code which
+conforms to the binary interface defined by library, most essentially the
+<a href="#stack-map">stack map</a>.</p>
+
+<p>To subclass <tt>llvm::GCStrategy</tt> and register it with the compiler:</p>
+
+<blockquote><pre>// lib/MyGC/MyGC.cpp - Example LLVM GC plugin
+
+#include "llvm/CodeGen/GCStrategy.h"
+#include "llvm/CodeGen/GCMetadata.h"
+#include "llvm/Support/Compiler.h"
+
+using namespace llvm;
+
+namespace {
+  class LLVM_LIBRARY_VISIBILITY MyGC : public GCStrategy {
+  public:
+    MyGC() {}
+  };
+  
+  GCRegistry::Add<MyGC>
+  X("mygc", "My bespoke garbage collector.");
+}</pre></blockquote>
+
+<p>This boilerplate collector does nothing. More specifically:</p>
+
+<ul>
+  <li><tt>llvm.gcread</tt> calls are replaced with the corresponding
+      <tt>load</tt> instruction.</li>
+  <li><tt>llvm.gcwrite</tt> calls are replaced with the corresponding
+      <tt>store</tt> instruction.</li>
+  <li>No safe points are added to the code.</li>
+  <li>The stack map is not compiled into the executable.</li>
+</ul>
+
+<p>Using the LLVM makefiles (like the <a
+href="http://llvm.org/viewvc/llvm-project/llvm/trunk/projects/sample/">sample
+project</a>), this code can be compiled as a plugin using a simple
+makefile:</p>
+
+<blockquote><pre
+># lib/MyGC/Makefile
+
+LEVEL := ../..
+LIBRARYNAME = <var>MyGC</var>
+LOADABLE_MODULE = 1
+
+include $(LEVEL)/Makefile.common</pre></blockquote>
+
+<p>Once the plugin is compiled, code using it may be compiled using <tt>llc
+-load=<var>MyGC.so</var></tt> (though <var>MyGC.so</var> may have some other
+platform-specific extension):</p>
+
+<blockquote><pre
+>$ cat sample.ll
+define void @f() gc "mygc" {
+entry:
+        ret void
+}
+$ llvm-as < sample.ll | llc -load=MyGC.so</pre></blockquote>
+
+<p>It is also possible to statically link the collector plugin into tools, such
+as a language-specific compiler front-end.</p>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="collector-algos">Overview of available features</a>
+</h3>
+
+<div>
+
+<p><tt>GCStrategy</tt> provides a range of features through which a plugin
+may do useful work. Some of these are callbacks, some are algorithms that can
+be enabled, disabled, or customized. This matrix summarizes the supported (and
+planned) features and correlates them with the collection techniques which
+typically require them.</p>
+
+<table>
+  <tr>
+    <th>Algorithm</th>
+    <th>Done</th>
+    <th>shadow stack</th>
+    <th>refcount</th>
+    <th>mark-sweep</th>
+    <th>copying</th>
+    <th>incremental</th>
+    <th>threaded</th>
+    <th>concurrent</th>
+  </tr>
+  <tr>
+    <th class="rowhead"><a href="#stack-map">stack map</a></th>
+    <td>✔</td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr>
+    <th class="rowhead"><a href="#init-roots">initialize roots</a></th>
+    <td>✔</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr class="doc_warning">
+    <th class="rowhead">derived pointers</th>
+    <td>NO</td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td>✘*</td>
+    <td>✘*</td>
+  </tr>
+  <tr>
+    <th class="rowhead"><em><a href="#custom">custom lowering</a></em></th>
+    <td>✔</td>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+  </tr>
+  <tr>
+    <th class="rowhead indent">gcroot</th>
+    <td>✔</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+  </tr>
+  <tr>
+    <th class="rowhead indent">gcwrite</th>
+    <td>✔</td>
+    <td></td>
+    <td>✘</td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td></td>
+    <td>✘</td>
+  </tr>
+  <tr>
+    <th class="rowhead indent">gcread</th>
+    <td>✔</td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+  </tr>
+  <tr>
+    <th class="rowhead"><em><a href="#safe-points">safe points</a></em></th>
+    <td></td>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+  </tr>
+  <tr>
+    <th class="rowhead indent">in calls</th>
+    <td>✔</td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr>
+    <th class="rowhead indent">before calls</th>
+    <td>✔</td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr class="doc_warning">
+    <th class="rowhead indent">for loops</th>
+    <td>NO</td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr>
+    <th class="rowhead indent">before escape</th>
+    <td>✔</td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr class="doc_warning">
+    <th class="rowhead">emit code at safe points</th>
+    <td>NO</td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr>
+    <th class="rowhead"><em>output</em></th>
+    <td></td>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+    <th></th>
+  </tr>
+  <tr>
+    <th class="rowhead indent"><a href="#assembly">assembly</a></th>
+    <td>✔</td>
+    <td></td>
+    <td></td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+    <td>✘</td>
+  </tr>
+  <tr class="doc_warning">
+    <th class="rowhead indent">JIT</th>
+    <td>NO</td>
+    <td></td>
+    <td></td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+  </tr>
+  <tr class="doc_warning">
+    <th class="rowhead indent">obj</th>
+    <td>NO</td>
+    <td></td>
+    <td></td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+  </tr>
+  <tr class="doc_warning">
+    <th class="rowhead">live analysis</th>
+    <td>NO</td>
+    <td></td>
+    <td></td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+  </tr>
+  <tr class="doc_warning">
+    <th class="rowhead">register map</th>
+    <td>NO</td>
+    <td></td>
+    <td></td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+    <td class="optl">✘</td>
+  </tr>
+  <tr>
+    <td colspan="10">
+      <div><span class="doc_warning">*</span> Derived pointers only pose a
+           hazard to copying collectors.</div>
+      <div><span class="optl">✘</span> in gray denotes a feature which
+           could be utilized if available.</div>
+    </td>
+  </tr>
+</table>
+
+<p>To be clear, the collection techniques above are defined as:</p>
+
+<dl>
+  <dt>Shadow Stack</dt>
+  <dd>The mutator carefully maintains a linked list of stack roots.</dd>
+  <dt>Reference Counting</dt>
+  <dd>The mutator maintains a reference count for each object and frees an
+      object when its count falls to zero.</dd>
+  <dt>Mark-Sweep</dt>
+  <dd>When the heap is exhausted, the collector marks reachable objects starting
+      from the roots, then deallocates unreachable objects in a sweep
+      phase.</dd>
+  <dt>Copying</dt>
+  <dd>As reachability analysis proceeds, the collector copies objects from one
+      heap area to another, compacting them in the process. Copying collectors
+      enable highly efficient "bump pointer" allocation and can improve locality
+      of reference.</dd>
+  <dt>Incremental</dt>
+  <dd>(Including generational collectors.) Incremental collectors generally have
+      all the properties of a copying collector (regardless of whether the
+      mature heap is compacting), but bring the added complexity of requiring
+      write barriers.</dd>
+  <dt>Threaded</dt>
+  <dd>Denotes a multithreaded mutator; the collector must still stop the mutator
+      ("stop the world") before beginning reachability analysis. Stopping a
+      multithreaded mutator is a complicated problem. It generally requires
+      highly platform specific code in the runtime, and the production of
+      carefully designed machine code at safe points.</dd>
+  <dt>Concurrent</dt>
+  <dd>In this technique, the mutator and the collector run concurrently, with
+      the goal of eliminating pause times. In a <em>cooperative</em> collector,
+      the mutator further aids with collection should a pause occur, allowing
+      collection to take advantage of multiprocessor hosts. The "stop the world"
+      problem of threaded collectors is generally still present to a limited
+      extent. Sophisticated marking algorithms are necessary. Read barriers may
+      be necessary.</dd>
+</dl>
+
+<p>As the matrix indicates, LLVM's garbage collection infrastructure is already
+suitable for a wide variety of collectors, but does not currently extend to
+multithreaded programs. This will be added in the future as there is
+interest.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="stack-map">Computing stack maps</a>
+</h3>
+
+<div>
+
+<p>LLVM automatically computes a stack map. One of the most important features
+of a <tt>GCStrategy</tt> is to compile this information into the executable in
+the binary representation expected by the runtime library.</p>
+
+<p>The stack map consists of the location and identity of each GC root in the
+each function in the module. For each root:</p>
+
+<ul>
+  <li><tt>RootNum</tt>: The index of the root.</li>
+  <li><tt>StackOffset</tt>: The offset of the object relative to the frame
+      pointer.</li>
+  <li><tt>RootMetadata</tt>: The value passed as the <tt>%metadata</tt>
+      parameter to the <a href="#gcroot"><tt>@llvm.gcroot</tt></a> intrinsic.</li>
+</ul>
+
+<p>Also, for the function as a whole:</p>
+
+<ul>
+  <li><tt>getFrameSize()</tt>: The overall size of the function's initial
+      stack frame, not accounting for any dynamic allocation.</li>
+  <li><tt>roots_size()</tt>: The count of roots in the function.</li>
+</ul>
+
+<p>To access the stack map, use <tt>GCFunctionMetadata::roots_begin()</tt> and
+-<tt>end()</tt> from the <tt><a
+href="#assembly">GCMetadataPrinter</a></tt>:</p>
+
+<blockquote><pre
+>for (iterator I = begin(), E = end(); I != E; ++I) {
+  GCFunctionInfo *FI = *I;
+  unsigned FrameSize = FI->getFrameSize();
+  size_t RootCount = FI->roots_size();
+
+  for (GCFunctionInfo::roots_iterator RI = FI->roots_begin(),
+                                      RE = FI->roots_end();
+                                      RI != RE; ++RI) {
+    int RootNum = RI->Num;
+    int RootStackOffset = RI->StackOffset;
+    Constant *RootMetadata = RI->Metadata;
+  }
+}</pre></blockquote>
+
+<p>If the <tt>llvm.gcroot</tt> intrinsic is eliminated before code generation by
+a custom lowering pass, LLVM will compute an empty stack map. This may be useful
+for collector plugins which implement reference counting or a shadow stack.</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="init-roots">Initializing roots to null: <tt>InitRoots</tt></a>
+</h3>
+
+<div>
+
+<blockquote><pre
+>MyGC::MyGC() {
+  InitRoots = true;
+}</pre></blockquote>
+
+<p>When set, LLVM will automatically initialize each root to <tt>null</tt> upon
+entry to the function. This prevents the GC's sweep phase from visiting
+uninitialized pointers, which will almost certainly cause it to crash. This
+initialization occurs before custom lowering, so the two may be used
+together.</p>
+
+<p>Since LLVM does not yet compute liveness information, there is no means of
+distinguishing an uninitialized stack root from an initialized one. Therefore,
+this feature should be used by all GC plugins. It is enabled by default.</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="custom">Custom lowering of intrinsics: <tt>CustomRoots</tt>, 
+    <tt>CustomReadBarriers</tt>, and <tt>CustomWriteBarriers</tt></a>
+</h3>
+
+<div>
+
+<p>For GCs which use barriers or unusual treatment of stack roots, these
+flags allow the collector to perform arbitrary transformations of the LLVM
+IR:</p>
+
+<blockquote><pre
+>class MyGC : public GCStrategy {
+public:
+  MyGC() {
+    CustomRoots = true;
+    CustomReadBarriers = true;
+    CustomWriteBarriers = true;
+  }
+  
+  virtual bool initializeCustomLowering(Module &M);
+  virtual bool performCustomLowering(Function &F);
+};</pre></blockquote>
+
+<p>If any of these flags are set, then LLVM suppresses its default lowering for
+the corresponding intrinsics and instead calls
+<tt>performCustomLowering</tt>.</p>
+
+<p>LLVM's default action for each intrinsic is as follows:</p>
+
+<ul>
+  <li><tt>llvm.gcroot</tt>: Leave it alone. The code generator must see it
+                            or the stack map will not be computed.</li>
+  <li><tt>llvm.gcread</tt>: Substitute a <tt>load</tt> instruction.</li>
+  <li><tt>llvm.gcwrite</tt>: Substitute a <tt>store</tt> instruction.</li>
+</ul>
+
+<p>If <tt>CustomReadBarriers</tt> or <tt>CustomWriteBarriers</tt> are specified,
+then <tt>performCustomLowering</tt> <strong>must</strong> eliminate the
+corresponding barriers.</p>
+
+<p><tt>performCustomLowering</tt> must comply with the same restrictions as <a
+href="WritingAnLLVMPass.html#runOnFunction"><tt
+>FunctionPass::runOnFunction</tt></a>.
+Likewise, <tt>initializeCustomLowering</tt> has the same semantics as <a
+href="WritingAnLLVMPass.html#doInitialization_mod"><tt
+>Pass::doInitialization(Module&)</tt></a>.</p>
+
+<p>The following can be used as a template:</p>
+
+<blockquote><pre
+>#include "llvm/Module.h"
+#include "llvm/IntrinsicInst.h"
+
+bool MyGC::initializeCustomLowering(Module &M) {
+  return false;
+}
+
+bool MyGC::performCustomLowering(Function &F) {
+  bool MadeChange = false;
+  
+  for (Function::iterator BB = F.begin(), E = F.end(); BB != E; ++BB)
+    for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; )
+      if (IntrinsicInst *CI = dyn_cast<IntrinsicInst>(II++))
+        if (Function *F = CI->getCalledFunction())
+          switch (F->getIntrinsicID()) {
+          case Intrinsic::gcwrite:
+            // Handle llvm.gcwrite.
+            CI->eraseFromParent();
+            MadeChange = true;
+            break;
+          case Intrinsic::gcread:
+            // Handle llvm.gcread.
+            CI->eraseFromParent();
+            MadeChange = true;
+            break;
+          case Intrinsic::gcroot:
+            // Handle llvm.gcroot.
+            CI->eraseFromParent();
+            MadeChange = true;
+            break;
+          }
+  
+  return MadeChange;
+}</pre></blockquote>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="safe-points">Generating safe points: <tt>NeededSafePoints</tt></a>
+</h3>
+
+<div>
+
+<p>LLVM can compute four kinds of safe points:</p>
+
+<blockquote><pre
+>namespace GC {
+  /// PointKind - The type of a collector-safe point.
+  /// 
+  enum PointKind {
+    Loop,    //< Instr is a loop (backwards branch).
+    Return,  //< Instr is a return instruction.
+    PreCall, //< Instr is a call instruction.
+    PostCall //< Instr is the return address of a call.
+  };
+}</pre></blockquote>
+
+<p>A collector can request any combination of the four by setting the 
+<tt>NeededSafePoints</tt> mask:</p>
+
+<blockquote><pre
+>MyGC::MyGC() {
+  NeededSafePoints = 1 << GC::Loop
+                   | 1 << GC::Return
+                   | 1 << GC::PreCall
+                   | 1 << GC::PostCall;
+}</pre></blockquote>
+
+<p>It can then use the following routines to access safe points.</p>
+
+<blockquote><pre
+>for (iterator I = begin(), E = end(); I != E; ++I) {
+  GCFunctionInfo *MD = *I;
+  size_t PointCount = MD->size();
+
+  for (GCFunctionInfo::iterator PI = MD->begin(),
+                                PE = MD->end(); PI != PE; ++PI) {
+    GC::PointKind PointKind = PI->Kind;
+    unsigned PointNum = PI->Num;
+  }
+}
+</pre></blockquote>
+
+<p>Almost every collector requires <tt>PostCall</tt> safe points, since these
+correspond to the moments when the function is suspended during a call to a
+subroutine.</p>
+
+<p>Threaded programs generally require <tt>Loop</tt> safe points to guarantee
+that the application will reach a safe point within a bounded amount of time,
+even if it is executing a long-running loop which contains no function
+calls.</p>
+
+<p>Threaded collectors may also require <tt>Return</tt> and <tt>PreCall</tt>
+safe points to implement "stop the world" techniques using self-modifying code,
+where it is important that the program not exit the function without reaching a
+safe point (because only the topmost function has been patched).</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+  <a name="assembly">Emitting assembly code: <tt>GCMetadataPrinter</tt></a>
+</h3>
+
+<div>
+
+<p>LLVM allows a plugin to print arbitrary assembly code before and after the
+rest of a module's assembly code. At the end of the module, the GC can compile
+the LLVM stack map into assembly code. (At the beginning, this information is not
+yet computed.)</p>
+
+<p>Since AsmWriter and CodeGen are separate components of LLVM, a separate
+abstract base class and registry is provided for printing assembly code, the
+<tt>GCMetadaPrinter</tt> and <tt>GCMetadataPrinterRegistry</tt>. The AsmWriter
+will look for such a subclass if the <tt>GCStrategy</tt> sets
+<tt>UsesMetadata</tt>:</p>
+
+<blockquote><pre
+>MyGC::MyGC() {
+  UsesMetadata = true;
+}</pre></blockquote>
+
+<p>This separation allows JIT-only clients to be smaller.</p>
+
+<p>Note that LLVM does not currently have analogous APIs to support code
+generation in the JIT, nor using the object writers.</p>
+
+<blockquote><pre
+>// lib/MyGC/MyGCPrinter.cpp - Example LLVM GC printer
+
+#include "llvm/CodeGen/GCMetadataPrinter.h"
+#include "llvm/Support/Compiler.h"
+
+using namespace llvm;
+
+namespace {
+  class LLVM_LIBRARY_VISIBILITY MyGCPrinter : public GCMetadataPrinter {
+  public:
+    virtual void beginAssembly(std::ostream &OS, AsmPrinter &AP,
+                               const TargetAsmInfo &TAI);
+  
+    virtual void finishAssembly(std::ostream &OS, AsmPrinter &AP,
+                                const TargetAsmInfo &TAI);
+  };
+  
+  GCMetadataPrinterRegistry::Add<MyGCPrinter>
+  X("mygc", "My bespoke garbage collector.");
+}</pre></blockquote>
+
+<p>The collector should use <tt>AsmPrinter</tt> and <tt>TargetAsmInfo</tt> to
+print portable assembly code to the <tt>std::ostream</tt>. The collector itself
+contains the stack map for the entire module, and may access the
+<tt>GCFunctionInfo</tt> using its own <tt>begin()</tt> and <tt>end()</tt>
+methods. Here's a realistic example:</p>
+
+<blockquote><pre
+>#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/Function.h"
+#include "llvm/Target/TargetMachine.h"
+#include "llvm/DataLayout.h"
+#include "llvm/Target/TargetAsmInfo.h"
+
+void MyGCPrinter::beginAssembly(std::ostream &OS, AsmPrinter &AP,
+                                const TargetAsmInfo &TAI) {
+  // Nothing to do.
+}
+
+void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP,
+                                 const TargetAsmInfo &TAI) {
+  // Set up for emitting addresses.
+  const char *AddressDirective;
+  int AddressAlignLog;
+  if (AP.TM.getDataLayout()->getPointerSize() == sizeof(int32_t)) {
+    AddressDirective = TAI.getData32bitsDirective();
+    AddressAlignLog = 2;
+  } else {
+    AddressDirective = TAI.getData64bitsDirective();
+    AddressAlignLog = 3;
+  }
+  
+  // Put this in the data section.
+  AP.SwitchToDataSection(TAI.getDataSection());
+  
+  // For each function...
+  for (iterator FI = begin(), FE = end(); FI != FE; ++FI) {
+    GCFunctionInfo &MD = **FI;
+    
+    // Emit this data structure:
+    // 
+    // struct {
+    //   int32_t PointCount;
+    //   struct {
+    //     void *SafePointAddress;
+    //     int32_t LiveCount;
+    //     int32_t LiveOffsets[LiveCount];
+    //   } Points[PointCount];
+    // } __gcmap_<FUNCTIONNAME>;
+    
+    // Align to address width.
+    AP.EmitAlignment(AddressAlignLog);
+    
+    // Emit the symbol by which the stack map entry can be found.
+    std::string Symbol;
+    Symbol += TAI.getGlobalPrefix();
+    Symbol += "__gcmap_";
+    Symbol += MD.getFunction().getName();
+    if (const char *GlobalDirective = TAI.getGlobalDirective())
+      OS << GlobalDirective << Symbol << "\n";
+    OS << TAI.getGlobalPrefix() << Symbol << ":\n";
+    
+    // Emit PointCount.
+    AP.EmitInt32(MD.size());
+    AP.EOL("safe point count");
+    
+    // And each safe point...
+    for (GCFunctionInfo::iterator PI = MD.begin(),
+                                     PE = MD.end(); PI != PE; ++PI) {
+      // Align to address width.
+      AP.EmitAlignment(AddressAlignLog);
+      
+      // Emit the address of the safe point.
+      OS << AddressDirective
+         << TAI.getPrivateGlobalPrefix() << "label" << PI->Num;
+      AP.EOL("safe point address");
+      
+      // Emit the stack frame size.
+      AP.EmitInt32(MD.getFrameSize());
+      AP.EOL("stack frame size");
+      
+      // Emit the number of live roots in the function.
+      AP.EmitInt32(MD.live_size(PI));
+      AP.EOL("live root count");
+      
+      // And for each live root...
+      for (GCFunctionInfo::live_iterator LI = MD.live_begin(PI),
+                                            LE = MD.live_end(PI);
+                                            LI != LE; ++LI) {
+        // Print its offset within the stack frame.
+        AP.EmitInt32(LI->StackOffset);
+        AP.EOL("stack offset");
+      }
+    }
+  }
+}
+</pre></blockquote>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+  <a name="references">References</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p><a name="appel89">[Appel89]</a> Runtime Tags Aren't Necessary. Andrew
+W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.</p>
+
+<p><a name="goldberg91">[Goldberg91]</a> Tag-free garbage collection for
+strongly typed programming languages. Benjamin Goldberg. ACM SIGPLAN
+PLDI'91.</p>
+
+<p><a name="tolmach94">[Tolmach94]</a> Tag-free garbage collection using
+explicit type parameters. Andrew Tolmach. Proceedings of the 1994 ACM
+conference on LISP and functional programming.</p>
+
+<p><a name="henderson02">[Henderson2002]</a> <a
+href="http://citeseer.ist.psu.edu/henderson02accurate.html">
+Accurate Garbage Collection in an Uncooperative Environment</a>.
+Fergus Henderson. International Symposium on Memory Management 2002.</p>
+
+</div>
+
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+  src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+  <a href="http://validator.w3.org/check/referer"><img
+  src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+  <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+  <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+  Last modified: $Date: 2012-10-08 11:39:34 -0500 (Mon, 08 Oct 2012) $
+</address>
+
+</body>
+</html>