<div dir="ltr"><div>Thanks Chandler. So I will focus on fixing bug 26445, using approach (2). If I encounter something unexpected, I will update this thread.<br><br></div>Ehsan<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 28, 2016 at 5:18 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@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 dir="ltr">Sorry for my delay responding, finally caught up on my email to this point and read through the whole thread.<div><br></div><div>First and foremost: we should *definitely* not sit on our hands and wait for typeless pointers to arrive. However, we also shouldn't (IMO) take on lots of technical debt instead of working on causing typeless pointers to arrive sooner. But I don't think any of the options here are likely to incur large technical debt, so we should IMO feel free to pursue either approach.</div><div><br></div><div>I do actually think that in the face of typeless pointers, we will likely want to use integer loads and stores in the absence of some operation that makes a particular type a better fit. The reason I feel this way is because that will give us more consistent and thus "canonical" results from different input programs.</div><div><br></div><div>I think leaning on pointer type to pick a better type when lowering memcpy is a bad idea because it will essentially cause us to not know about the optimizations that are currently blocked by pointer bitcasts.</div><div><br></div><div>I have been advocating in other places that we should keep canonicalizing exactly as we currently do, and teach every optimization pass to look through pointer bitcasts (until they go away). The particular reason I advocate for this is that I expect this to make it *easier to get to typeless pointers*. Every time we fix optimization passes to look through bitcasts we get the rest of the optimizer closer in semantics to the world with typeless pointers. As an example, there may be in some passes work that will be needed to support this, and we can parallelize that work with the other typeless pointer work.</div><div><br></div><div>When typeless pointers arrive, yes, we will have lots of code that looks through bitcasts that are no longer there, but that will be both harmless and easily found and removed I suspect. Whereas, adding usage of pointer types runs the risk of continued barriers to typeless pointers creeping into the optimization layers.</div><div><br></div><div>So, I vote for approach #2 above FWIW.</div><span class="HOEnZb"><font color="#888888"><div>-Chandler</div></font></span></div><br><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Mar 23, 2016 at 8:58 AM Ehsan Amiri via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr">OK. I will do some experiments with (1) on Power PC. Will update this email chain about the results.<br><br><div class="gmail_extra"><br></div></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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</span></blockquote></div>
</blockquote></div><br></div>