[llvm-bugs] [Bug 36578] New: [Coroutines] mem2reg causes "cannot move instruction since its users are not dominated by CoroBegin"

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Mar 2 10:20:33 PST 2018


https://bugs.llvm.org/show_bug.cgi?id=36578

            Bug ID: 36578
           Summary: [Coroutines] mem2reg causes "cannot move instruction
                    since its users are not dominated by CoroBegin"
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: superjoe30 at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 19988
  --> https://bugs.llvm.org/attachment.cgi?id=19988&action=edit
repro.ll

In my frontend, I'm careful to store args that are referenced in the Cleanup
block into the coro frame, to avoid tripping "cannot move instruction since its
users are not dominated by CoroBegin":


define internal fastcc i8* @amain(%Allocator*, i16*) unnamed_addr #0 !dbg !234
{
  store %Allocator* %0, %Allocator** %_anon3, align 8, !dbg !248

then later in the cleanup block:

  %28 = load %Allocator*, %Allocator** %_anon3, align 8, !dbg !248
  %29 = getelementptr inbounds %Allocator, %Allocator* %28, i32 0, i32 2, !dbg
!248
  %30 = load void (%Allocator*, %"[]u8"*)*, void (%Allocator*, %"[]u8"*)** %29,
align 8, !dbg !248
  %31 = call i8* @llvm.coro.free(token %6, i8* %12), !dbg !248

This works at -O0. But when mem2reg runs it replaces the load from _anon3 to %0
directly:

  call fastcc void %31(%Allocator* nonnull %0, %"[]u8"* byval nonnull %2) #6,
!dbg !191

This trips the corosplit assertion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180302/ded3357b/attachment.html>


More information about the llvm-bugs mailing list