[llvm-dev] [RFC] Introducing the maynotprogress IR attribute

[Nicolai Hähnle via llvm-dev]

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 section of the C++ spec talks about "progress" it is
> referring to
>  >>  > how some abstract scheduler schedules execution of multiple threads.
>  >>  > That is, it is talking about the dynamic behavior of the
>  >>  > implementation. On the other hand, the proposed attribute presumably
>  >>  > makes a statement about the program itself _assuming that_ its
>  >>  > execution gets scheduled. So there is no applicable definition of
>  >>  > "progress" in the cited section of the C++ spec.
>  >>
>  >> I don't understand. What is the alternative to "assuming that its
>  >> execution gets scheduled"?
>  >
>  > The alternative is dealing with the possibility that execution of a
>  > thread is _not_ scheduled by the abstract machine :)
>
> I guess if you do not schedule something there is not much to say about
> it. We usually talk about about all executions and if you don't have
> any, everything is true anyway. Unsure how you see that tie in here
> though.

The point is purely one about understandability of the proposed
LangRef change. The LangRef change talks about "progress" as defined
in [intro.progress] of the C++ spec, but the vast majority of that
section, and _all_ parts of that section that actually use the word
"progress", talk about the kind of forward progress guarantees that
have nothing at all to do with what you're trying to get at in the
proposal. My understanding is that for your proposal here, you're only
really interested in what's written in the very first clause of that
C++ spec section, but that's totally non-obvious from what the
proposed patch to the LangRef says. The point is that the proposed
language is misleading to somebody who approaches it without
preconceptions.

Cheers,
Nicolai




>
> ~ Johannes
>
>  > This is a serious topic on GPUs, where you may have no or very weak
>  > forward progress guarantees, e.g. because threads mapped to the same
>  > vector/wave might not make progress while the vector is executing some
>  > other divergent part of the CFG, or because more threads are requested
>  > than physically fit on the machine.
>  >
>  > Cheers,
>  > Nicolai
>  >
>  >
>  >
>  >>
>  >> ~ Johannes
>  >>
>  >>
>  >>  > Cheers,
>  >>  > Nicolai
>  >>  >
>  >>  >
>  >>  >>  >> [1] https://bugs.llvm.org/show_bug.cgi?id=965
>  >>  >>  >> [2]
> https://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html
>  >>  >>  >> [3]
>  >> https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html
>  >>  >>  >> [4] https://reviews.llvm.org/D38336
>  >>  >>  >> [5] https://reviews.llvm.org/D65718
>  >>  >>  >> [6] https://eel.is/c++draft/intro.progress
>  >>  >
>  >>  >
>  >>  >
>  >>
>  >
>  >
>


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.