search for: nfpg

...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 progre...

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

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

...op. 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 attribute lists, it will > still appear a lot. > > I think that I like nfpg the best (for "no forward-progress > guarantee"). Why nfpg? It's technically accurate and short. Short is > useful because, for some languages (any maybe even for some IR from > C), the attribute is going to appear on nearly every function. I know > that we have attrib...

..._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 attribute lists, it will >> > still appear a lot. >> > >> > I think that I like nfpg the best (for "no forward-progress >> > guarantee"). Why nfpg? It's technically accurate and short. Short is >> > useful because, for some languages (any maybe even for some IR from >> > C), the attribute is going to appear on nearly every function. I...