
<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Ehsan Amiri via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"Mehdi Amini" <mehdi.amini@apple.com><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org>, "Tom Stellard" <thomas.stellard@amd.com>, "Ulrich Weigand" <uweigand@de.ibm.com><br><b>Sent: </b>Tuesday, March 22, 2016 6:38:32 PM<br><b>Subject: </b>Re: [llvm-dev] RFC: A change in InstCombine canonical form<br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 7:33 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><br><div><span class=""><blockquote><div>On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div><div><div>James,<br><br></div>I think (1) reduces the number of "do-not-see-through-bitcast" bugs that we need to uncover and fix between now and the time that typeless pointer is available. That means it is likely that we have multiple such fixes in the code and then we have to remove each one of them. (And means each one of those has to be done properly to be easily remove-able).<br><br></div>Changing canonicaliztion of memcpy, will be removing a couple of lines of code. I am not sure about the size of backend changes to optimize load-store patterns. But I expect it to be small.<br></div></div></div></blockquote><div><br></div></span><div>Are you saying that the canonicalization you want to change is temporary till we get the typeless pointers?</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></blockquote><div><br></div><div>I think typeless pointer, will automatically makes it obsolete. Remember, I proposed to make a change "when we load a value of type T from a type T* memory address". There will not be a type T * memory address, once typeless pointer work is in.<br></div><div id="DWT19055"><br></div></div></div></div></blockquote>When we transform a small memcpy into a pair of load and store instructions, we'll still need to pick a type. Currently, as I understand it, we always pick integers. It is proposed to use the original type instead. Once we have typeless pointers, how will we pick the type? If the answer is that we'll always use integers, then I suppose this is temporary. Otherwise, not. Does that accurately represent the situation?<br><br> -Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><span class="HOEnZb"><font color="#888888"><div></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><br></font></span><blockquote><div><span class=""><div dir="ltr"><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 6:58 PM, James Y Knight <span dir="ltr"><<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Mar 22, 2016 at 5:44 PM, Ehsan Amiri 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div><div>Thanks. <br><br></div><b>Phillip, </b>As Hal said I do not think (1) is a very large item. Please let me know if I am mistaken. <br></div><br><b>David </b>I think (1) is more inline with typeless pointer work than (2). Contributing to typeless pointer work will be great, but given its unknown time frame we cannot stop fixing existing problems. Of course, we should follow an approach consistent with the long-term solution.</div></blockquote><div><br></div></span><div>It seems to me that the question to ask is what would be the best state of the code, assuming that the typeless pointers work had already been done. Is it the current canonical form? Or the newly proposed one?</div><div><br></div><div>I think it'd be the current one? If so, I'd suggest that proposal #2 is more compatible with the typeless pointer work. That is because (if done properly), code which knows how to look through pointer bitcast nodes is something which will be much more easily deletable once pointer bitcast nodes cease to exist, than to change the canonicalization of memcpy back and remove any backend code which was added only to compensate for that change.<br></div></div></div></div>

</blockquote></div><br></div></span><span class="">

_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></span></div></blockquote></div><br></div></blockquote></div><br></div></div>

<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>