[LLVMdev] [LSR] hoisting loop invariants in reverse order

[Daniel Berlin]

On Mon, May 18, 2015 at 10:17 AM, Jingyue Wu <jingyue at google.com> wrote:
> It's not caused by "the insertion point is set to the default after".
>
> I should mention the reason somewhere earlier. "Reversing the order of
> arg0~3 is not intentional. The user list of pixel_idx happens to have
> pixel_idx+3, pixel_idx+2, and pixel_idx+1 in this order, so LSR simply
> follows this order when collecting the LSRFixups."
Ugh.
Yes, I missed that. Sorry for not reading close enough.

> I'm not an expert on uselist orders, but after skimming Duncan Smith's
> recent work on preserving uselist orders in assembly, these orders are
> deterministic but arbitrary.

Yes.
> So blindly following these orders sometimes
> cause funny behavior (as in my example).

So, then it makes sense to figure out if dominance order is really better.
Otherwise, it's trivial to keep it in appearance order by assigning
ids to order of appearance
(IE iterating through the function bb by bb, and then inst by inst) ,
and sorting back into that order.