Atmn Patel cbe95c4921 [LangRef] Define mustprogress attribute ... 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		2020-10-19 13:34:27 -04:00
..
llvm.vim	[LangRef] Define mustprogress attribute	2020-10-19 13:34:27 -04:00
tablegen.vim