<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 7:50 PM, Hao Liu <span dir="ltr"><<a href="mailto:Hao.Liu@arm.com" target="_blank">Hao.Liu@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":hot" class="a3s" style="overflow:hidden">Example for the specific case @load_store_i64 in the patch. There is an i64 alloca, then the alloca is stored by two i32 STOREs. Following is the i64 LOAD. Currently, the SROA splits the i64 LOAD, so that  the former two i32 STOREs and the i64 LOAD can be optimized and removed.<br>

The problem is that the split of i64 LOAD introducing additional ZEXT/SHL/AND/OR IRs to handle the following i64 uses. Such additional IRs try to combine two i32 into one i64 and then store it. So I think why don't we store two i32 separately so that such additional IRs can be removed.<br>

I add patch in SROA, because following 3 reasons:<br>
  1) It is SROA that introduces such additional IRs.<br>
  2) Also it is easier to do such optimize in SROA. The LOAD can be sliced means the STORE also can be sliced. We can just split the STORE. If we keep such additional IRs and i64 STORE, the following optimizer or backend optimizer need more efforts to analyze both such additional IRs and STORE. Currently we don't have such similar optimization.<br>
</div></blockquote><div><br></div><div>These are reasons why *if* this is the right thing to do, it would be reasonable to do it in SROA. The question is -- should we be splitting the stores up at all, and why?</div><div>
<br></div><div>I don't believe we should. I'll reply to your other email with the details of why I think this is the case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":hot" class="a3s" style="overflow:hidden">
  3) This patch does the same thing as SROA handles memory copy.</div></blockquote></div><br>Note that this is pretty much incidental. It wasn't my intent to handle memcpy differently, it was just convenient at the time. It would probably be better for it to do two loads, combine the bits, and the store once.</div>
</div>