forked from OSchip/llvm-project
21521891a2
This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336 |
||
---|---|---|
.. | ||
CommandGuide | ||
Frontend | ||
HistoricalNotes | ||
TableGen | ||
_ocamldoc | ||
_static | ||
_templates | ||
_themes/llvm-theme | ||
tutorial | ||
AMDGPUUsage.rst | ||
ARM-BE-bitcastfail.png | ||
ARM-BE-bitcastsuccess.png | ||
ARM-BE-ld1.png | ||
ARM-BE-ldr.png | ||
AdvancedBuilds.rst | ||
AliasAnalysis.rst | ||
Atomics.rst | ||
BigEndianNEON.rst | ||
BitCodeFormat.rst | ||
BitSets.rst | ||
BlockFrequencyTerminology.rst | ||
BranchWeightMetadata.rst | ||
Bugpoint.rst | ||
CMake.rst | ||
CMakeLists.txt | ||
CMakePrimer.rst | ||
CodeGenerator.rst | ||
CodingStandards.rst | ||
CommandLine.rst | ||
CompileCudaWithLLVM.rst | ||
CompilerWriterInfo.rst | ||
CoverageMappingFormat.rst | ||
DebuggingJITedCode.rst | ||
DeveloperPolicy.rst | ||
Dummy.html | ||
ExceptionHandling.rst | ||
ExtendedIntegerResults.txt | ||
ExtendingLLVM.rst | ||
Extensions.rst | ||
FAQ.rst | ||
FaultMaps.rst | ||
GarbageCollection.rst | ||
GetElementPtr.rst | ||
GettingStarted.rst | ||
GettingStartedVS.rst | ||
GoldPlugin.rst | ||
HowToAddABuilder.rst | ||
HowToBuildOnARM.rst | ||
HowToCrossCompileLLVM.rst | ||
HowToReleaseLLVM.rst | ||
HowToSetUpLLVMStyleRTTI.rst | ||
HowToSubmitABug.rst | ||
HowToUseAttributes.rst | ||
HowToUseInstrMappings.rst | ||
InAlloca.rst | ||
LLVMBuild.rst | ||
LLVMBuild.txt | ||
LangRef.rst | ||
Lexicon.rst | ||
LibFuzzer.rst | ||
LinkTimeOptimization.rst | ||
MCJIT-creation.png | ||
MCJIT-dyld-load.png | ||
MCJIT-engine-builder.png | ||
MCJIT-load-object.png | ||
MCJIT-load.png | ||
MCJIT-resolve-relocations.png | ||
MCJITDesignAndImplementation.rst | ||
MIRLangRef.rst | ||
Makefile.sphinx | ||
MarkedUpDisassembly.rst | ||
MergeFunctions.rst | ||
NVPTXUsage.rst | ||
Packaging.rst | ||
Passes.rst | ||
Phabricator.rst | ||
ProgrammersManual.rst | ||
Projects.rst | ||
README.txt | ||
ReleaseNotes.rst | ||
ReleaseProcess.rst | ||
ScudoHardenedAllocator.rst | ||
SegmentedStacks.rst | ||
SourceLevelDebugging.rst | ||
SphinxQuickstartTemplate.rst | ||
StackMaps.rst | ||
Statepoints.rst | ||
SystemLibrary.rst | ||
TableGenFundamentals.rst | ||
TestSuiteMakefileGuide.rst | ||
TestingGuide.rst | ||
Vectorizers.rst | ||
WritingAnLLVMBackend.rst | ||
WritingAnLLVMPass.rst | ||
YamlIO.rst | ||
conf.py | ||
doxygen-mainpage.dox | ||
doxygen.cfg.in | ||
gcc-loops.png | ||
index.rst | ||
linpack-pc.png | ||
make.bat | ||
re_format.7 | ||
yaml2obj.rst |
README.txt
LLVM Documentation ================== LLVM's documentation is written in reStructuredText, a lightweight plaintext markup language (file extension `.rst`). While the reStructuredText documentation should be quite readable in source form, it is mostly meant to be processed by the Sphinx documentation generation system to create HTML pages which are hosted on <http://llvm.org/docs/> and updated after every commit. Manpage output is also supported, see below. If you instead would like to generate and view the HTML locally, install Sphinx <http://sphinx-doc.org/> and then do: cd <build-dir> cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true <src-dir> make -j3 docs-llvm-html $BROWSER <build-dir>/docs//html/index.html The mapping between reStructuredText files and generated documentation is `docs/Foo.rst` <-> `<build-dir>/docs//html/Foo.html` <-> `http://llvm.org/docs/Foo.html`. If you are interested in writing new documentation, you will want to read `SphinxQuickstartTemplate.rst` which will get you writing documentation very fast and includes examples of the most important reStructuredText markup syntax. Manpage Output =============== Building the manpages is similar to building the HTML documentation. The primary difference is to use the `man` makefile target, instead of the default (which is `html`). Sphinx then produces the man pages in the directory `<build-dir>/docs/man/`. cd <build-dir> cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_MAN=true <src-dir> make -j3 docs-llvm-man man -l >build-dir>/docs/man/FileCheck.1 The correspondence between .rst files and man pages is `docs/CommandGuide/Foo.rst` <-> `<build-dir>/docs//man/Foo.1`. These .rst files are also included during HTML generation so they are also viewable online (as noted above) at e.g. `http://llvm.org/docs/CommandGuide/Foo.html`. Checking links ============== The reachability of external links in the documentation can be checked by running: cd docs/ make -f Makefile.sphinx linkcheck