[PATCH] D123300: [Clang] Enable opaque pointers by default

Dawid Jurczak via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Apr 22 07:34:56 PDT 2022

yurai007 added a comment.

Just one more thing regarding this:

In D123300#3467165 <https://reviews.llvm.org/D123300#3467165>, @yurai007 wrote:

> Hi, unfortunately for some reason it doesn't play well with coroutines HALO. There is regression seen on Gor's Nishanov classical code snippet:  https://godbolt.org/z/PKMxqq4Gr I'm checking IR to find out more.

It's (kind of) related to GEPs as well. From CoroElide perspective the thing is that we cannot collect coro.subfn.addrs associated with coro.begin intrinsics in processCoroId.
Normally, for each coro.begin we traverse its users list and save found coro.subfn.addr. That explains why elision works fine when coro.begin is directly used by coro.subfn.addr:

  %35 = call noalias nonnull i8* @llvm.coro.begin(token %31, i8* %34)
  %40 = call i8* @llvm.coro.subfn.addr(i8* nonnull %35, i8 0)

With opaque pointers IR reaching CoroElide has intermediate GEPs so coro.subfn.addr is not present on coro.begin's list and DestroyAddrs are not collected:

  %22 = call noalias nonnull ptr @llvm.coro.begin(token %18, ptr %21)
  %__promise.reload.addr.i36 = getelementptr inbounds %_Z3addIiE9generatorIT_ERS2_S1_.Frame, ptr %22, i64 0, i32 2
  %23 = getelementptr inbounds i8, ptr %__promise.reload.addr.i36, i64 -16
  %24 = call ptr @llvm.coro.subfn.addr(ptr nonnull %23, i8 0)

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list