[PATCH] D124363: [Coroutines] Don't optimize readnone function before we split coroutine (4/5)

John McCall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 27 22:53:45 PDT 2022


rjmccall added inline comments.


================
Comment at: clang/lib/CodeGen/CGCall.cpp:2132
     if (TargetDecl->hasAttr<ConstAttr>()) {
-      FuncAttrs.addAttribute(llvm::Attribute::ReadNone);
+      if (!LangOpts.Coroutines)
+        FuncAttrs.addAttribute(llvm::Attribute::ReadNone);
----------------
This is a global setting and will affect every function in every file that has coroutines enabled, which is presumably every file compiled with `-std=c++20` or later.  So you're radically changing optimization for a ton of C++ code that doesn't use coroutines.

It should be fine to just add `coro_readnone` instead of `readnone` to call sites from coroutine bodies, right?  Oh, but I guess we could have a `readnone` call in an inlined function body.  Can we just suppress this kind of code motion in coroutine bodies, or is that too invasive to the optimizer?

Actually, maybe your change to this patch was a misunderstanding.  What I was trying to say in Discourse was that I wasn't sure that your early pass approach would work for thread-local variables, because addresses of thread-locals are LLVM constants and can get moved around implicitly; you need the frontend to be involved there so that there's something hooked into the right place in the emitted function.  But I think it should work for this `readnone` annotation.


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

https://reviews.llvm.org/D124363



More information about the llvm-commits mailing list