search for: r313631

There are multiple problems/questions here: 1. Make sure you've updated trunk to the latest rev before running update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the output you're seeing if you're running the script on a version of that test file before r313631. After that commit, each RUN has its own check prefix, so there should be no conflict opportunity. 2. I didn't realize the scope of the patch covered all targets and both scalars and vectors. That isn't going to work as-is. We can't assume that every target and data type will prefer to...

...re multiple problems/questions here: > > 1. Make sure you've updated trunk to the latest rev before running > update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the > output you're seeing if you're running the script on a version of that > test file before r313631. After that commit, each RUN has its own check > prefix, so there should be no conflict opportunity. > > 2. I didn't realize the scope of the patch covered all targets and both > scalars and vectors. That isn't going to work as-is. We can't assume > that every target...

...questions here: > > > > 1. Make sure you've updated trunk to the latest rev before running > > update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the > > output you're seeing if you're running the script on a version of that > > test file before r313631. After that commit, each RUN has its own check > > prefix, so there should be no conflict opportunity. > > > > 2. I didn't realize the scope of the patch covered all targets and both > > scalars and vectors. That isn't going to work as-is. We can't assume > &g...

...; > 1. Make sure you've updated trunk to the latest rev before running > > update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the > > output you're seeing if you're running the script on a version of > that > > test file before r313631. After that commit, each RUN has its own > check > > prefix, so there should be no conflict opportunity. > > > > 2. I didn't realize the scope of the patch covered all targets > and both > > scalars and vectors. That isn't going to w...

Hi, I am currently working on a more or less intrusive patch (D37896), which pulls optimizations on multiplications from some back-ends, e.g., (mul x, 2^N + 1) => (add (shl x, N), x) in AArch64, into the DAGCombiner to have this optimization generic on all targets. However, running the LLVM Tests leads to 67 unexpected results. Am 19.09.2017 um 15:58 schrieb Sanjay Patel: > For the

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated