[PATCH] D85393: [WIP] [IR] Adding noprogress as a LLVM IR attribute

Thu Aug 6 08:51:31 PDT 2020

jdoerfert added a comment.

In D85393#2199024 <https://reviews.llvm.org/D85393#2199024>, @RalfJung wrote:

> I am going solely off the description here as I am not familiar with LLVM internals. Looking forward to the LangRef update. :)
>
> Great to see some progress (heh ;) is made on this, thanks Johannes! One thing made me curious though: if I understand correctly "noprogress" is a somewhat strange attribute in that *not* having this attribute promises that the function *will* "make progress"? That's the opposite from other attributes like "nounwind". Is it not possible to instead have a "progress" or "nodiverge" attribute which promises that the function *will* make progress / will not diverge (in the sense of running infinitely without any side-effect)? I imagine the attribute could be added by default when loading old bitcode to preserve semantics (but dropping the attribute is safe so this would only be crucial for performance, not for correctness).

Right, the "direction" of the attribute is what we need to discuss now. This was a first try, renaming it now is simple if we decide to do so. I suggested to start with this version as it shouldn't cause regressions for C/C++, though, I acknowledge the opposite attribute might at first be the "safer"/"saner" choice. Either should do the trick after a while given that all optimizations need to preserve/handle attribute already, you cannot just drop them and so `noprogress` should be sufficient.

> Also, in terms of semantics (but this might be more appropriate for the LangRef PR), is it legal for a "progress" and "noprogress" function to mutually recursively call each other infinitely? As in, does not having "noprogress" promise that every call to this function will return or have infinitely many side-effects, or does not having "noprogress" just promise that *this function* and all the no-"noprogress" functions it calls will not diverge? (You can see here why I think the attribute should be inverted in its meaning. ;)

Hm... I will need to think about this. Given that we want to mix C/C++ with Rust on IR-level, right?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85393/new/

https://reviews.llvm.org/D85393