search for: update_llc_test_checks

Displaying 20 results from an estimated 28 matches for "update_llc_test_checks".

2019 Dec 11
3
Weird update_llc_test_checks behavior?
I've run update_llc_test_checks on a set of tests and am seeing some weird behavior. The CHECK lines appear directly after the function's first line, even if there are multiple arguments. E.g.: define <vscale x 4 x i32> @sel_nxv4i32(<vscale x 4 x i1> %p, ; CHECK-LABEL: sel_nxv4i32: ; CHECK: // %bb.0: ; CHEC...
2017 Sep 20
3
Updating LLVM Tests for Patch
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 cove...
2017 Sep 20
0
Updating LLVM Tests for Patch
...t; 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/...
2017 Sep 22
0
[Hexagon] Type Legalization
...on and the unreachable is trigged. Is this really working as intended or am I missing something here? Cheers, Michael On 20.09.2017 16:10, Sanjay Patel wrote: > 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...
2017 Sep 19
5
How to add optimizations to InstCombine correctly?
...is 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 a...
2017 Sep 22
2
[Hexagon] Type Legalization
...his really working as intended or am I missing something here? > > Cheers, > Michael > > On 20.09.2017 16:10, Sanjay Patel wrote: > > 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....
2018 Aug 06
2
[PATCH] D50328: [X86][SSE] Combine (some) target shuffles with multiple uses
...CHECK-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0 > ---------------- > greened wrote: >> Can we make this test less brittle by using FileCheck variables? >> This goes for pretty much every test in this patch. > I'm sorry but no - its been repeatedly proven that using > update_llc_test_checks.py on the majority of x86 tests is the way > forward - it speeds up creation of tests (x86 by far has the highest > test coverage), makes regeneration of checks trivial and it prevents > dodgy code being 'hidden' (either on purpose or by > accident). Additionally many x86 subtar...
2017 Sep 22
0
[Hexagon] Type Legalization
...am I missing something here? > > Cheers, > Michael > > On 20.09.2017 16:10, Sanjay Patel wrote: > > 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 op...
2017 Sep 19
0
How to add optimizations to InstCombine correctly?
...is 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 a...
2018 May 04
0
RFC: Are auto-generated assertions a good practice?
...be problematic for very large test cases that are likely to see churn due to scheduling or regallloc changes. Being able to regenerate the CHECK lines and view the diff is also incredibly helpful when rebasing or moving a patch between different branches. My policy for test/Codegen/RISCV is to use update_llc_test_checks.py wherever possible, except in cases where there are so many CHECK lines on the output that they obscure the property being tested, indicating that a more limited hand-crafted pattern would be superior. Best, Alex
2018 May 04
2
RFC: Are auto-generated assertions a good practice?
...large test cases that are likely to see churn due to scheduling or > regallloc changes. Being able to regenerate the CHECK lines and view > the diff is also incredibly helpful when rebasing or moving a patch > between different branches. > > My policy for test/Codegen/RISCV is to use update_llc_test_checks.py > wherever possible, except in cases where there are so many CHECK lines > on the output that they obscure the property being tested, indicating > that a more limited hand-crafted pattern would be superior. > > Best, > > Alex > ____________________________________________...
2018 May 04
2
RFC: Are auto-generated assertions a good practice?
Hello llvm-dev, On a recent code review I was asked to auto-generate assertion checks for my unit test. I wasn't aware that this was even possible. I am referring to the python `update` scripts under `utils` directory. My first reaction was wow! I found it very practical and useful. It saves you significant amount of time when writing a regression test. So I gave it a try. The generated
2015 Oct 09
3
Python version for scripts in LLVM?
...for j in s] for i, s in enumerate(shuffles)] if len(results) != 1: - print >>sys.stderr, 'ERROR: Bad results: %s' % (results,) + print('ERROR: Bad results: %s' % (results,), file=sys.stderr) sys.exit(1) result = results[0] Index: update_llc_test_checks.py =================================================================== --- update_llc_test_checks.py (revision 249819) +++ update_llc_test_checks.py (working copy) @@ -6,7 +6,7 @@ FileCheck patterns. It can either update all of the tests in the file or a single test function. """...
2019 Mar 08
2
Writing unit tests - how to test re-orderable blocks...
...ocks in the same test > differently each time? > If it is *NOT* deterministic, then it is most certainly a bug that > should be reported. > If it is deterministic, (answer without backend-specific knowledge) it > might be best not to worry about this, > and just use the llvm/utils/update_llc_test_checks.py to simplify > updating of the tests. > >> Can anyone offer advice? >> >> Carl > Roman. > >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mai...
2019 Oct 10
3
[cfe-dev] RFC: End-to-end testing
...jority are not. A test that, for example, checks the entire generated asm for a match is indeed very fragile. A test that checks whether a specific instruction/mnemonic was emitted is generally not, at least in my experience. End-to-end tests require some care in construction. I don't think update_llc_test_checks.py-type operation is desirable. Still, you raise a valid point and I think present some good options below. > A couple of approaches we could consider: > > 1. Simply restrict end to end tests to crash/assert cases.  (i.e. no > property of the generated code is checked, other than...
2018 May 04
0
RFC: Are auto-generated assertions a good practice?
...t are likely to see churn due to scheduling or >> regallloc changes. Being able to regenerate the CHECK lines and view >> the diff is also incredibly helpful when rebasing or moving a patch >> between different branches. >> >> My policy for test/Codegen/RISCV is to use update_llc_test_checks.py >> wherever possible, except in cases where there are so many CHECK lines >> on the output that they obscure the property being tested, indicating >> that a more limited hand-crafted pattern would be superior. >> >> Best, >> >> Alex >> ____________...
2018 May 04
2
RFC: Are auto-generated assertions a good practice?
...churn due to scheduling or >>> regallloc changes. Being able to regenerate the CHECK lines and view >>> the diff is also incredibly helpful when rebasing or moving a patch >>> between different branches. >>> >>> My policy for test/Codegen/RISCV is to use update_llc_test_checks.py >>> wherever possible, except in cases where there are so many CHECK lines >>> on the output that they obscure the property being tested, indicating >>> that a more limited hand-crafted pattern would be superior. >>> >>> Best, >>> >>&gt...
2017 Sep 19
0
How to add optimizations to InstCombine correctly?
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:
2018 May 04
0
RFC: Are auto-generated assertions a good practice?
...ing or >>>> regallloc changes. Being able to regenerate the CHECK lines and view >>>> the diff is also incredibly helpful when rebasing or moving a patch >>>> between different branches. >>>> >>>> My policy for test/Codegen/RISCV is to use update_llc_test_checks.py >>>> wherever possible, except in cases where there are so many CHECK lines >>>> on the output that they obscure the property being tested, indicating >>>> that a more limited hand-crafted pattern would be superior. >>>> >>>> Best, >...
2016 Dec 26
0
LLVM Weekly - #156, Dec 26th 2016
...vm.org/rL290346). * GlobalISel implementation work continues, with the addition of a basic tablegen backend. [r290284](http://reviews.llvm.org/rL290284). * A POWER9 processor model was added for scheduling. [r290102](http://reviews.llvm.org/rL290102). * ARM and PPC support has been added to the `update_llc_test_checks.py` script. [r290144](http://reviews.llvm.org/rL290144), [r290370](http://reviews.llvm.org/rL290370). * The GlobPattern class has been imported into LLVM from LLD. [r290212](http://reviews.llvm.org/rL290212). * Codegen for the x86 vectorcall calling convention has landed. [r290240](http://reviews...