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

[Hal Finkel via llvm-dev]

On 9/11/20 1:04 PM, James Y Knight wrote:
> On Fri, Sep 11, 2020 at 12:42 PM Atmn Patel <atmndp at gmail.com 
> <mailto:atmndp at gmail.com>> wrote:
>
>     Hi Hal,
>
>     On Thu, Sep 10, 2020 at 8:54 PM Hal Finkel <hfinkel at anl.gov
>     <mailto: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'd actually like to suggest that we invert the default for 
> functions. Rather than adding a "maynotprogress" function attribute, 
> instead add a "mustprogress" function attribute, which Clang will emit 
> on every function compiled in C++ mode. For two reasons:
> 1. Having both the attribute and the loop metadata be the same way 
> around makes it simpler to think about (rather than one being 
> positive, and the other being negated).
> 2. Given that the global progress-requirement seems to be pretty much 
> C++-specific, having this behavior be off by default, and opted into 
> by C++ frontends makes sense.
> 3. Bonus: it makes choosing an attribute name easier: mustprogress, done.


I support this suggestion.

  -Hal


>
>     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 <https://reviews.llvm.org/D86841>
>
>
> You mean that you now apply maynotprogress to all functions in C, 
> right? But why only C11 and later? I think all versions of C should 
> get the maynotprogress function attribute? (Or, with the change I 
> suggest above: only C++ code should get the "mustprogress" function 
> attribute.)

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200911/acce3eb9/attachment.html>