- User Since
- Feb 1 2019, 9:58 AM (90 w, 4 d)
Sep 4 2020
Shouldn't it be "maynotprogress" (or "maybenoprogress" or so)? *Every* function *may* progress, but only those with this marker are also allowed to not "make progress".
Changed name from noprogress to mayprogress for clarity.
Aug 28 2020
I don't look at it as added or removed, for me it is a boolean flag, with a default that requires progress. It is more like nobuiltin, noduplicate, nomerge, returns_twice, .... The difference is that I don't see this being deduced. It is just a description of the input semantics, not a property we derive from the code (to describe the code). Unclear if the view makes a difference, let me know what u think :)
Aug 27 2020
It depends on how you look at it:
From the perspective of optimizations we can do, sure absence is the one that enables more.
From the perspective of source behavior, it just distinguishes between two alternatives, so both option w/ and w/o flag have the same information value.
Aug 20 2020
This attribute indicates that the function is guaranteed to not make progress
Aug 10 2020
It isn't contradiction, but about whether noprogress brings useful information or not, though.
Aug 9 2020
No happens-before rule is needed for sequential programs. The compiled program must exhibit all observable events in the same order as the source program.
I don't know what this statement is based on.
Aug 8 2020
If there are no accesses to the variable, there are no calls of the function. Throwing away the loop is valid, analysis of whether it is finite is not required.
Aug 6 2020
Either should do the trick after a while given that all optimizations need to preserve/handle attribute already, you cannot just drop them and so noprogress should be sufficient.
I am going solely off the description here as I am not familiar with LLVM internals. Looking forward to the LangRef update. :)
Nov 27 2019
Nov 21 2019
Aug 15 2019
A fence is not an atomic operation on its own in C++. See http://eel.is/c++draft/atomics.fences where it says "is a synchronization operation *if* [...]".
Aug 12 2019
Does this need a side effect? Per the current definition, no. Per C++, yes.
Jul 23 2019
I cannot land commits myself, could you help with that?
Feb 26 2019
I fixed the typo.
Please make sure you have llvm-commits added as a subscriber when creating patches in the future