Sanjay Patel via llvm-dev
2017-Sep-19 13:58 UTC
[llvm-dev] How to add optimizations to InstCombine correctly?
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 diffs by re-running that script after your code patch is applied: $ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc lea-3.ll $ svn diff lea-3.ll On Tue, Sep 19, 2017 at 5:23 AM, Haidl, Michael via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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: scanning from here > orq %rdi, %rax > ^ > <stdin>:10:2: note: with variable "A0" equal to "%rdi" > orq %rdi, %rax > ^ > <stdin>:10:2: note: with variable "A0" equal to "%rdi" > orq %rdi, %rax > ^ > <stdin>:23:2: note: possible intended match here > leal (,%rdi,4), %eax > ^ > or: > > llvm/test/CodeGen/X86/mul-constant-i16.ll:40:13: error: expected string > not found in input > ; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax > ^ > <stdin>:35:2: note: scanning from here > movzwl 4(%esp), %ecx > ^ > llvm/test/CodeGen/X86/mul-constant-i16.ll:272:13: error: expected string > not found in input > ; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax > ^ > <stdin>:212:2: note: scanning from here > movzwl 4(%esp), %ecx > ^ > > What is the right way to fix this? Is it ok to modify the tests to match > the new generated pattern? > > Cheers, > Michael > > > Am 16.09.2017 um 15:46 schrieb Simon Pilgrim: > > 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 occur. > > > > Simon. > > > >> On 14 Sep 2017, at 06:23, Craig Topper <craig.topper at gmail.com > >> <mailto:craig.topper at gmail.com>> wrote: > >> > >> Probably in visitMUL in DAGCombiner.cpp to be target independent. Or > >> in LowerMUL in X86ISelLowering.cpp to be X86 specific. > >> > >> Adding Simon. Simon, which were you thinking? > >> > >> ~Craig > >> > >> On Wed, Sep 13, 2017 at 10:06 PM, Haidl, Michael > >> <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> > >> wrote: > >> > >> 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 the correct answer. I think this transformation is > better > >> > left to codegen where we know whether multiply or shift is truly > better. > >> > > >> > ~Craig > >> > > >> > On Wed, Sep 13, 2017 at 10:18 AM, Craig Topper < > craig.topper at gmail.com <mailto:craig.topper at gmail.com> > >> > <mailto:craig.topper at gmail.com <mailto:craig.topper at gmail.com>>> > wrote: > >> > > >> > There is in fact a transform out there somewhere that > reverses yours. > >> > > >> > define i64 @foo(i64 %a) { > >> > %b = shl i64 %a, 5 > >> > %c = add i64 %b, %a > >> > ret i64 %c > >> > } > >> > > >> > becomes > >> > > >> > define i64 @foo(i64 %a) { > >> > > >> > %c = mul i64 %a, 33 > >> > > >> > ret i64 %c > >> > > >> > } > >> > > >> > > >> > ~Craig > >> > > >> > On Wed, Sep 13, 2017 at 10:11 AM, Craig Topper > >> > <craig.topper at gmail.com <mailto:craig.topper at gmail.com> > >> <mailto:craig.topper at gmail.com <mailto:craig.topper at gmail.com>>> > >> wrote: > >> > > >> > Your code seems fine. InstCombine can infinite loop if > some > >> > other transform is reversing your transform. Can you send > the > >> > whole patch and a test case? > >> > > >> > ~Craig > >> > > >> > On Wed, Sep 13, 2017 at 10:01 AM, Haidl, Michael via > llvm-dev > >> > <llvm-dev at lists.llvm.org > >> <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org > >> <mailto:llvm-dev at lists.llvm.org>>> wrote: > >> > > >> > Hi, > >> > > >> > I am working on PR34474 and try to add a new > >> optimization to > >> > InstCombine. Like in other parts of the visitMul > >> function I > >> > add a Shl > >> > through the IR builder and create a new BinaryOp > which I > >> > return from > >> > visitMul. If I understand correctly the new BinaryOp > >> > returned from > >> > visitMul should replace the original Instruction in > the > >> > Worklist. > >> > However, I end up in an infinite loop and the > >> Instruction I > >> > try to > >> > replace gets scheduled again and again. What is > >> wrong in my > >> > code? > >> > > >> > // Replace X * (2^C+/-1) with (X << C) -/+ X > >> > APInt Plus1 = *IVal + 1; > >> > APInt Minus1 = *IVal - 1; > >> > int isPow2 = Plus1.isPowerOf2() ? 1 : > >> Minus1.isPowerOf2() ? > >> > -1 : 0; > >> > > >> > if (isPow2) { > >> > APInt &Pow2 = isPow2 > 0 ? Plus1 : Minus1; > >> > Value *Shl = Builder.CreateShl(Op0, > >> Pow2.logBase2()); > >> > return BinaryOperator::Create(isPow2 > 0 ? > >> > BinaryOperator::Sub : > >> > BinaryOperator::Add, Shl, Op0); > >> > } > >> > > >> > Thanks, > >> > Michael > >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170919/61c43cf6/attachment-0001.html>
Haidl, Michael via llvm-dev
2017-Sep-19 18:35 UTC
[llvm-dev] How to add optimizations to InstCombine correctly?
Hi Sanjay,
thanks for enlighten me on terms of tests. I assume I have to run the test-suite
benchmarks to check for regressions? Is there a guide to get the metrics from
the benchmarks?
Cheers,
Michael
BTW the beginner tag for bugs was really a good idea to get started with
contributing to llvm.
On Tue, Sep 19, 2017 at 3:58 PM +0200, "Sanjay Patel" <spatel at
rotateright.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 diffs by re-running that script after your code patch is
applied:
$ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc lea-3.ll
$ svn diff lea-3.ll
On Tue, Sep 19, 2017 at 5:23 AM, Haidl, Michael via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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: scanning from here
orq %rdi, %rax
^
<stdin>:10:2: note: with variable "A0" equal to "%rdi"
orq %rdi, %rax
^
<stdin>:10:2: note: with variable "A0" equal to "%rdi"
orq %rdi, %rax
^
<stdin>:23:2: note: possible intended match here
leal (,%rdi,4), %eax
^
or:
llvm/test/CodeGen/X86/mul-constant-i16.ll:40:13: error: expected string
not found in input
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
^
<stdin>:35:2: note: scanning from here
movzwl 4(%esp), %ecx
^
llvm/test/CodeGen/X86/mul-constant-i16.ll:272:13: error: expected string
not found in input
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
^
<stdin>:212:2: note: scanning from here
movzwl 4(%esp), %ecx
^
What is the right way to fix this? Is it ok to modify the tests to match
the new generated pattern?
Cheers,
Michael
Am 16.09.2017 um 15:46 schrieb Simon Pilgrim:> 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 occur.
>
> Simon.
>
>> On 14 Sep 2017, at 06:23, Craig Topper <craig.topper at
gmail.com<mailto:craig.topper at gmail.com>
>> <mailto:craig.topper at gmail.com<mailto:craig.topper at
gmail.com>>> wrote:
>>
>> Probably in visitMUL in DAGCombiner.cpp to be target independent. Or
>> in LowerMUL in X86ISelLowering.cpp to be X86 specific.
>>
>> Adding Simon. Simon, which were you thinking?
>>
>> ~Craig
>>
>> On Wed, Sep 13, 2017 at 10:06 PM, Haidl, Michael
>> <michael.haidl at uni-muenster.de<mailto:michael.haidl at
uni-muenster.de> <mailto:michael.haidl at
uni-muenster.de<mailto:michael.haidl at uni-muenster.de>>>
>> wrote:
>>
>> 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 the correct answer. I think this transformation is
better
>> > left to codegen where we know whether multiply or shift is
truly better.
>> >
>> > ~Craig
>> >
>> > On Wed, Sep 13, 2017 at 10:18 AM, Craig Topper
<craig.topper at gmail.com<mailto:craig.topper at gmail.com>
<mailto:craig.topper at gmail.com<mailto:craig.topper at gmail.com>>
>> > <mailto:craig.topper at gmail.com<mailto:craig.topper at
gmail.com> <mailto:craig.topper at gmail.com<mailto:craig.topper at
gmail.com>>>> wrote:
>> >
>> > There is in fact a transform out there somewhere that
reverses yours.
>> >
>> > define i64 @foo(i64 %a) {
>> > %b = shl i64 %a, 5
>> > %c = add i64 %b, %a
>> > ret i64 %c
>> > }
>> >
>> > becomes
>> >
>> > define i64 @foo(i64 %a) {
>> >
>> > %c = mul i64 %a, 33
>> >
>> > ret i64 %c
>> >
>> > }
>> >
>> >
>> > ~Craig
>> >
>> > On Wed, Sep 13, 2017 at 10:11 AM, Craig Topper
>> > <craig.topper at gmail.com<mailto:craig.topper at
gmail.com> <mailto:craig.topper at gmail.com<mailto:craig.topper at
gmail.com>>
>> <mailto:craig.topper at gmail.com<mailto:craig.topper at
gmail.com> <mailto:craig.topper at gmail.com<mailto:craig.topper at
gmail.com>>>>
>> wrote:
>> >
>> > Your code seems fine. InstCombine can infinite loop if
some
>> > other transform is reversing your transform. Can you
send the
>> > whole patch and a test case?
>> >
>> > ~Craig
>> >
>> > On Wed, Sep 13, 2017 at 10:01 AM, Haidl, Michael via
llvm-dev
>> > <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>
>> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev
at lists.llvm.org>
>> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>>> wrote:
>> >
>> > Hi,
>> >
>> > I am working on PR34474 and try to add a new
>> optimization to
>> > InstCombine. Like in other parts of the visitMul
>> function I
>> > add a Shl
>> > through the IR builder and create a new BinaryOp
which I
>> > return from
>> > visitMul. If I understand correctly the new
BinaryOp
>> > returned from
>> > visitMul should replace the original Instruction
in the
>> > Worklist.
>> > However, I end up in an infinite loop and the
>> Instruction I
>> > try to
>> > replace gets scheduled again and again. What is
>> wrong in my
>> > code?
>> >
>> > // Replace X * (2^C+/-1) with (X << C) -/+ X
>> > APInt Plus1 = *IVal + 1;
>> > APInt Minus1 = *IVal - 1;
>> > int isPow2 = Plus1.isPowerOf2() ? 1 :
>> Minus1.isPowerOf2() ?
>> > -1 : 0;
>> >
>> > if (isPow2) {
>> > APInt &Pow2 = isPow2 > 0 ? Plus1 :
Minus1;
>> > Value *Shl = Builder.CreateShl(Op0,
>> Pow2.logBase2());
>> > return BinaryOperator::Create(isPow2 > 0 ?
>> > BinaryOperator::Sub :
>> > BinaryOperator::Add, Shl, Op0);
>> > }
>> >
>> > Thanks,
>> > Michael
>>
>
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170919/35a7c818/attachment.html>
Sanjay Patel via llvm-dev
2017-Sep-19 19:45 UTC
[llvm-dev] How to add optimizations to InstCombine correctly?
Your patch must pass all of the regression tests (everything under llvm/test), or you'll get many fail mails from bots soon after the commit. The commit will then be reverted if it can't be corrected immediately. Running the test-suite is a good idea, but it's not required. If there's consensus that the patch is doing the theoretical right thing, then the patch should be ok to commit once reviewed and approved. Particularly with low-level changes like this, it's possible that doing the right thing may still cause some unexpected change that leads to a regression on some hardware somewhere in the world. There are public and private bots running the test-suite and many other benchmarks, so you'll hear about it sooner or later if your patch makes something worse. :) A couple of links to get started: https://llvm.org/docs/TestingGuide.html http://llvm.org/docs/lnt/quickstart.html On Tue, Sep 19, 2017 at 12:35 PM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote:> Hi Sanjay, > > thanks for enlighten me on terms of tests. I assume I have to run the > test-suite benchmarks to check for regressions? Is there a guide to get the > metrics from the benchmarks? > > Cheers, > Michael > > BTW the beginner tag for bugs was really a good idea to get started with > contributing to llvm. > > > > On Tue, Sep 19, 2017 at 3:58 PM +0200, "Sanjay Patel" < > 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 diffs by re-running that script after your code >> patch is applied: >> $ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc >> lea-3.ll >> $ svn diff lea-3.ll >> >> On Tue, Sep 19, 2017 at 5:23 AM, Haidl, Michael via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> 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: scanning from here >>> orq %rdi, %rax >>> ^ >>> <stdin>:10:2: note: with variable "A0" equal to "%rdi" >>> orq %rdi, %rax >>> ^ >>> <stdin>:10:2: note: with variable "A0" equal to "%rdi" >>> orq %rdi, %rax >>> ^ >>> <stdin>:23:2: note: possible intended match here >>> leal (,%rdi,4), %eax >>> ^ >>> or: >>> >>> llvm/test/CodeGen/X86/mul-constant-i16.ll:40:13: error: expected string >>> not found in input >>> ; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax >>> ^ >>> <stdin>:35:2: note: scanning from here >>> movzwl 4(%esp), %ecx >>> ^ >>> llvm/test/CodeGen/X86/mul-constant-i16.ll:272:13: error: expected string >>> not found in input >>> ; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax >>> ^ >>> <stdin>:212:2: note: scanning from here >>> movzwl 4(%esp), %ecx >>> ^ >>> >>> What is the right way to fix this? Is it ok to modify the tests to match >>> the new generated pattern? >>> >>> Cheers, >>> Michael >>> >>> >>> Am 16.09.2017 um 15:46 schrieb Simon Pilgrim: >>> > 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 occur. >>> > >>> > Simon. >>> > >>> >> On 14 Sep 2017, at 06:23, Craig Topper <craig.topper at gmail.com >>> >> <mailto:craig.topper at gmail.com>> wrote: >>> >> >>> >> Probably in visitMUL in DAGCombiner.cpp to be target independent. Or >>> >> in LowerMUL in X86ISelLowering.cpp to be X86 specific. >>> >> >>> >> Adding Simon. Simon, which were you thinking? >>> >> >>> >> ~Craig >>> >> >>> >> On Wed, Sep 13, 2017 at 10:06 PM, Haidl, Michael >>> >> <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de >>> >> >>> >> wrote: >>> >> >>> >> 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 the correct answer. I think this transformation is >>> better >>> >> > left to codegen where we know whether multiply or shift is >>> truly better. >>> >> > >>> >> > ~Craig >>> >> > >>> >> > On Wed, Sep 13, 2017 at 10:18 AM, Craig Topper < >>> craig.topper at gmail.com <mailto:craig.topper at gmail.com> >>> >> > <mailto:craig.topper at gmail.com <mailto:craig.topper at gmail.com>>> >>> wrote: >>> >> > >>> >> > There is in fact a transform out there somewhere that >>> reverses yours. >>> >> > >>> >> > define i64 @foo(i64 %a) { >>> >> > %b = shl i64 %a, 5 >>> >> > %c = add i64 %b, %a >>> >> > ret i64 %c >>> >> > } >>> >> > >>> >> > becomes >>> >> > >>> >> > define i64 @foo(i64 %a) { >>> >> > >>> >> > %c = mul i64 %a, 33 >>> >> > >>> >> > ret i64 %c >>> >> > >>> >> > } >>> >> > >>> >> > >>> >> > ~Craig >>> >> > >>> >> > On Wed, Sep 13, 2017 at 10:11 AM, Craig Topper >>> >> > <craig.topper at gmail.com <mailto:craig.topper at gmail.com> >>> >> <mailto:craig.topper at gmail.com <mailto:craig.topper at gmail.com>>> >>> >> wrote: >>> >> > >>> >> > Your code seems fine. InstCombine can infinite loop if >>> some >>> >> > other transform is reversing your transform. Can you >>> send the >>> >> > whole patch and a test case? >>> >> > >>> >> > ~Craig >>> >> > >>> >> > On Wed, Sep 13, 2017 at 10:01 AM, Haidl, Michael via >>> llvm-dev >>> >> > <llvm-dev at lists.llvm.org >>> >> <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org >>> >> <mailto:llvm-dev at lists.llvm.org>>> wrote: >>> >> > >>> >> > Hi, >>> >> > >>> >> > I am working on PR34474 and try to add a new >>> >> optimization to >>> >> > InstCombine. Like in other parts of the visitMul >>> >> function I >>> >> > add a Shl >>> >> > through the IR builder and create a new BinaryOp >>> which I >>> >> > return from >>> >> > visitMul. If I understand correctly the new BinaryOp >>> >> > returned from >>> >> > visitMul should replace the original Instruction in >>> the >>> >> > Worklist. >>> >> > However, I end up in an infinite loop and the >>> >> Instruction I >>> >> > try to >>> >> > replace gets scheduled again and again. What is >>> >> wrong in my >>> >> > code? >>> >> > >>> >> > // Replace X * (2^C+/-1) with (X << C) -/+ X >>> >> > APInt Plus1 = *IVal + 1; >>> >> > APInt Minus1 = *IVal - 1; >>> >> > int isPow2 = Plus1.isPowerOf2() ? 1 : >>> >> Minus1.isPowerOf2() ? >>> >> > -1 : 0; >>> >> > >>> >> > if (isPow2) { >>> >> > APInt &Pow2 = isPow2 > 0 ? Plus1 : Minus1; >>> >> > Value *Shl = Builder.CreateShl(Op0, >>> >> Pow2.logBase2()); >>> >> > return BinaryOperator::Create(isPow2 > 0 ? >>> >> > BinaryOperator::Sub : >>> >> > BinaryOperator::Add, Shl, Op0); >>> >> > } >>> >> > >>> >> > Thanks, >>> >> > Michael >>> >> >>> > >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170919/a553ed58/attachment.html>
Haidl, Michael via llvm-dev
2017-Sep-20 10:17 UTC
[llvm-dev] Updating LLVM Tests for Patch
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 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 > <https://reviews.llvm.org/rL313631> ), then it's easy to observe the > diffs by re-running that script after your code patch is applied: > $ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc > lea-3.ll > $ svn diff lea-3.llAs described by Sanjay in the original thread, I updated the llc tests but some of the tests were not updated. For example: CodeGen/X86/lea-3.ll produces the following output: llvm/utils/update_llc_test_checks.py --llc=/home/dev/local/bin/llc CodeGen/X86/lea-3.ll WARNING: Found conflicting asm under the same prefix: 'CHECK'! WARNING: Found conflicting asm under the same prefix: 'CHECK'! WARNING: Found conflicting asm under the same prefix: 'CHECK'! leaving parts of the test unchanged and the tests still fail. Other tests like CodeGen/AArch64/aarch64-gep-opt.ll results in: WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -mattr=-use-aa -print-after=codegenprepare < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -mattr=+use-aa -print-after=codegenprepare < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cyclone < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cortex-a53 < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s And the worst thing I witnessed was with the Hexagon back-end were my changes in DAGCombiner trigger an Unreachable: home/dev/llvm/build/./bin/llc -march=hexagon -mcpu=hexagonv5 -disable-hsdr < /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll | /home/dev/llvm/build/./bin/FileCheck /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll -- Exit Code: 2 Command Output (stderr): -- ReplaceNodeResults not implemented for this target! UNREACHABLE executed at /home/dev/llvm/llvm/include/llvm/Target/TargetLowering.h:3164! #0 0x00007f1b2d330cfa llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x116cfa) #1 0x00007f1b2d32ea9e llvm::sys::RunSignalHandlers() (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x114a9e) #2 0x00007f1b2d32ec04 SignalHandler(int) (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x114c04) #3 0x00007f1b2c3ed7f0 (/lib/x86_64-linux-gnu/libc.so.6+0x357f0) #4 0x00007f1b2c3ed77f gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x3577f) #5 0x00007f1b2c3ef37a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3737a) #6 0x00007f1b2d2b012a (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x9612a) #7 0x00007f1b359326ec (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) #8 0x00007f1b2d6a37a6 llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) #9 0x00007f1b2d6be0d9 llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156) #11 0x00007f1b2d6a01ff llvm::SelectionDAG::LegalizeTypes() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1211ff) #12 0x00007f1b2d785d42 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x206d42) #13 0x00007f1b2d790fd8 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x211fd8) #14 0x00007f1b2d7930e2 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone .part.873] (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x2140e2) #15 0x00007f1b35931d6a (anonymous namespace)::HexagonDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x116d6a) #16 0x00007f1b2ef22585 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/dev/llvm/build/bin/../lib/libLLVMCodeGen.so.6+0x21f585) #17 0x00007f1b2e922dd3 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18ddd3) #18 0x00007f1b2e922e93 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18de93) #19 0x00007f1b2e9239e1 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18e9e1) #20 0x000055b29c4ef3e2 compileModule(char**, llvm::LLVMContext&) (/home/dev/llvm/build/./bin/llc+0x213e2) #21 0x000055b29c4e23bc main (/home/dev/llvm/build/./bin/llc+0x143bc) #22 0x00007f1b2c3d83f1 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x203f1) #23 0x000055b29c4e256a _start (/home/dev/llvm/build/./bin/llc+0x1456a) Stack dump: 0. Program arguments: /home/dev/llvm/build/./bin/llc -march=hexagon -mcpu=hexagonv5 -disable-hsdr 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Hexagon DAG->DAG Pattern Instruction Selection' on function '@run' FileCheck error: '-' is empty. FileCheck command line: /home/dev/llvm/build/./bin/FileCheck /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll How do I proceed to get the patch running all tests as expected? The Tests directly focused on the results of the patch are passing without problems. Cheers, Michael
Haidl, Michael via llvm-dev
2017-Sep-20 10:34 UTC
[llvm-dev] Updating LLVM Tests for Patch
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 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 > <https://reviews.llvm.org/rL313631> ), then it's easy to observe the > diffs by re-running that script after your code patch is applied: > $ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc > lea-3.ll > $ svn diff lea-3.llAs described by Sanjay in the original thread, I updated the llc tests but some of the tests were not updated. For example: CodeGen/X86/lea-3.ll produces the following output: llvm/utils/update_llc_test_checks.py --llc=/home/dev/local/bin/llc CodeGen/X86/lea-3.ll WARNING: Found conflicting asm under the same prefix: 'CHECK'! WARNING: Found conflicting asm under the same prefix: 'CHECK'! WARNING: Found conflicting asm under the same prefix: 'CHECK'! leaving parts of the test unchanged and the tests still fail. Other tests like CodeGen/AArch64/aarch64-gep-opt.ll results in: WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -mattr=-use-aa -print-after=codegenprepare < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -mattr=+use-aa -print-after=codegenprepare < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cyclone < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cortex-a53 < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s And the worst thing I witnessed was with the Hexagon back-end were my changes in DAGCombiner trigger an Unreachable: home/dev/llvm/build/./bin/llc -march=hexagon -mcpu=hexagonv5 -disable-hsdr < /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll | /home/dev/llvm/build/./bin/FileCheck /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll -- Exit Code: 2 Command Output (stderr): -- ReplaceNodeResults not implemented for this target! UNREACHABLE executed at /home/dev/llvm/llvm/include/llvm/Target/TargetLowering.h:3164! #0 0x00007f1b2d330cfa llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x116cfa) #1 0x00007f1b2d32ea9e llvm::sys::RunSignalHandlers() (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x114a9e) #2 0x00007f1b2d32ec04 SignalHandler(int) (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x114c04) #3 0x00007f1b2c3ed7f0 (/lib/x86_64-linux-gnu/libc.so.6+0x357f0) #4 0x00007f1b2c3ed77f gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x3577f) #5 0x00007f1b2c3ef37a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3737a) #6 0x00007f1b2d2b012a (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x9612a) #7 0x00007f1b359326ec (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) #8 0x00007f1b2d6a37a6 llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) #9 0x00007f1b2d6be0d9 llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156) #11 0x00007f1b2d6a01ff llvm::SelectionDAG::LegalizeTypes() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1211ff) #12 0x00007f1b2d785d42 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x206d42) #13 0x00007f1b2d790fd8 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x211fd8) #14 0x00007f1b2d7930e2 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone .part.873] (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x2140e2) #15 0x00007f1b35931d6a (anonymous namespace)::HexagonDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x116d6a) #16 0x00007f1b2ef22585 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/dev/llvm/build/bin/../lib/libLLVMCodeGen.so.6+0x21f585) #17 0x00007f1b2e922dd3 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18ddd3) #18 0x00007f1b2e922e93 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18de93) #19 0x00007f1b2e9239e1 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18e9e1) #20 0x000055b29c4ef3e2 compileModule(char**, llvm::LLVMContext&) (/home/dev/llvm/build/./bin/llc+0x213e2) #21 0x000055b29c4e23bc main (/home/dev/llvm/build/./bin/llc+0x143bc) #22 0x00007f1b2c3d83f1 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x203f1) #23 0x000055b29c4e256a _start (/home/dev/llvm/build/./bin/llc+0x1456a) Stack dump: 0. Program arguments: /home/dev/llvm/build/./bin/llc -march=hexagon -mcpu=hexagonv5 -disable-hsdr 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Hexagon DAG->DAG Pattern Instruction Selection' on function '@run' FileCheck error: '-' is empty. FileCheck command line: /home/dev/llvm/build/./bin/FileCheck /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll How do I proceed to get the patch running all tests as expected? The Tests directly focused on the results of the patch are passing without problems. Cheers, Michael
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 replace that multiply. Even the
x86 diffs in lea-3.ll are regressions:
-; LNX1-NEXT: leal (%rdi,%rdi,2), %eax
+; LNX1-NEXT: leal (,%rdi,4), %eax
+; LNX1-NEXT: subl %edi, %eax
I suggest taking a smaller first step by limiting the patch to cases where
the multiply is not a legal op for a target (TLI.isOperationLegal()).
3. Since the patch can cause a crash, that needs to be investigated first.
I didn't look into it, but my guess for the Hexagon crash (and probably
other targets) is that you're trying to create illegal
ops after the DAG has been legalized. So that's another potential way to
limit the scope of the patch - 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.09.2017 um 15:58 schrieb Sanjay Patel:
> > 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
> > <https://reviews.llvm.org/rL313631> ), then it's easy to
observe the
> > diffs by re-running that script after your code patch is applied:
> > $ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc
> > lea-3.ll
> > $ svn diff lea-3.ll
>
> As described by Sanjay in the original thread, I updated the llc tests
> but some of the tests were not updated.
>
> For example: CodeGen/X86/lea-3.ll produces the following output:
> llvm/utils/update_llc_test_checks.py --llc=/home/dev/local/bin/llc
> CodeGen/X86/lea-3.ll
> WARNING: Found conflicting asm under the same prefix: 'CHECK'!
> WARNING: Found conflicting asm under the same prefix: 'CHECK'!
> WARNING: Found conflicting asm under the same prefix: 'CHECK'!
>
> leaving parts of the test unchanged and the tests still fail.
>
> Other tests like CodeGen/AArch64/aarch64-gep-opt.ll results in:
> WARNING: Skipping non-FileChecked RUN line: llc -O3
> -aarch64-enable-gep-opt=true -mattr=-use-aa -print-after=codegenprepare
> < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA
<%t %s
> WARNING: Skipping non-FileChecked RUN line: llc -O3
> -aarch64-enable-gep-opt=true -mattr=+use-aa -print-after=codegenprepare
> < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA
<%t %s
> WARNING: Skipping non-FileChecked RUN line: llc -O3
> -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cyclone <
> %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t
%s
> WARNING: Skipping non-FileChecked RUN line: llc -O3
> -aarch64-enable-gep-opt=true -print-after=codegenprepare
> -mcpu=cortex-a53 < %s >%t 2>&1 && FileCheck
--check-prefix=CHECK-UseAA
> <%t %s
>
> And the worst thing I witnessed was with the Hexagon back-end were my
> changes in DAGCombiner trigger an Unreachable:
>
> home/dev/llvm/build/./bin/llc -march=hexagon -mcpu=hexagonv5
> -disable-hsdr <
> /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll |
> /home/dev/llvm/build/./bin/FileCheck
> /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll
> --
> Exit Code: 2
>
> Command Output (stderr):
> --
> ReplaceNodeResults not implemented for this target!
> UNREACHABLE executed at
> /home/dev/llvm/llvm/include/llvm/Target/TargetLowering.h:3164!
> #0 0x00007f1b2d330cfa llvm::sys::PrintStackTrace(llvm::raw_ostream&)
> (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x116cfa)
> #1 0x00007f1b2d32ea9e llvm::sys::RunSignalHandlers()
> (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x114a9e)
> #2 0x00007f1b2d32ec04 SignalHandler(int)
> (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x114c04)
> #3 0x00007f1b2c3ed7f0 (/lib/x86_64-linux-gnu/libc.so.6+0x357f0)
> #4 0x00007f1b2c3ed77f gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x3577f)
> #5 0x00007f1b2c3ef37a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3737a)
> #6 0x00007f1b2d2b012a
> (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x9612a)
> #7 0x00007f1b359326ec
> (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec)
> #8 0x00007f1b2d6a37a6
> llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool)
> (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6)
> #9 0x00007f1b2d6be0d9
> llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int)
> (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9)
> #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run()
> (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156)
> #11 0x00007f1b2d6a01ff llvm::SelectionDAG::LegalizeTypes()
> (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1211ff)
> #12 0x00007f1b2d785d42 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
> (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x206d42)
> #13 0x00007f1b2d790fd8
> llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
> (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x211fd8)
> #14 0x00007f1b2d7930e2
> llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
> [clone .part.873]
> (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x2140e2)
> #15 0x00007f1b35931d6a (anonymous
> namespace)::HexagonDAGToDAGISel::runOnMachineFunction(llvm::
> MachineFunction&)
> (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x116d6a)
> #16 0x00007f1b2ef22585
> llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
> (/home/dev/llvm/build/bin/../lib/libLLVMCodeGen.so.6+0x21f585)
> #17 0x00007f1b2e922dd3
> llvm::FPPassManager::runOnFunction(llvm::Function&)
> (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18ddd3)
> #18 0x00007f1b2e922e93 llvm::FPPassManager::runOnModule(llvm::Module&)
> (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18de93)
> #19 0x00007f1b2e9239e1
llvm::legacy::PassManagerImpl::run(llvm::Module&)
> (/home/dev/llvm/build/bin/../lib/libLLVMCore.so.6+0x18e9e1)
> #20 0x000055b29c4ef3e2 compileModule(char**, llvm::LLVMContext&)
> (/home/dev/llvm/build/./bin/llc+0x213e2)
> #21 0x000055b29c4e23bc main (/home/dev/llvm/build/./bin/llc+0x143bc)
> #22 0x00007f1b2c3d83f1 __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x203f1)
> #23 0x000055b29c4e256a _start (/home/dev/llvm/build/./bin/llc+0x1456a)
> Stack dump:
> 0. Program arguments: /home/dev/llvm/build/./bin/llc -march=hexagon
> -mcpu=hexagonv5 -disable-hsdr
> 1. Running pass 'Function Pass Manager' on module
'<stdin>'.
> 2. Running pass 'Hexagon DAG->DAG Pattern Instruction
Selection' on
> function '@run'
> FileCheck error: '-' is empty.
> FileCheck command line: /home/dev/llvm/build/./bin/FileCheck
> /home/dev/llvm/llvm/test/CodeGen/Hexagon/vect/vect-cst-v4i32.ll
>
> How do I proceed to get the patch running all tests as expected? The
> Tests directly focused on the results of the patch are passing without
> problems.
>
> Cheers,
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170920/054182e9/attachment.html>