search for: no_fpg

...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 progress in thi...

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

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

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

...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 attribute lists, but even so. no_fpg is good too. I'm given up on the name. To be honest, if you don't read the langref you don't know what these things do half the time, at least not in detail. Let's just number them, this would be `attribute70` I think ;) Cheers,   Johannes > Thanks again, > > Hal &...

...ee"). 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 attribute lists, but even so. no_fpg is good too. >> >> I'm given up on the name. To be honest, if you don't read the langref >> you don't know what these things do half the time, at least not in >> detail. Let's just number them, this would be `attribute70` I think ;) >> >> Cheers,...