rjmccall added a comment. In D100282#2682269 <https://reviews.llvm.org/D100282#2682269>, @lxfind wrote:
> In D100282#2682251 <https://reviews.llvm.org/D100282#2682251>, @rjmccall > wrote: > >> Why does this pass even exist? We should just expect the frontend to set >> the attribute. It's not like frontends don't have to otherwise know that >> they're emitting a coroutine; a ton of things about the expected entire IR >> pattern are different. > > The attribute setting can totally be moved to the front-end. > One thing that's not clear to me is whether we should simply set coroutine > functions noinline instead of replying on the attributres for this. > GCC seems to complain about inlining coroutines: > https://godbolt.org/z/KrzE1znno, not fully sure why. Well, *properly* inlining a coroutine requires merging the functions in ways that LLVM's representation wouldn't really support, and I assume that's true of GCC's representation as well. The best we can do is lower the coroutine and then inline the ramp function, which is not really the same thing. So warning about marking a coroutine `always_inline` does make some sense. > As for the CoroEarly pass, it lowers a bunch of intrinsics. Technically I > think they can all be done in the front-end. But moving some complexity out > of front-end to IR seems reasonable to me. Ah, if the pass does more than just setting the attribute, then sure, it makes sense to keep it. But I do think we should be requiring the attribute to be added by frontends, since it's really an IR invariant that it's present on all unlowered coroutines. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100282/new/ https://reviews.llvm.org/D100282 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
