summaryrefslogtreecommitdiffstats
path: root/llvm/utils/UpdateTestChecks/asm.py
Commit message (Collapse)AuthorAgeFilesLines
* [ARM] Add armv8a triple to test check updatersOliver Stannard2019-03-011-0/+1
| | | | llvm-svn: 355186
* [NFC] Fix the regular expression for BE PPC in update_llc_test_checks.pyNemanja Ivanovic2018-10-261-0/+1
| | | | | | | | | Currently, the regular expression that matches the lines of assembly for PPC LE (ELFv2) does not work for the assembly for BE (ELFv1). This patch fixes it. Differential revision: https://reviews.llvm.org/D53059 llvm-svn: 345363
* Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC code ↵Reid Kleckner2018-07-231-2/+3
| | | | | | | | | | | | | | models" Don't try to generate large PIC code for non-ELF targets. Neither COFF nor MachO have relocations for large position independent code, and users have been using "large PIC" code models to JIT 64-bit code for a while now. With this change, if they are generating ELF code, their JITed code will truly be PIC, but if they target MachO or COFF, it will contain 64-bit immediates that directly reference external symbols. For a JIT, that's perfectly fine. llvm-svn: 337740
* [UpdateTestChecks] Teach the x86 asm parser to skip over the functionChandler Carruth2018-07-131-1/+1
| | | | | | | | | | | | begin label emitted for some routines with personality functions and such. Without this, we don't even recognize such functions as appearing in the output and so don't attach any assertions to them. Happy to tweak this or improve it if folks w/ deeper knowledge of the asm sequences that show up here want. llvm-svn: 336987
* Revert "Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC ↵Jonas Devlieghere2018-06-281-3/+2
| | | | | | | | | | | | | code models"" Reverting because this is causing failures in the LLDB test suite on GreenDragon. LLVM ERROR: unsupported relocation with subtraction expression, symbol '__GLOBAL_OFFSET_TABLE_' can not be undefined in a subtraction expression llvm-svn: 335894
* Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC code ↵Reid Kleckner2018-06-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | models" The large code model allows code and data segments to exceed 2GB, which means that some symbol references may require a displacement that cannot be encoded as a displacement from RIP. The large PIC model even relaxes the assumption that the GOT itself is within 2GB of all code. Therefore, we need a special code sequence to materialize it: .LtmpN: leaq .LtmpN(%rip), %rbx movabsq $_GLOBAL_OFFSET_TABLE_-.LtmpN, %rax # Scratch addq %rax, %rbx # GOT base reg From that, non-local references go through the GOT base register instead of being PC-relative loads. Local references typically use GOTOFF symbols, like this: movq extern_gv@GOT(%rbx), %rax movq local_gv@GOTOFF(%rbx), %rax All calls end up being indirect: movabsq $local_fn@GOTOFF, %rax addq %rbx, %rax callq *%rax The medium code model retains the assumption that the code segment is less than 2GB, so calls are once again direct, and the RIP-relative loads can be used to access the GOT. Materializing the GOT is easy: leaq _GLOBAL_OFFSET_TABLE_(%rip), %rbx # GOT base reg DSO local data accesses will use it: movq local_gv@GOTOFF(%rbx), %rax Non-local data accesses will use RIP-relative addressing, which means we may not always need to materialize the GOT base: movq extern_gv@GOTPCREL(%rip), %rax Direct calls are basically the same as they are in the small code model: They use direct, PC-relative addressing, and the PLT is used for calls to non-local functions. This patch adds reasonably comprehensive testing of LEA, but there are lots of interesting folding opportunities that are unimplemented. I restricted the MCJIT/eh-lg-pic.ll test to Linux, since the large PIC code model is not implemented for MachO yet. Differential Revision: https://reviews.llvm.org/D47211 llvm-svn: 335508
* Revert r335297 "[X86] Implement more of x86-64 large and medium PIC code models"Reid Kleckner2018-06-211-3/+2
| | | | | | MCJIT can't handle R_X86_64_GOT64 yet. llvm-svn: 335300
* [X86] Implement more of x86-64 large and medium PIC code modelsReid Kleckner2018-06-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The large code model allows code and data segments to exceed 2GB, which means that some symbol references may require a displacement that cannot be encoded as a displacement from RIP. The large PIC model even relaxes the assumption that the GOT itself is within 2GB of all code. Therefore, we need a special code sequence to materialize it: .LtmpN: leaq .LtmpN(%rip), %rbx movabsq $_GLOBAL_OFFSET_TABLE_-.LtmpN, %rax # Scratch addq %rax, %rbx # GOT base reg From that, non-local references go through the GOT base register instead of being PC-relative loads. Local references typically use GOTOFF symbols, like this: movq extern_gv@GOT(%rbx), %rax movq local_gv@GOTOFF(%rbx), %rax All calls end up being indirect: movabsq $local_fn@GOTOFF, %rax addq %rbx, %rax callq *%rax The medium code model retains the assumption that the code segment is less than 2GB, so calls are once again direct, and the RIP-relative loads can be used to access the GOT. Materializing the GOT is easy: leaq _GLOBAL_OFFSET_TABLE_(%rip), %rbx # GOT base reg DSO local data accesses will use it: movq local_gv@GOTOFF(%rbx), %rax Non-local data accesses will use RIP-relative addressing, which means we may not always need to materialize the GOT base: movq extern_gv@GOTPCREL(%rip), %rax Direct calls are basically the same as they are in the small code model: They use direct, PC-relative addressing, and the PLT is used for calls to non-local functions. This patch adds reasonably comprehensive testing of LEA, but there are lots of interesting folding opportunities that are unimplemented. Reviewers: chandlerc, echristo Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D47211 llvm-svn: 335297
* [Utils] update_llc_test_checks.py: support AMDGPU backend: AMDGCN, r600 triplesRoman Lebedev2018-06-111-0/+19
| | | | | | | | | | | | | | | | | | | | | | | Summary: Lack of that support has taken me by surprise. I need to add (or at least look at) some tests for https://reviews.llvm.org/D47980#1127615, and i don't really fancy doing that by hand. The asm pattern is quite similar to that of x86: https://godbolt.org/g/hfgeds just with `#` replaced with `;` Reviewers: spatel, RKSimon, MaskRay, tstellar, arsenm Reviewed By: arsenm Subscribers: arsenm, kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, rampitec, bogner, mareko, llvm-commits Tags: #amdgpu Differential Revision: https://reviews.llvm.org/D48001 llvm-svn: 334396
* [Utils][X86] Help update_llc_test_checks.py to recognise retl/retq to reduce ↵Simon Pilgrim2018-06-011-1/+1
| | | | | | | | | | | | | | | | CHECK duplication (PR35003) This patch replaces the --x86_extra_scrub command line argument to automatically support a second level of regex-scrubbing if it improves the matching of nearly-identical code patterns. The argument '--extra_scrub' is there now to force extra matching if required. This is mostly useful to help us share 32-bit/64-bit x86 vector tests which only differs by retl/retq instructions, but any scrubber can now technically support this, meaning test checks don't have to be needlessly obfuscated. I've updated some of the existing checks that had been manually run with --x86_extra_scrub, to demonstrate the extra "ret{{[l|q]}}" scrub now only happens when useful, and re-run the sse42-intrinsics file to show extra matches - most sse/avx intrinsics files should be able to now share 32/64 checks. Tested with the opt/analysis scripts as well which share common code - AFAICT the other update scripts use their own versions. Differential Revision: https://reviews.llvm.org/D47485 llvm-svn: 333749
* [utils] improve AArch64 asm parserSanjay Patel2018-04-201-1/+1
| | | | | | | | If we don't mark the cfi line as optional, the script won't work with 'nounwind' code. Without that attr, there may be extra noise in the asm body that we don't want to see. llvm-svn: 330453
* Add SPARC support to update_llc_test_checks.pyDaniel Cederman2018-04-201-0/+18
| | | | | | | | | | | | Reviewers: spatel, jyknight Reviewed By: spatel Subscribers: fedor.sergeev, llvm-commits Differential Revision: https://reviews.llvm.org/D45809 llvm-svn: 330401
* [UpdateTestChecks] Add update_analyze_test_checks.py for cost model analysis ↵Simon Pilgrim2018-04-061-1/+1
| | | | | | | | | | | | | | generation The script allows the auto-generation of checks for cost model tests to speed up their creation and help improve coverage, which will help a lot with PR36550. If the need arises we can add support for other analyze passes as well, but the cost models was the one I needed to get done - at the moment it just warns that any other analysis mode is unsupported. I've regenerated a couple of x86 test files to show the effect. Differential Revision: https://reviews.llvm.org/D45272 llvm-svn: 329390
* [UpdateTestChecks] Moved core functionality of add_asm_checks into add_checksSimon Pilgrim2018-04-051-23/+1
| | | | | | As discussed on D45272 llvm-svn: 329270
* [UpdateTestChecks] Make add_asm_checks more like add_ir_checksSimon Pilgrim2018-04-051-5/+8
| | | | | | Towards merging them as mentioned on D45272 llvm-svn: 329265
* [x86] Fix a pretty obvious think-o with my asm scrubbing. You have to inChandler Carruth2018-04-031-1/+1
| | | | | | | | | | fact use regular expression syntax to use regular expressions. Should restore the bots. Sorry for the noise on this test. Thanks to Philip for spotting the bug! llvm-svn: 329057
* [x86] Extend my goofy SP offset scrubbing for llc test cases to actuallyChandler Carruth2018-04-031-0/+7
| | | | | | | | | | | | | | | do explicit scrubbing of the offsets of stack spills and reloads. You can always turn this off in order to test specific stack slot usage. We were already hiding most of this, but the new logic hides it more generically. Notably, we should effectively hide stack slot churn in functions that have a frame pointer now, and should also hide it when changing a function from stack pointer to frame pointer. That transition already changes enough to be clearly noticed in the test case diff, showing *every* spill and reload is really noisy without benefit. See the test case I ran this on as a classic example. llvm-svn: 329055
* [utils] Add utils/update_cc_test_checks.pyFangrui Song2018-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A utility to update LLVM IR in C/C++ FileCheck test files. Example RUN lines in .c/.cc test files: // RUN: %clang -S -Os -DXX %s -o - | FileCheck %s // RUN: %clangxx -S -Os %s -o - | FileCheck -check-prefix=IR %s Usage: % utils/update_cc_test_checks.py --llvm-bin=release/bin test/a.cc % utils/update_cc_test_checks.py --c-index-test=release/bin/c-index-test --clang=release/bin/clang /tmp/c/a.cc // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py // RUN: %clang -emit-llvm -S -Os -DXX %s -o - | FileCheck -check-prefix=AA %s // RUN: %clangxx -emit-llvm -S -Os %s -o - | FileCheck -check-prefix=BB %s using T = #ifdef XX int __attribute__((vector_size(16))) #else short __attribute__((vector_size(16))) #endif ; // AA-LABEL: _Z3fooDv4_i: // AA: entry: // AA-NEXT: %add = shl <4 x i32> %a, <i32 1, i32 1, i32 1, i32 1> // AA-NEXT: ret <4 x i32> %add // // BB-LABEL: _Z3fooDv8_s: // BB: entry: // BB-NEXT: %add = shl <8 x i16> %a, <i16 1, i16 1, i16 1, i16 1, i16 1, i16 1, i16 1, i16 1> // BB-NEXT: ret <8 x i16> %add T foo(T a) { return a + a; } Differential Revision: https://reviews.llvm.org/D42712 llvm-svn: 326591
* [utils] Refactor utils/update_{,llc_}test_checks.py to share more codeFangrui Song2018-02-101-1/+35
| | | | | | | | | | | | | | Summary: This revision refactors 1. parser 2. CHECK line adder of utils/update_{,llc_}test_checks.py so that thir functionality can be re-used by other utility scripts (e.g. D42712) Reviewers: asb, craig.topper, RKSimon, echristo Subscribers: llvm-commits, spatel Differential Revision: https://reviews.llvm.org/D42805 llvm-svn: 324803
* [utils] De-duplicate utils/update_{llc_,}test_checks.pyFangrui Song2018-01-301-0/+199
Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42654 llvm-svn: 323718
OpenPOWER on IntegriCloud