<div class="gmail_extra">On Thu, Jun 28, 2012 at 2:09 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It specifically prevents replacing your implementation of memcpy with a call to memcpy, resulting in an infloop. This will actually happen in some cases.</blockquote><div><br></div><div>Why can't the same happen with a hosted impl?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I personally think we should also provide a way to avoid the introduction of *any* calls to memcpy, and instead synthesize the loops directly. That said, while we are close to that today, there are still a few places that will do this.</div>
</blockquote><div><br></div><div>It would be nice. For some reason I still have a feeling that I am fighting against implementation details of the particular compiler.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 27, 2012 at 3:04 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div>On Thu, Jun 28, 2012 at 1:56 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unless you specify -fno-builtin, the compiler (even the low-level code generator) is free to insert a call to 'memcpy', assuming that a libc will eventually show up and provide that function. It may not be happening yet, but it will be eventually.<div>
<br></div><div>No amount of always-inline annotations help this, because the calls may get inserted after inlining has taken place.</div></blockquote><div><br></div><div><br></div></div><div>Since freestanding implementations provide memcpy, how can -ffreestanding/-fno-builtin help with this?... Why a compiler is disallows to insert memcpy's in this case?</div>
<div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">
On Wed, Jun 27, 2012 at 2:44 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br><div class="gmail_extra">On Thu, Jun 28, 2012 at 1:32 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, Jun 27, 2012 at 2:16 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div>On Thu, Jun 28, 2012 at 1:07 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect you'll need to work still harder than this... =[</blockquote><div><br></div></div><div>I know :)</div><div>Now I need to understand how exactly it is broken.</div></div></div></blockquote><div><br></div></div>
<div>
Hmm, I may also need to better understand what you're attempting to achieve with this patch (based on Timur's comment).</div><div><br></div><div>You define memset, memcpy, etc in a header file -- what callers use them? Most callers moved to 'internal_foo' versions.</div>
<div><br></div><div>To answer Timur's question -- yes its ok, but it's hard to control which (instrumented or not-instrumented) gets used if they are inserted by LLVM, and thus have the normal names. It occurs to me that my post-process name-mangling tool would solve this problem as well...</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>You'll need to compile with -fno-builtins in order to prevent LLVM's optimizer from recognizing your code as equivalent to 'memset' or 'memcpy', and replacing it with a call to those functions. =/</div>
</blockquote><div><br></div></div><div>I believe we are compiling with -fno-builtin.</div><div>You mentioned that I also need <span style="font-family:arial,sans-serif;font-size:12.800000190734863px">-ffreestanding:</span></div>
</div></div></blockquote><div><br></div></div><div>Yea, -ffreestanding may be better. It is a superset of -fno-builtin</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote">
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">"Yes, there are attributes which can be attached to the non-instrumented memcpy function, provided by the runtime and selected due to -ffreestanding, which will force inlining. __attribute__((always_inline))</span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">, __attribute__((flatten))"</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Why do I need it?</span></div></div></div>
</blockquote><div><br></div></div><div>Need which?</div><div><br></div><div>You need '-ffreestanding' so that your source code can implement 'memset' itself, and that implementation will be used rather than assuming that at some point 'libc' will get linked in and we can call *its* memset. This is necessary even if your function isn't named 'memset' but something eles.</div>
<div><br></div><div>The __attribute__((always_inline)) is needed if you want to force this function to be inlined into its callers. I don't recall off hand why this was important?</div></div></div>
</blockquote></div><br></div><div class="gmail_extra"><br></div></div></div><div class="gmail_extra">I need to prevent compiler from inserting memxxx() calls into random places of the runtime. At first glance the patch achieves the goal.</div>
<div class="gmail_extra">always_inline is required to eliminate calls.<br></div><div class="gmail_extra">I do not fully understand why <span style="color:rgb(80,0,80)"> </span><span style="color:rgb(80,0,80)">-fno-builtins/</span>-ffreestanding are required. The idea is that the compiler leaves no calls to memxxx (everything is inlined).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>