search for: might_not_progress

...l <hfinkel at anl.gov> wrote: > > Hi, Atmn, > > Has anyone else expressed an opinion regarding 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...

...gt; Has anyone else expressed an opinion regarding 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 subst...

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

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: > >

...>> Feedback welcome. >> >> (The name of the function attribute and the loop metadata are still >> under discussion, and we’re definitely open to changing them.) > > > Some additional thoughts on the bikeshedding: > > I'm not in love with this name. might_not_progress would be better. We > could choose something more colloquial, like may_inf_loop. Or more > formal, like no_forward_progress_guarantee. I like this because it > seems the most technically accurate and isn't likely to be misread. > It's long, however, and even though we have a...

...the function attribute and the loop metadata are still >> >> under discussion, and we’re definitely open to changing them.) >> > >> > >> > Some additional thoughts on the bikeshedding: >> > >> > I'm not in love with this name. might_not_progress would be better. We >> > could choose something more colloquial, like may_inf_loop. Or more >> > formal, like no_forward_progress_guarantee. I like this because it >> > seems the most technically accurate and isn't likely to be misread. >> > It's...