mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 10:42:39 +01:00
cbe95c4921
LLVM IR currently assumes some form of forward progress. This form is not explicitly defined anywhere, and is the cause of miscompilations in most languages that are not C++11 or later. This implicit forward progress guarantee can not be opted out of on a function level nor on a loop level. Languages such as C (C11 and later), C++ (pre-C++11), and Rust have different forward progress requirements and this needs to be evident in the IR. Specifically, C11 and onwards (6.8.5, Paragraph 6) states that "An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of for statement) its expression-3, may be assumed by the implementation to terminate." C++11 and onwards does not have this assumption, and instead assumes that every thread must make progress as defined in [intro.progress] when it comes to scheduling. This was initially brought up in [0] as a bug, a solution was presented in [1] which is the current workaround, and the predecessor to this change was [2]. After defining a notion of forward progress for IR, there are two options to address this: 1) Set the default to assuming Forward Progress and provide an opt-out for functions and an opt-in for loops. 2) Set the default to not assuming Forward Progress and provide an opt-in for functions, and an opt-in for loops. Option 2) has been selected because only C++11 and onwards have a forward progress requirement and it makes sense for them to opt-into it via the defined `mustprogress` function attribute. The `mustprogress` function attribute indicates that the function is required to make forward progress as defined. This is sharply in contrast to the status quo where this is implicitly assumed. In addition, `willreturn` implies `mustprogress`. The background for why this definition was chosen is in [3] and for why the option was chosen is in [4] and the corresponding thread(s). The implementation is in D85393, the clang patch is in D86841, the LoopDeletion patch is in D86844, the Inliner patches are in D87180 and D87262, and there will be more incoming. [0] https://bugs.llvm.org/show_bug.cgi?id=965#c25 [1] https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html [2] https://reviews.llvm.org/D65718 [3] https://lists.llvm.org/pipermail/llvm-dev/2020-September/144919.html [4] https://lists.llvm.org/pipermail/llvm-dev/2020-September/145023.html Reviewed By: jdoerfert, efriedma, nikic Differential Revision: https://reviews.llvm.org/D86233 |
||
|---|---|---|
| .. | ||
| _ocamldoc | ||
| _static | ||
| _templates | ||
| _themes/llvm-theme | ||
| AMDGPU | ||
| CommandGuide | ||
| DependenceGraphs | ||
| Frontend | ||
| GlobalISel | ||
| HistoricalNotes | ||
| PDB | ||
| Proposals | ||
| TableGen | ||
| tutorial | ||
| AddingConstrainedIntrinsics.rst | ||
| AdvancedBuilds.rst | ||
| AliasAnalysis.rst | ||
| AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst | ||
| AMDGPUInstructionNotation.rst | ||
| AMDGPUInstructionSyntax.rst | ||
| AMDGPUModifierSyntax.rst | ||
| AMDGPUOperandSyntax.rst | ||
| AMDGPUUsage.rst | ||
| ARM-BE-bitcastfail.png | ||
| ARM-BE-bitcastsuccess.png | ||
| ARM-BE-ld1.png | ||
| ARM-BE-ldr.png | ||
| Atomics.rst | ||
| Benchmarking.rst | ||
| BigEndianNEON.rst | ||
| BitCodeFormat.rst | ||
| BlockFrequencyTerminology.rst | ||
| BranchWeightMetadata.rst | ||
| BugLifeCycle.rst | ||
| Bugpoint.rst | ||
| BugpointRedesign.md | ||
| BuildingADistribution.rst | ||
| CFIVerify.rst | ||
| CMake.rst | ||
| CMakeLists.txt | ||
| CMakePrimer.rst | ||
| CodeGenerator.rst | ||
| CodeOfConduct.rst | ||
| CodeReview.rst | ||
| CodingStandards.rst | ||
| CommandLine.rst | ||
| CompileCudaWithLLVM.rst | ||
| CompilerWriterInfo.rst | ||
| conf.py | ||
| Contributing.rst | ||
| Coroutines.rst | ||
| CoverageMappingFormat.rst | ||
| DebuggingJITedCode.rst | ||
| DeveloperPolicy.rst | ||
| Docker.rst | ||
| doxygen-mainpage.dox | ||
| doxygen.cfg.in | ||
| ExceptionHandling.rst | ||
| ExtendedIntegerResults.txt | ||
| ExtendingLLVM.rst | ||
| Extensions.rst | ||
| FAQ.rst | ||
| FaultMaps.rst | ||
| FuzzingLLVM.rst | ||
| GarbageCollection.rst | ||
| gcc-loops.png | ||
| GetElementPtr.rst | ||
| GettingInvolved.rst | ||
| GettingStarted.rst | ||
| GettingStartedTutorials.rst | ||
| GettingStartedVS.rst | ||
| GitBisecting.rst | ||
| GoldPlugin.rst | ||
| GwpAsan.rst | ||
| HowToAddABuilder.rst | ||
| HowToBuildOnARM.rst | ||
| HowToBuildWithPGO.rst | ||
| HowToCrossCompileBuiltinsOnArm.rst | ||
| HowToCrossCompileLLVM.rst | ||
| HowToReleaseLLVM.rst | ||
| HowToSetUpLLVMStyleRTTI.rst | ||
| HowToSubmitABug.rst | ||
| HowToUpdateDebugInfo.rst | ||
| HowToUseAttributes.rst | ||
| HowToUseInstrMappings.rst | ||
| InAlloca.rst | ||
| index.rst | ||
| LangRef.rst | ||
| Lexicon.rst | ||
| LibFuzzer.rst | ||
| LinkTimeOptimization.rst | ||
| linpack-pc.png | ||
| llvm-objdump.1 | ||
| LLVMBuild.rst | ||
| LLVMBuild.txt | ||
| loop-guard.svg | ||
| loop-irreducible.svg | ||
| loop-merge.svg | ||
| loop-nested.svg | ||
| loop-nonmaximal.svg | ||
| loop-separate.svg | ||
| loop-single.svg | ||
| loop-terminology-guarded-loop.png | ||
| loop-terminology-initial-loop.png | ||
| loop-terminology-rotated-loop.png | ||
| loop-terminology.svg | ||
| LoopTerminology.rst | ||
| make.bat | ||
| Makefile.sphinx | ||
| MarkdownQuickstartTemplate.md | ||
| MarkedUpDisassembly.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 | ||
| MeetupGuidelines.rst | ||
| MemorySSA.rst | ||
| MemTagSanitizer.rst | ||
| MergeFunctions.rst | ||
| MIRLangRef.rst | ||
| NVPTXUsage.rst | ||
| OptBisect.rst | ||
| ORCv2.rst | ||
| Packaging.rst | ||
| Passes.rst | ||
| Phabricator.rst | ||
| ProgrammersManual.rst | ||
| Projects.rst | ||
| re_format.7 | ||
| README.txt | ||
| Reference.rst | ||
| ReleaseNotes.rst | ||
| ReleaseProcess.rst | ||
| Remarks.rst | ||
| ReportingGuide.rst | ||
| ScudoHardenedAllocator.rst | ||
| Security.rst | ||
| SegmentedStacks.rst | ||
| SourceLevelDebugging.rst | ||
| speculative_load_hardening_microbenchmarks.png | ||
| SpeculativeLoadHardening.md | ||
| SphinxQuickstartTemplate.rst | ||
| StackMaps.rst | ||
| StackSafetyAnalysis.rst | ||
| Statepoints.rst | ||
| SupportLibrary.rst | ||
| SystemLibrary.rst | ||
| TableGenFundamentals.rst | ||
| TestingGuide.rst | ||
| TestSuiteGuide.md | ||
| TestSuiteMakefileGuide.rst | ||
| TransformMetadata.rst | ||
| TypeMetadata.rst | ||
| UserGuides.rst | ||
| Vectorizers.rst | ||
| WritingAnLLVMBackend.rst | ||
| WritingAnLLVMNewPMPass.rst | ||
| WritingAnLLVMPass.rst | ||
| XRay.rst | ||
| XRayExample.rst | ||
| XRayFDRFormat.rst | ||
| yaml2obj.rst | ||
| YamlIO.rst | ||
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 <https://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` <-> `https://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.
`https://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
Doxygen page Output
==============
Install doxygen <http://www.stack.nl/~dimitri/doxygen/download.html> and dot2tex <https://dot2tex.readthedocs.io/en/latest>.
cd <build-dir>
cmake -DLLVM_ENABLE_DOXYGEN=On <llvm-top-src-dir>
make doxygen-llvm # for LLVM docs
make doxygen-clang # for clang docs
It will generate html in
<build-dir>/docs/doxygen/html # for LLVM docs
<build-dir>/tools/clang/docs/doxygen/html # for clang docs