search for: mustprogress

...t; No other names have come in yet, in total the names proposed so far (I >> think) are: >> - maynotprogress >> - maybenoprogress >> - might_not_progress >> - nfpg >> - no_fpg >> and the loop metadata has been pretty firmly established as >> llvm.loop.mustprogress. IMHO, I've warmed up to no_fpg (or even nfpg >> in a pinch if we want to save 33% of space and lose some readability) >> since we've made substantial progress in clarifying the exact >> definitions of progress in this context and I think it's a good idea >> to b...

...garding the naming? We need to > clarify the semantics in C, it seems. No other names have come in yet, in total the names proposed so far (I think) are: - maynotprogress - maybenoprogress - might_not_progress - nfpg - no_fpg and the loop metadata has been pretty firmly established as llvm.loop.mustprogress. IMHO, I've warmed up to no_fpg (or even nfpg in a pinch if we want to save 33% of space and lose some readability) since we've made substantial progress in clarifying the exact definitions of progress in this context and I think it's a good idea to bake it into the attribute name. I...

On 9/7/20 2:52 PM, Nicolai Hähnle wrote: > Hi Johannes, > > On Mon, Sep 7, 2020 at 6:51 PM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> On 9/7/20 10:56 AM, Nicolai Hähnle wrote: >>  > Hi Johannes and Atmn, >>  > >>  > On Sat, Sep 5, 2020 at 7:07 AM Johannes Doerfert via llvm-dev >>  > <llvm-dev at

Hi All, We’ve prepared a new function attribute `maynotprogress` and loop metadata `llvm.loop.mustprogress` in order to better formalize the way LLVM deals with infinite loops without observable side-effects. This is deeply related to the implicit forward progress requirements in the IR. Background: There has been a demonstrated need for clarity within the forward progress requirements in LLVM IR. This...

On 9/7/20 4:48 PM, Nicolai Hähnle wrote: > Hi Johannes, > > > On Mon, Sep 7, 2020 at 11:17 PM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> >> > As a separate comment, I don't find the reference to the C++ spec in >> >> > https://reviews.llvm.org/D86233 to be informative enough. Whenever >> >> > that

On 9/4/20 7:39 PM, Hal Finkel via llvm-dev wrote: > > On 9/4/20 6:31 PM, Atmn Patel via llvm-dev wrote: >> Hi All, >> >> We’ve prepared a new function attribute `maynotprogress` and loop >> metadata `llvm.loop.mustprogress` in order to better formalize the way >> LLVM deals with infinite loops without observable side-effects. This >> is deeply related to the implicit forward progress requirements in the >> IR. >> >> Background: >> There has been a demonstrated need for clarit...

.../20 7:39 PM, Hal Finkel via llvm-dev wrote: >> > >> > On 9/4/20 6:31 PM, Atmn Patel via llvm-dev wrote: >> >> Hi All, >> >> >> >> We’ve prepared a new function attribute `maynotprogress` and loop >> >> metadata `llvm.loop.mustprogress` in order to better formalize the way >> >> LLVM deals with infinite loops without observable side-effects. This >> >> is deeply related to the implicit forward progress requirements in the >> >> IR. >> >> >> >> Background: >&...

...was documented. [25ba6b2](https://reviews.llvm.org/rG25ba6b2bcd1). * Implementation was started on `llvm.coro.async` which will be used by the Swift frontend to lower async functions. [ea5989b](https://reviews.llvm.org/rGea5989b43ad), [c6543cc](https://reviews.llvm.org/rGc6543cc6b8f). * llvm.loop.mustprogress metadata was introduced. [cea0599](https://reviews.llvm.org/rGcea0599aa75), * A range of fixes and improvements were made to the RISC-V backend's support for the yet-to-be-ratified bitmanip extension. [d47300f](https://reviews.llvm.org/rGd47300f503c), [0122a4e](https://reviews.llvm.org/rG0122a...

Hi Nicolai and Hal, I was wondering if your present concerns regarding the directions of the proposed attributes and semantics of the current direction had been addressed, so I thought I'd send over a friendly ping. Have they? Atmn On Wed, Sep 9, 2020 at 1:08 AM Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > > On 9/8/20 9:08 PM, Hal Finkel wrote: > >

...s allows to hoist/sink code, improves alias analysis, ... On the other end, with https://reviews.llvm.org/rGb22910daab95 we can remove more dead code based on `willreturn` (and `nounwind`). > Assuming the simple flip of polarity, is a new attribute needed at > all? It seems like the "mustprogress" loop metadata would be > sufficient. I think that is correct. Though, then we are back the regressing all existing IR. I'm not opposing this choice but it seems to me of little gain. To put the regression into perspective: We would basically need to stop removing an unused `readonly...