[LLVMbugs] [Bug 16716] New: char-copying loop should optimize to memcpy
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri Jul 26 18:15:24 PDT 2013
http://llvm.org/bugs/show_bug.cgi?id=16716
Bug ID: 16716
Summary: char-copying loop should optimize to memcpy
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedbugs at nondot.org
Reporter: jyasskin at google.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
I'm reproducing with clang because I don't have an 'opt' easily available.
Looking at the unoptimized output, this looks like an `opt` issue though.
TL;DR: char-copying loop with known-alignment-and-size-after-inlining in
linkonce_odr or external function fails to optimize; in internal function
optimizes to bitcast.
$ clang++ --version
clang version 3.4 (trunk 182481)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
Manual memcpy vs the builtin:
$ cat test.cc
#include <stddef.h>
#include <string.h>
inline void my_memcpy(void* out, const void* in, size_t len) {
char* out_c = static_cast<char*>(out);
const char* in_c = static_cast<const char*>(in);
while (len--)
*out_c++ = *in_c++;
}
int foo(float f) {
int result;
my_memcpy(&result, &f, sizeof(result));
return result;
}
int foo_m(float f) {
int result;
memcpy(&result, &f, sizeof(result));
return result;
}
$ clang++ -S test.cc -o - -emit-llvm -O2
; ModuleID = 'test.cc'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.8.0"
; Function Attrs: nounwind ssp uwtable
define i32 @_Z3foof(float %f) #0 {
entry:
%result = alloca i32, align 4
%0 = bitcast i32* %result to i8*
%1 = bitcast float %f to i32
%trunc = trunc i32 %1 to i8
%incdec.ptr1.i = getelementptr inbounds i8* %0, i64 1
store i8 %trunc, i8* %0, align 4, !tbaa !0
%2 = lshr i32 %1, 8
%3 = trunc i32 %2 to i8
%incdec.ptr1.i.1 = getelementptr inbounds i8* %0, i64 2
store i8 %3, i8* %incdec.ptr1.i, align 1, !tbaa !0
%4 = lshr i32 %1, 16
%5 = trunc i32 %4 to i8
%incdec.ptr1.i.2 = getelementptr inbounds i8* %0, i64 3
store i8 %5, i8* %incdec.ptr1.i.1, align 2, !tbaa !0
%6 = lshr i32 %1, 24
%7 = trunc i32 %6 to i8
store i8 %7, i8* %incdec.ptr1.i.2, align 1, !tbaa !0
%8 = load i32* %result, align 4, !tbaa !2
ret i32 %8
}
; Function Attrs: nounwind readnone ssp uwtable
define i32 @_Z5foo_mf(float %f) #1 {
entry:
%0 = bitcast float %f to i32
ret i32 %0
}
attributes #0 = { nounwind ssp uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { nounwind readnone ssp uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false"
"use-soft-float"="false" }
!0 = metadata !{metadata !"omnipotent char", metadata !1}
!1 = metadata !{metadata !"Simple C/C++ TBAA"}
!2 = metadata !{metadata !"int", metadata !0}
Very surprisingly, making 'my_memcpy' static fixes the optimization:
$ cat test.cc
#include <stddef.h>
static void my_memcpy(void* out, const void* in, size_t len) {
char* out_c = static_cast<char*>(out);
const char* in_c = static_cast<const char*>(in);
while (len--)
*out_c++ = *in_c++;
}
int foo(float f) {
int result;
my_memcpy(&result, &f, sizeof(result));
return result;
}
jyasskin-macbookpro:~/tmp$ clang++ -S test.cc -o - -emit-llvm -O2
; ModuleID = 'test.cc'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.8.0"
; Function Attrs: nounwind readnone ssp uwtable
define i32 @_Z3foof(float %f) #0 {
entry:
%0 = bitcast float %f to i32
ret i32 %0
}
attributes #0 = { nounwind readnone ssp uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false"
"use-soft-float"="false" }
--
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/20130727/6a69b6bc/attachment.html>
More information about the llvm-bugs
mailing list