<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 12, 2014 at 5:32 AM, James Molloy <span dir="ltr"><<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</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">Hi Chandler,<div><br></div><div>I had a discussion with Jiangning about this based upon our chat on IRC, and he asked a question I couldn't answer, so possibly you could?</div><div><br></div><div>On IRC you asserted that we need the wide store so that instcombines can see that the store was made up of two constitutent values. Why is this the case? Why can't memdep get you the same information with two narrow stores?</div></div></blockquote><div><br></div><div>Because analyzing through memory is hard?</div><div><br></div><div>Not really sure what you're asking. instcombine doesn't have memdep, and doesn't do the kind of analyses that GVN does. (Nor could it for compile time reasons...)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Surely a query such as "what does this i64 load depend on?" would return "these two i32 stores"? If this is not the case, why not?</div></div></blockquote><div><br></div><div>It is the case in things which do heavy-weight memory load/store analyses, but those aren't instcombine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> and if it is the case, why can't instcombine use this information to dive across load/store boundaries?</div></div></blockquote></div><br>Because instcombine is fundamentally about optimizing based on the SSA graph, not based on value numbers or other load/store information about the contents of memory.</div></div>