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

[Hal Finkel via llvm-dev]

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