mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +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 |
||
|---|---|---|
| .. | ||
| ftdetect | ||
| ftplugin | ||
| indent | ||
| syntax | ||
| README | ||
| vimrc | ||
-*- llvm/utils/vim/README -*-
This directory contains settings for the vim editor to work on llvm *.ll and
tablegen *.td files. It comes with filetype detection rules in the (ftdetect),
syntax highlighting (syntax), some minimal sensible default settings (ftplugin)
and indentation plugins (indent).
To install copy all subdirectories to your $HOME/.vim or if you prefer create
symlinks to the files here. Do not copy the vimrc file here it is only meant as
an inspiration and starting point for those working on llvm c++ code.
Note: If you notice missing or incorrect syntax highlighting, please contact
<llvm-bugs [at] lists.llvm.org>; if you wish to provide a patch to improve the
functionality, it will be most appreciated. Thank you.
If you find yourself working with LLVM Makefiles often, but you don't get syntax
highlighting (because the files have names such as Makefile.rules or
TEST.nightly.Makefile), add the following to your ~/.vimrc:
" LLVM Makefile highlighting mode
augroup filetype
au! BufRead,BufNewFile *Makefile* set filetype=make
augroup END