<div dir="ltr"><br><br><div class="gmail_quote">On Mon, May 18, 2015 at 10:29 AM Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 18, 2015 at 10:17 AM, Jingyue Wu <<a href="mailto:jingyue@google.com" target="_blank">jingyue@google.com</a>> wrote:<br>
> It's not caused by "the insertion point is set to the default after".<br>
><br>
> I should mention the reason somewhere earlier. "Reversing the order of<br>
> arg0~3 is not intentional. The user list of pixel_idx happens to have<br>
> pixel_idx+3, pixel_idx+2, and pixel_idx+1 in this order, so LSR simply<br>
> follows this order when collecting the LSRFixups."<br>
Ugh.<br>
Yes, I missed that. Sorry for not reading close enough.<br>
<br>
> I'm not an expert on uselist orders, but after skimming Duncan Smith's<br>
> recent work on preserving uselist orders in assembly, these orders are<br>
> deterministic but arbitrary.<br>
<br>
Yes.<br>
> So blindly following these orders sometimes<br>
> cause funny behavior (as in my example).<br>
<br>
So, then it makes sense to figure out if dominance order is really better.<br>
Otherwise, it's trivial to keep it in appearance order by assigning<br>
ids to order of appearance<br>
(IE iterating through the function bb by bb, and then inst by inst) ,<br>
and sorting back into that order.<br></blockquote><div><br></div><div>Agree. I didn't mean to propose we must use dominance order; appearance order should work for me too. My patch chose dominance order because it's easy to hack (a single line of std::sort) :) Anyhow, I should experiment with both orders, and I doubt choosing one way or the other will significantly affect the code quality. </div></div></div>