<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">We have tests that are structured like that, and a good percentage of the ones related to library calls fail when written as end-to-end tests. A single change in the chain of name changes and macros and the tests no longer connect with reality. I'll give some specific examples in the morning. The optimization isn't the only important piece here. It is also that the library calls as a user would write them are actually exposed to optimization.<div><br></div><div>Joel</div><div><br></div><div><br></div><div><div><div>On Mar 3, 2013, at 11:31 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Sun, Mar 3, 2013 at 11:24 PM, Joel Jones <span dir="ltr"><<a href="mailto:joel_k_jones@apple.com" target="_blank" class="cremed">joel_k_jones@apple.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This is the C source from the clang repo.<br></blockquote><div><br></div><div style="">Clang shouldn't be providing tests for LLVM's optimizers ever really. While we have some, the number should really decrease. (There are a very few exceptions, but this certainly doesn't seem like one...)</div>
<div style=""><br></div><div style="">Instead, if you want to test this, check that clang (without any optimizations) emits the particular IR patterns of interest. Then provide LLVM-based IR->IR tests which isolate the simplifications you expect to happen here entirely within the LLVM pipeline.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://llvm-reviews.chandlerc.com/D489" target="_blank" class="cremed">http://llvm-reviews.chandlerc.com/D489</a><br>
<br>
CHANGE SINCE LAST DIFF<br>
<a href="http://llvm-reviews.chandlerc.com/D489?vs=1179&id=1180#toc" target="_blank" class="cremed">http://llvm-reviews.chandlerc.com/D489?vs=1179&id=1180#toc</a><br>
<br>
Files:<br>
test/CodeGen/memSetCpy.c<br>
<br>
Index: test/CodeGen/memSetCpy.c<br>
===================================================================<br>
--- test/CodeGen/memSetCpy.c<br>
+++ test/CodeGen/memSetCpy.c<br>
@@ -0,0 +1,16 @@<br>
+// RUN: %clang -O3 -S -emit-llvm %s -o - | FileCheck %s<br>
+// Note: using clang here as it is very easy to end up with C source that<br>
+// doesn't actually produce llvm.mem* intrinsics that the memset; memcpy<br>
+// argument rewriting depends upon. This test may be too fragile in the form<br>
+// here. Another LLVM IR only source file tests the transformation as well,<br>
+// and is less dependent upon host compilation environments.<br>
+<br>
+#include <strings.h><br>
+<br>
+void foo(char* src, int src_size, char* dest, int dest_size)<br>
+{<br>
+// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* %dest, i8* %src,<br>
+// CHECK: call void @llvm.memset.p0i8.i64(i8*<br>
+ memset(dest, 0, dest_size);<br>
+ memcpy(dest, src, src_size);<br>
+}<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div></body></html>