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

[Andrew Trick]

> On May 18, 2015, at 10:07 PM, Jingyue Wu <jingyue at google.com> wrote:
> 
> 
> 
> On Mon, May 18, 2015 at 10:29 AM Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote:
> On Mon, May 18, 2015 at 10:17 AM, Jingyue Wu <jingyue at google.com <mailto: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. 

Unless we have done sane block layout by the time LSR runs (IIRC we haven’t), I doubt appearance order would be meaningful.
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/6dfb61f5/attachment.html>