<div dir="ltr">Pete - That patch sounds great!<div><br></div><div>Philip, Hal, Medhi, Gerolf - Thanks very much for the feedback.</div><div><br></div><div>So how about this:</div><div>(1) We drop llvm.memcpy's alignment argument and use Pete's alignment-via-metadata patch (whatever version of it passes review). </div><div>(2) llvm.memcpy retains its current semantics, but we teach clang, SimplifyLibCalls, etc. to add noalias metadata where we know it's safe.</div><div><br></div><div>Dropping the alignment argument will still change the signature of llvm.memcpy / llvm.memmove, so I guess there's one other issue worth discussing: <span style="line-height:normal">Should we also split 'isVolatile' into 'isSrcVolatile' and 'isDstVolatile' ? Nobody has asked for this as far as I know, but I </span>believe<span style="line-height:normal"> it would improve </span>codegen in some cases. <span style="line-height:normal">E.g.:</span></div><div><br></div><div><font face="monospace, monospace">typedef struct {</font></div><div><font face="monospace, monospace">  unsigned X[8];</font></div><div><font face="monospace, monospace">} S;</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">unsigned foo(volatile S* s) {</font></div><div><font face="monospace, monospace">  S t = *s;</font></div><div><font face="monospace, monospace">  return t.X[4];</font></div><div><font face="monospace, monospace">}</font></div><div><span style="line-height:normal"><br></span></div><div>If the frontend lowers the struct copy to a volatile memcpy we'll have to copy the whole struct before reading part of 't'. If we could mark only the source as volatile then we could discard the stores to 't'.</div><div><br></div><div>Again - nobody has asked for this, but if there's interest now would be a good time to look at it.</div><div><br></div><div><span style="line-height:normal">Cheers,</span></div><div><span style="line-height:normal">Lang.</span></div><div><span style="line-height:normal"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 19, 2015 at 1:56 PM, Gerolf Hoflehner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Aug 19, 2015, at 12:54 PM, Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><blockquote type="cite" style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>On Aug 19, 2015, at 12:01 PM, Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><br>----- Original Message -----<br><blockquote type="cite">From: "Philip Reames via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>To: "Pete Cooper" <<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>>, "Lang Hames" <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>><br>Cc: "LLVM Developers Mailing List" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>Sent: Wednesday, August 19, 2015 12:14:19 PM<br>Subject: Re: [llvm-dev] [RFC] Generalize llvm.memcpy / llvm.memmove<span style="white-space:pre-wrap">     </span>intrinsics.<br><br>On 08/19/2015 09:35 AM, Pete Cooper via llvm-dev wrote:<br><blockquote type="cite">Hey Lang<br><blockquote type="cite">On Aug 18, 2015, at 6:04 PM, Lang Hames via llvm-dev<br><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><br>Hi All,<br><br>I'd like to float two changes to the llvm.memcpy / llvm.memmove<br>intrinsics.<br><br><br>(1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy<br>intrinsic.<br><br>When set to '1' (the auto-upgrade default), this argument would<br>indicate that the source and destination arguments may perfectly<br>alias (otherwise they must not alias at all - memcpy prohibits<br>partial overlap). While the C standard says that memcpy's<br>arguments can't alias at all, perfect aliasing works in practice,<br>and clang currently relies on this behavior: it emits<br>llvm.memcpys for aggregate copies, despite the possibility of<br>self-assignment.<br><br>Going forward, llvm.memcpy calls emitted for aggregate copies<br>would have mayPerfectlyAlias set to '1'. Other uses of<br>llvm.memcpy (including lowerings from memcpy calls) would have<br>mapPerfectlyAlias set to '0'.<br><br>This change is motivated by poor optimization for small memcpys on<br>targets with strict alignment requirements. When a user writes a<br>small, unaligned memcpy we may transform it into an unaligned<br>load/store pair in instcombine (See<br>InstCombine::SimplifyMemTransfer), which is then broken up into<br>an unwieldy series of smaller loads and stores during<br>legalization. I have a fix for this issue which tags the pointers<br>for unaligned load/store pairs with noalias metadata allowing<br>CodeGen to produce better code during legalization, but it's not<br>safe to apply while clang is emitting memcpys with pointers that<br>may perfectly alias. If the 'mayPerfectlyAlias' flag were<br>introduced, I could inspect that and add the noalias tag only if<br>mayPerfectlyAlias is '0'.<br><br>Note: We could also achieve the desired effect by adding a new<br>intrinsic (llvm.structcpy?) with semantics that match the current<br>llvm.memcpy ones (i.e. perfect-aliasing or non-aliasing, but no<br>partial), and then reclaim llvm.memcpy for non-aliasing pointers<br>only. I floated this idea with David Majnemer on IRC and he<br>suggested that adding a flag to llvm.memcpy might be less<br>disruptive and easier to maintain - thanks for the suggestion<br>David!<br></blockquote></blockquote>Given there's a semantically conservative interpretation and a more<br>optimistic one, this really sounds like a case for metadata not<br>another<br>argument to the function.  Our memcpy could keep it's current<br>semantics,<br>and we could add a piece of metadata which says none of the arguments<br>to<br>the call alias.<br></blockquote><br>We could add some "memcpy-allows-self-copies" metadata, and have Clang tag its associated aggregate copies with it. That would also work.<br></blockquote><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Isn’t introducing an instruction wise “correctness” related metadata?<span> </span></span><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Shouldn’t it be the opposite for correctness, i.e. “memcpy-disallows-self-copies”?</span><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">(correctness in the sense that dropping the metadata does not break anything).</span><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><blockquote type="cite"><br>Actually, can't we already get this interpretation by marking both<br>argument points as noalias?  Doesn't that require that they don't<br>overlap at all?  I think we just need the ability to specify noalias<br>at<br>the callsite for each argument.  I don't know if that's been tried,<br>but<br>it should work in theory.  There are some issues with control<br>dependence<br>of call site attributes though that we'd need to watch out for/fix.<br></blockquote><br>But that's not quite what we want. We want to say: These can't alias, unless they're exactly equal. noalias either means that it does not alias at all, nor do any derived pointers, and obviously the lack of it says nothing.<br><br>This we can still make aliasing assumptions if can prove that src != destination, which is often easier than proving things accounting for overlaps.<br></blockquote><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Is this limited to the memcpy case or are these other use-cases so that it would be worth having another attribute than noalias that would carry this semantic (“nooverlap”)?<span> </span></span><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></div></div>I was wondering about that, too. This looks like information either the user has or the compiler could derive. Would it be best to condense the properties into *alias* and *align* attributes that are also user visible?<br><blockquote type="cite"><div><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">—<span> </span></span><div><div class="h5"><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Mehdi</span><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br><br><br>(2) Allow different source and destination alignments on both<br>llvm.memcpy / llvm.memmove.<br><br>Since I'm talking about changes to llvm.memcpy anyway, a few<br>people asked me to float this one. Having separate alignments for<br>the source and destination pointers may allow us to generate<br>better code when one of the pointers has a higher alignment.<br><br>The auto-upgrade for this would be to set both source and<br>destination alignment to the original 'align' value.<br></blockquote>FWIW, I have a patch for this lying around.  I can dig it up.  I<br>use alignment attributes to do it as there’s no need for alignment<br>to be its own argument any more.<br></blockquote>This would be a nice cleanup in general.  +1<br></blockquote><br>I agree, this sounds useful.<br><br>-Hal<br><br><blockquote type="cite"><blockquote type="cite"><br>Cheers,<br>Pete<br><blockquote type="cite"><br><br>Any thoughts?<br><br>Cheers,<br>Lang.<br><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=03tkj3107244TlY4t3_hEgkDY-UG6gKwwK0wOUS3qjM&m=Js9_JWwnnCSoMnHhNlCr8sySTkjrVAbkaLqUP-49_x8&s=fAOxwvp7OA1L-OJfpwmZClRuD_eqxcJWA9p2bZ2-zz0&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=03tkj3107244TlY4t3_hEgkDY-UG6gKwwK0wOUS3qjM&m=Js9_JWwnnCSoMnHhNlCr8sySTkjrVAbkaLqUP-49_x8&s=fAOxwvp7OA1L-OJfpwmZClRuD_eqxcJWA9p2bZ2-zz0&e=</a><br></blockquote>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=cdlq9gO3Mw04smTsaMSYBJqPKPuYO_guZlyYV2-SNCo&s=Ywfk-QiLMxxWDFi3tHscrVSc4DBfToJguedKSyzZbos&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=cdlq9gO3Mw04smTsaMSYBJqPKPuYO_guZlyYV2-SNCo&s=Ywfk-QiLMxxWDFi3tHscrVSc4DBfToJguedKSyzZbos&e=</a><span> </span><br></blockquote><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=cdlq9gO3Mw04smTsaMSYBJqPKPuYO_guZlyYV2-SNCo&s=Ywfk-QiLMxxWDFi3tHscrVSc4DBfToJguedKSyzZbos&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=cdlq9gO3Mw04smTsaMSYBJqPKPuYO_guZlyYV2-SNCo&s=Ywfk-QiLMxxWDFi3tHscrVSc4DBfToJguedKSyzZbos&e=</a><span> </span><br><br></blockquote><br>--<span> </span><br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=cdlq9gO3Mw04smTsaMSYBJqPKPuYO_guZlyYV2-SNCo&s=Ywfk-QiLMxxWDFi3tHscrVSc4DBfToJguedKSyzZbos&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=cdlq9gO3Mw04smTsaMSYBJqPKPuYO_guZlyYV2-SNCo&s=Ywfk-QiLMxxWDFi3tHscrVSc4DBfToJguedKSyzZbos&e=</a><br></blockquote><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">LLVM Developers mailing list</span><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:llvm-dev@lists.llvm.org" style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">llvm-dev@lists.llvm.org</a><br style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></div><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=PlQHl7sshPU7FSzb4jGZyKbtJGJEL8ML0yYUKuWLs60&m=1ldotGn12NIM8scnVXnxKfrKZywUWKkEsSehTMLLR0E&s=489ZmsCqyXRRy8ULJCTdjh8vwbKjS5wSZfLbnsf4fD8&e=" style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=PlQHl7sshPU7FSzb4jGZyKbtJGJEL8ML0yYUKuWLs60&m=1ldotGn12NIM8scnVXnxKfrKZywUWKkEsSehTMLLR0E&s=489ZmsCqyXRRy8ULJCTdjh8vwbKjS5wSZfLbnsf4fD8&e=</a><span style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"></span></div></blockquote></div><br></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>