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

Fri Sep 11 11:33:33 PDT 2020

On 9/11/20 1:04 PM, James Y Knight via llvm-dev wrote:
 > On Fri, Sep 11, 2020 at 12:42 PM Atmn Patel <atmndp at gmail.com> wrote:
 >
 >> Hi Hal,
 >>
 >> On Thu, Sep 10, 2020 at 8:54 PM Hal Finkel <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.

Yeah, since we basically miscompile all but C++ code right now it makes
sense to switch the IR default and make C++ "special". To actually stop
miscompiling these codes we need to change more places as they have the
`mustprogress` backed in, though that was necessary either way. (We
could say that a call w/o the `mustprogress` and w/o `willreturn` is a
side-effect of sorts.)

~ Johannes

 > 3. Bonus: it makes choosing an attribute name easier: mustprogress, done.
 >
 > 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
 >
 >
 > 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.)
 >
 >
 > _______________________________________________
 > LLVM Developers mailing list
 > llvm-dev at lists.llvm.org
 > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev