Displaying 2 results from an estimated 2 matches for "pixel_idx".
2015 May 09
4
[LLVMdev] [LSR] hoisting loop invariants in reverse order
...riants back to the
"natural" order? IMO, the optimized code should in general resemble the
original code unless intentionally changed otherwise.
More specifically, I ran LSR on
void foo(float *input, int a, int b, int c, int n) {
for (int node_x = 0; node_x < n; ++node_x) {
int pixel_idx = (a + node_x) * b; // {a*b, +, b}
bar(pixel_idx * c); // {a*b*c, +, b*c}
bar((pixel_idx + 1) * c); // {(a*b+1)*c, +, b*c}
bar((pixel_idx + 2) * c); // {(a*b+2)*c, +, b*c}
bar((pixel_idx + 3) * c); // {(a*b+3)*c, +, b*c}
}
}
and LSR produced
void foo(float *input, int a, int b,...
2015 May 18
2
[LLVMdev] [LSR] hoisting loop invariants in reverse order
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."
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
deter...