search for: lsrfixup

...n 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 deterministic but arbitrary. So blindly following these orders sometimes cause funny behavior (as in my example). On Mon, May 18, 2015 at 1...

...dundant operations, i.e. a * b and b * c, combined). Note that the order of arg0~3 is reversed. 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. This creates troubles for SLSR. Given the current order of arg0~arg3 int arg3 = (a * b + 3) * c; int arg2 = (a * b + 2) * c; int arg1 = (a * b + 1) * c; int arg0 = a * b * c; SLSR optimizes them to int arg3 = (a * b + 3) * c; int arg2 = arg3 - c; int arg1 = arg2 - c; int arg0...

That source file was removed from LLVM in r232397 on March 16, 2015. It looks like lljvm hasn't been updated in a long time. LLVM's C++ APIs are not stable, so there is no expectation that a project built against LLVM's C++ API in 2015 would build or reasonably function against LLVM trunk. The project probably works against LLVM 3.6.2 which was (I believe) the last LLVM release to