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

[Nicolai Hähnle via llvm-dev]

Hi Johannes and Atmn,

On Sat, Sep 5, 2020 at 7:07 AM Johannes Doerfert via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>  > In any case, please explain the intended behavior of the attribute and
>  > the metadata upon inlining.
>
> The attribute will be attached to the caller upon inlining as this is
> the only way to keep semantics correct. Metadata can be added to the
> loops of the caller if the caller did not have the attribute, but that
> is an optimization and not required. The patch for the first part will
> be part of this change set.

I don't understand why this would be correct, unless you meant this
statement to only refer to loops in the caller that contain the
inlined call.

A deeper issue I have with the proposal is that I'm concerned about
adding more attributes which add constraints on program transforms.
I'm afraid I don't have the full history of these discussions, but is
there really a _good_ reason for doing so? It would feel more natural
to have no progress requirement by default and add a "willprogress"
attribute to indicate that the so annotated function will eventually
make progress (whatever that means, which is the other issue I have
with this :))

Assuming the simple flip of polarity from the previous paragraph, what
is the difference between the existing "willreturn" and the proposed
"willprogress"? Furthermore, if there is a difference, why is it
relevant to the compiler?

Assuming the simple flip of polarity, is a new attribute needed at
all? It seems like the "mustprogress" loop metadata would be
sufficient.

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.

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.