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

[Atmn Patel via llvm-dev]

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
>