[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