3bd5f9ccfa
Gather operations that take four separate offsets are meant to allow for programmable, non-immediate values. This removes them from the immediate and range validations by giving the immediate versions their own opcodes For these intrinsics and loads, errors are generated when offsets are non-literal or out of range. These largely use the slightly altered validation paths that the sample intrinsics use. Reword error when texture access offsets are not immediates to be more all encompassing and grammatical. Incidentally remove duplicate shaders being used for the validation test from the old directory while identical copies in the validation directory went unused. Redirected validation test to the appropriate copies. This is consistent with the test shader re-org's stated intent Sample operations have a maximum of 3 args, but gather has a maximum of two since it always operates on 2D images. So gather operations only pass in two offset args to the offset validation, which resulted in an invalid access. Rather than adding a specialized condition to evade this, just iterate over the number of elements in the array. For sample it will be 3 and for gather 2 and it will still check for expected undefined args appropriately. For the offset legalization pass, the opcode is used to determine the start and end of the offset args Only produce the loop unroll suggestion when within a loop Base error line on call instruction instead of source of the offset Sort by location in source when possible and remove duplicates Adapt tests to verify and match these changes Fixes #2590 Fixes #2713 |
||
|---|---|---|
| .. | ||
| CommandGuide | ||
| Frontend | ||
| TableGen | ||
| _static | ||
| _templates | ||
| _themes/dxc-theme | ||
| AliasAnalysis.rst | ||
| Atomics.rst | ||
| BitCodeFormat.rst | ||
| BitSets.rst | ||
| BlockFrequencyTerminology.rst | ||
| BranchWeightMetadata.rst | ||
| CMake.rst | ||
| CMakeLists.txt | ||
| CodeGenerator.rst | ||
| CodingStandards.rst | ||
| CommandLine.rst | ||
| CoverageMappingFormat.rst | ||
| DXIL.rst | ||
| Dummy.html | ||
| DxcOnUnix.rst | ||
| ExceptionHandling.rst | ||
| ExtendingLLVM.rst | ||
| FaultMaps.rst | ||
| GetElementPtr.rst | ||
| HLSLChanges.rst | ||
| HowToSetUpLLVMStyleRTTI.rst | ||
| HowToUseAttributes.rst | ||
| HowToUseInstrMappings.rst | ||
| InAlloca.rst | ||
| LLVMBuild.rst | ||
| LLVMBuild.txt | ||
| LangRef.rst | ||
| Lexicon.rst | ||
| LibFuzzer.rst | ||
| LinkTimeOptimization.rst | ||
| Makefile.sphinx | ||
| MarkedUpDisassembly.rst | ||
| MergeFunctions.rst | ||
| Passes.rst | ||
| ProgrammersManual.rst | ||
| README.txt | ||
| SPIR-V.rst | ||
| SPIRV-Cookbook.rst | ||
| SourceLevelDebugging.rst | ||
| SourceLevelDebuggingHLSL.rst | ||
| SystemLibrary.rst | ||
| Vectorizers.rst | ||
| WritingAnLLVMBackend.rst | ||
| WritingAnLLVMPass.rst | ||
| YamlIO.rst | ||
| conf.py | ||
| index.rst | ||
| make.bat | ||
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 docs/
make -f Makefile.sphinx
$BROWSER _build/html/index.html
The mapping between reStructuredText files and generated documentation is
`docs/Foo.rst` <-> `_build/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/man/`.
cd docs/
make -f Makefile.sphinx man
man -l _build/man/FileCheck.1
The correspondence between .rst files and man pages is
`docs/CommandGuide/Foo.rst` <-> `_build/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 reachibility of external links in the documentation can be checked by
running:
cd docs/
make -f Makefile.sphinx linkcheck