Atmn Patel via llvm-dev
2020-Sep-10 18:21 UTC
[llvm-dev] [RFC] Introducing the maynotprogress IR attribute
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: > > There is another thing that I would like for us to document: do > > infinite loops have any relationship to thread synchronization? As I > > recall, this issue came up in the past when we discussed the deletion, > > or not, of infinite loops. If a thread writes a value to memory, and > > then enters an infinite loop, is that value eventually visible to > > other threads? My understanding is that some code depends on this > > property. If this is something that people would like to see > > guaranteed, > > I doubt we guarantee that now, though we might not actively exploit it. > I also think we should not treat termination as synchronization, at > least not in the case where progress is required. So, in C (and arguably > we might want to do this also in C++), we would say that: > ``` > global_signal = 1; > while (1); > ``` > is well defined and we will not remove the write. > > FWIW, I would agree that we should write this down though. > > > > I suspect that we may need specific handling (if nothing > > else, so we don't sink stores past possibly-infinite loops). > > If (possibly-)infinite loops are well defined, e.g., in a function with > the `mayprogress` attribute, we certainly cannot move any effect past > them. If they are not, they are UB if they loop infinitely and otherwise > finite and therefore a no-op. So we can either delete them, by assuming > they are finite, or, if we know they are not, actually eliminate > anything that is known to transfer execution to the loop [0]. > > [0] https://reviews.llvm.org/D87149 > > ~ Johannes > > > -Hal >
Hal Finkel via llvm-dev
2020-Sep-11 00:53 UTC
[llvm-dev] [RFC] Introducing the maynotprogress IR attribute
Hi, Atmn, Has anyone else expressed an opinion regarding the naming? We need to clarify the semantics in C, it seems. -Hal On 9/10/20 1:21 PM, Atmn Patel wrote:> 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: >> > There is another thing that I would like for us to document: do >> > infinite loops have any relationship to thread synchronization? As I >> > recall, this issue came up in the past when we discussed the deletion, >> > or not, of infinite loops. If a thread writes a value to memory, and >> > then enters an infinite loop, is that value eventually visible to >> > other threads? My understanding is that some code depends on this >> > property. If this is something that people would like to see >> > guaranteed, >> >> I doubt we guarantee that now, though we might not actively exploit it. >> I also think we should not treat termination as synchronization, at >> least not in the case where progress is required. So, in C (and arguably >> we might want to do this also in C++), we would say that: >> ``` >> global_signal = 1; >> while (1); >> ``` >> is well defined and we will not remove the write. >> >> FWIW, I would agree that we should write this down though. >> >> >> > I suspect that we may need specific handling (if nothing >> > else, so we don't sink stores past possibly-infinite loops). >> >> If (possibly-)infinite loops are well defined, e.g., in a function with >> the `mayprogress` attribute, we certainly cannot move any effect past >> them. If they are not, they are UB if they loop infinitely and otherwise >> finite and therefore a no-op. So we can either delete them, by assuming >> they are finite, or, if we know they are not, actually eliminate >> anything that is known to transfer execution to the loop [0]. >> >> [0] https://reviews.llvm.org/D87149 >> >> ~ Johannes >> >> > -Hal >>-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
Atmn Patel via llvm-dev
2020-Sep-11 16:42 UTC
[llvm-dev] [RFC] Introducing the maynotprogress IR attribute
Hi Hal, On Thu, 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 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've also modified the clang patch [0] to only apply either of the attributes for C functions when compiled with C11 or later so we can tightly adhere to both the C and C++ standards, and the other changes that need to be made will be forthcoming. Thanks again to James, that particular example was pretty cool, and I agree that it may be best to follow that interpretation. [0] https://reviews.llvm.org/D86841> -Hal > > On 9/10/20 1:21 PM, Atmn Patel wrote: > > 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: > >> > There is another thing that I would like for us to document: do > >> > infinite loops have any relationship to thread synchronization? As I > >> > recall, this issue came up in the past when we discussed the deletion, > >> > or not, of infinite loops. If a thread writes a value to memory, and > >> > then enters an infinite loop, is that value eventually visible to > >> > other threads? My understanding is that some code depends on this > >> > property. If this is something that people would like to see > >> > guaranteed, > >> > >> I doubt we guarantee that now, though we might not actively exploit it. > >> I also think we should not treat termination as synchronization, at > >> least not in the case where progress is required. So, in C (and arguably > >> we might want to do this also in C++), we would say that: > >> ``` > >> global_signal = 1; > >> while (1); > >> ``` > >> is well defined and we will not remove the write. > >> > >> FWIW, I would agree that we should write this down though. > >> > >> > >> > I suspect that we may need specific handling (if nothing > >> > else, so we don't sink stores past possibly-infinite loops). > >> > >> If (possibly-)infinite loops are well defined, e.g., in a function with > >> the `mayprogress` attribute, we certainly cannot move any effect past > >> them. If they are not, they are UB if they loop infinitely and otherwise > >> finite and therefore a no-op. So we can either delete them, by assuming > >> they are finite, or, if we know they are not, actually eliminate > >> anything that is known to transfer execution to the loop [0]. > >> > >> [0] https://reviews.llvm.org/D87149 > >> > >> ~ Johannes > >> > >> > -Hal > >> > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory >