search for: maynotprogress

...the first inliner patch: https://reviews.llvm.org/D87180 >> It is alone sufficient for correctness of this scheme. A follow up can >> provide better optimization opportunities by using metadata to annotate >> loops in the caller, assuming the caller did not have the >> `maynotprogress` function attribute already. All loops originally in the >> caller would be given the loop metadata that indicates the new >> `maynotprogress` inherited from the callee does not apply to them. If >> the metadata is lost for some reason, we do not loose correctness. > >...

..., Sep 10, 2020 at 8:54 PM Hal Finkel <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...

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

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

...ly but let me give it a try. So this is the first inliner patch: https://reviews.llvm.org/D87180 It is alone sufficient for correctness of this scheme. A follow up can provide better optimization opportunities by using metadata to annotate loops in the caller, assuming the caller did not have the `maynotprogress` function attribute already. All loops originally in the caller would be given the loop metadata that indicates the new `maynotprogress` inherited from the callee does not apply to them. If the metadata is lost for some reason, we do not loose correctness. > A deeper issue I have with the pro...

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

...johannesdoerfert at gmail.com> wrote: >> >> 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 >> >&gt...

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

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