<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 11:45 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Should SROA delete the ones it creates? Does it delete alloca+load?</blockquote></div><br>SROA isn't flow-sensitive, and I'd prefer it not grow such smarts. As a consequence, it doesn't know whether or not the memcpy source is undef or not.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">There are easy cases that it could handle (no stores to the newly created alloca slice) but I think that's too much cleverness in SROA.</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">However, the easy case (no stores, so no flow analysis necessary) should be handled by InstCombine if it isn't already. The flow-sensitive case of course is harder.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">However, MemCpyOptimization is also very poorly ordered in the pass pipeline currently. That will limit the utility of this patch. I'm not sure the exact best place to put it.</div>
</div>