http://llvm.org/bugs/show_bug.cgi?id=17021
Reid Kleckner <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Reid Kleckner <[email protected]> --- The difference is that after my patch, we successfully recognize memcpy as a builtin: --- cc_after.ll 2013-08-28 13:16:19.875920600 -0700 +++ cc_before.ll 2013-08-28 13:16:26.360920600 -0700 @@ -53,7 +53,7 @@ %call = call i8* @"\01?ident@@YAPAXPCX@Z"(i8* %arraydecay) %arraydecay1 = getelementptr inbounds [6 x i8]* %buff1, i32 0, i32 0 %call2 = call i8* @"\01?ident@@YAPAXPCX@Z"(i8* %arraydecay1) - call void @llvm.memcpy.p0i8.p0i8.i32(i8* %call, i8* %call2, i32 6, i32 1, i1 false) + %call3 = call i8* @memcpy(i8* %call, i8* %call2, i32 6) call void @"\01?UNREACHABLE@@YAXXZ"() ret i32 0 } @@ -61,6 +61,8 @@ ; Function Attrs: nounwind declare void @llvm.memcpy.p0i8.p0i8.i32(i8* nocapture, i8* nocapture readonly, i32, i32, i1) #2 +declare i8* @memcpy(i8*, i8*, i32) #1 + Presumably LLVM lowers it to loads and stores. Maybe if you put the function pointer through ident() you'd get the original stack. The weird thing is that this is not an LLVM optimization, it happens even with -mllvm -disable-llvm-optzns and -O0. It's something in clang. -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
