<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 6, 2010, at 11:30 AMPST, Chris Lattner wrote:</div><blockquote type="cite"><div>On Dec 6, 2010, at 9:36 AM, Duncan Sands wrote:<br><br><blockquote type="cite"><blockquote type="cite"> // memcpy is not defined if the source and destination pointers are exactly<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> // equal, but other compilers do this optimization, and almost every memcpy<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> // implementation handles this case safely. If there is a libc that does not<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> // safely handle this, we can add a target hook.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Note that the example from the PR doesn't explicitly call memcpy.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I've been told that on some platforms zeroing the target memory before doing the<br></blockquote><blockquote type="cite">copy speeds it up due to cache effects. It looks like clang's implementation<br></blockquote><blockquote type="cite">of struct copy will not work on such targets.<br></blockquote><br>GCC also uses memcpy. If we find one of these theoretical platforms, clang can always generate memmove on it.<br></div></blockquote><br></div><div>We might consider doing that anyway, to pre-emptively avoid the problem. Memmove will not be faster, but the performance difference is zero or negligible in many environments.</div><div><br></div></body></html>