<div dir="ltr">Thanks guys,<div><br></div><div>I'm writing up a short RFC now - I'll add a discussion of the alignment issue. While it's a separate issue, it makes sense to tackle both at once to avoid churn.<div><br></div><div>Are there any specific motivating cases you'd like me to mention?</div><div><br></div><div>- Lang.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 5:06 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "John McCall" <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>><br>
> To: "David Majnemer" <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>><br>
> Cc: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>, "Commit Messages and Patches for LLVM" <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>>, "Lang<br>
> Hames" <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>>, "Richard Smith" <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>><br>
</span><div><div class="h5">> Sent: Tuesday, August 18, 2015 7:05:18 PM<br>
> Subject: Re: [PATCH] Gut InstCombiner::SimplifyMemTransfer.<br>
><br>
><br>
><br>
><br>
><br>
> On Aug 18, 2015, at 5:01 PM, David Majnemer <<br>
> <a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a> > wrote:<br>
><br>
><br>
><br>
> On Tue, Aug 18, 2015 at 4:57 PM, John McCall < <a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> > On Aug 16, 2015, at 3:08 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> > wrote:<br>
> ><br>
> > [+Richard, John, Chandler]<br>
> ><br>
> > ----- Original Message -----<br>
> >> From: "David Majnemer via llvm-commits" <<br>
> >> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a> ><br>
> >> To: "Lang Hames" < <a href="mailto:lhames@gmail.com">lhames@gmail.com</a> ><br>
> >> Cc: "Commit Messages and Patches for LLVM" <<br>
> >> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a> ><br>
> >> Sent: Wednesday, August 12, 2015 10:35:16 PM<br>
> >> Subject: Re: [PATCH] Gut InstCombiner::SimplifyMemTransfer.<br>
> >><br>
> >><br>
> >><br>
> >> Hi Lang,<br>
> >><br>
> >><br>
> >> I reviewed the InstCombine side and it looks great, all that I ask<br>
> >> is<br>
> >> that you replace the `Instruction *` with `auto *` because the<br>
> >> type<br>
> >> is replicated in the `dyn_cast`.<br>
> >><br>
> >><br>
> >> My only concern is that clang will actually create calls to the<br>
> >> memcpy intrinsic from within clang with pointers which exactly<br>
> >> alias:<br>
> >> <a href="http://clang.llvm.org/doxygen/CGExprAgg_8cpp_source.html#l01448" rel="noreferrer" target="_blank">http://clang.llvm.org/doxygen/CGExprAgg_8cpp_source.html#l01448</a><br>
> >><br>
> ><br>
> > That seems very broken. We need to fix this. In fact, the comment<br>
> > admits as much:<br>
> ><br>
> > 01454 // memcpy is not defined if the source and destination<br>
> > pointers are exactly<br>
> > 01455 // equal, but other compilers do this optimization, and<br>
> > almost every memcpy<br>
> > 01456 // implementation handles this case safely. If there is a<br>
> > libc that does not<br>
> > 01457 // safely handle this, we can add a target hook.<br>
> ><br>
> > Is there any reason not to emit memmove instead?<br>
><br>
> Partial overlaps are generally not possible here — C guarantees that<br>
> the overlap<br>
> in an assignment has to be perfect. So a great deal of the added<br>
> complexity of<br>
> memmove is not needed; and as mentioned, no actual implementations of<br>
> memcpy misbehave for perfect overlap.<br>
><br>
> That said, I can appreciate wanting to keep the formal model sane. I<br>
> suspect that<br>
> emitting llvm.memmove would generally produce uses of the actual<br>
> memmove,<br>
> but I'd be happy to use a different intrinsic that allows only<br>
> perfect overlap and which<br>
> you can make a “platform-specific” decision to lower to memcpy in the<br>
> backend.<br>
><br>
><br>
><br>
> I suggested to Lang on IRC that we might want to add another operand<br>
> to the memcpy intrinsic to model this behavior. Another intrinsic<br>
> would, of course, work just as well. AFAICT, the only code which<br>
> would care about the distinction between memcpy as-written-in-source<br>
> and as-written-by-compiler which would make the extra flag a little<br>
> less disruptive than another intrinsic.<br>
><br>
> Oh, by the way, if you’re going to revise or embellish these<br>
> intrinsics, please also allow separate alignments to be expressed<br>
> for both operands.<br>
<br>
</div></div>While this is certainly a separate issue, FWIW, I share this desire.<br>
<br>
 -Hal<br>
<br>
><br>
><br>
> John.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>