search for: d37896

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 by utils/update_llc_test_checks.py"... and both of these do as of: https://reviews.llvm.org/rL313631 ), then it's easy to observe the...

I am currently improving the D37896 to include the suggestions from Chad. However, running the lit checks for the x86 backend I observe some changes in the generated MC, e.g.: llvm/test/CodeGen/X86/lea-3.ll:13:10: error: expected string not found in input ; CHECK: leal ([[A0]],[[A0]],2), %eax ^ <stdin>:10:2: note:...

This conversation has (partially) moved on to D37896 now, but if possible I was hoping that we could perform this in DAGCombiner and remove the various target specific combines that we still have. At least ARM/AARCH64 and X86 have cases that can hopefully be generalised and removed, but there will probably be a few legality/perf issues that will occ...

...right.com<mailto:spatel at rotateright.com>> wrote: 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 by utils/update_llc_test_checks.py"... and both of these do as of: https://reviews.llvm.org/rL313631 ), then it's easy to observe the...

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

...h - don't try the transform unless we're pre-legalization: if (Level < AfterLegalizeDAG) { // do something } On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote: > 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...

...lizeDAG) { // do something } > > > > On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael > <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> > wrote: > > 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....

...> > > > > On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael > > <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> > > wrote: > > > > 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 Te...

...uni-muenster.de> > <mailto:michael.haidl at uni-muenster.de > <mailto:michael.haidl at uni-muenster.de>>> > > wrote: > > > >     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. > >     Howev...

Hi Craig, thanks for digging into this. So InstCombine is the wrong place for fixing PR34474. Can you give me a hint where such an optimization should go into CodeGen? I am not really familiar with stuff that happens after the MidLevel. Cheers, Michael Am 13.09.2017 um 19:21 schrieb Craig Topper: > And that is less instructions. So from InstCombine's perspective the > multiply is