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

[Jingyue Wu]

On Mon, May 18, 2015 at 10:29 AM Daniel Berlin <dberlin at dberlin.org> wrote:

> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/0abecd04/attachment.html>