| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces two fixes. The second fix allows to generate
a test to check the first fix.
- Output `CHECK-EMPTY` prefix for an empty line in ASM output. Before that
fix `update_llc_test_checks.py` incorrectly emits `CHECK-NEXT: <space>`
prefix.
- Fix the `ASM_FUNCTION_MIPS_RE` regex to stop on a real function
epilogue not on an inline assembler prologue and include inline
assembler code into a test.
Differential Revision: https://reviews.llvm.org/D47192
|
|
|
|
|
| |
The users of build_function_body_dictionary and add_checks need to be
adjusted after the changes in UpdateTestChecks/common.py.
|
|
|
|
| |
llvm-svn: 373605
|
|
|
|
|
|
| |
function body
llvm-svn: 367786
|
|
|
|
|
|
|
|
| |
This mirrors the change made for X86 in rL336987. Without this patch,
update_llc_test_checks will completely skip functions with personality
functions.
llvm-svn: 365297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
SCRUB_LOOP_COMMENT_RE was introduced in https://reviews.llvm.org/D31285
This works for some loops.
However, we may generate lines with loop comments only.
And since we don't scrub leading white spaces, this will leave an empty
line there, and FileCheck will complain it.
eg: llvm/test/CodeGen/PowerPC/PR35812-neg-cmpxchg.ll:27:15:
error: found empty check string with prefix 'CHECK:'
; CHECK-NEXT:
This prevented us from using the `update_llc_test_checks.py` for quite some cases.
We should still keep the comment token there, so that we can safely
scrub the loop comment without breaking FileCheck.
Reviewers: timshen, hfinkel, lebedev.ri, RKSimon
Subscribers: nemanjai, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63957
llvm-svn: 364775
|
|
|
|
|
|
|
|
|
|
|
| |
armv7-apple-darwin was not supported well, the script can't generate
checks.
https://reviews.llvm.org/D60601/new/#inline-568671
Differential Revision: https://reviews.llvm.org/D63939
llvm-svn: 364668
|
|
|
|
|
|
|
|
| |
Matching is 'lossy', triples with same prefix can be dropped.
Differential Revision: https://reviews.llvm.org/D63732
llvm-svn: 364471
|
|
|
|
|
|
|
|
|
| |
There are quite some old testcases with powerpc- triple,
we should add this triple support so that we can update them with script.
Differential Revision: https://reviews.llvm.org/D63723
llvm-svn: 364213
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The prior behavior of the triple matcher would stop
in the first matched triple. It was not possible to
create specific matches for sub-sets of a triple
(e.g aarch64-apple-darwin would never be used after
aarch64 was matched).
This patch:
1) Allows that specialized triples take priority,
considering that the string lenght of the triple
indentifies how specialized a triple is. If two
triples of same lenght match, the one matched first
prevails, preserving the old behavior.
2) Remove 20 duplicated triples of arm, thumb,
aarch64 options with same arguments, matching
the common prefix (aarch64, arm, thumb) of them.
3) Creates three new function matching regexes and
five triple options for arm64-apple-ios,
(arm|thumb)-apple-ios and thumb(v5)?-macho
Reviewers: lebedev.ri, RKSimon, MaskRay, gbedwell
Reviewed By: MaskRay
Subscribers: javed.absar, kristof.beyls, llvm-commits, carwil
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63145
llvm-svn: 363656
|
|
|
|
|
|
|
|
| |
Kernels seem to go directly to a section switch instead of emitting
.Lfunc_end. This fixes including all of the kernel metadata in the
check lines, which is undesirable most of the time.
llvm-svn: 363452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These tests are being affected by an upcoming patch,
so having an understandable (autogenerated) diff is helpful.
This target, again, prefers `-march`:
```
llvm/test/CodeGen/Hexagon$ grep -r triple | wc -l
467
llvm/test/CodeGen/Hexagon$ grep -r march | wc -l
1167
```
Reviewers: RKSimon, kparzysz
Reviewed By: kparzysz
Subscribers: xbolva00, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62867
llvm-svn: 362605
|
|
|
|
|
|
| |
-march=amdgcn support
llvm-svn: 362228
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The assembly structure most resembles the SPARC pattern:
```
.globl f6 ! -- Begin function f6
.p2align 2
.type f6,@function
f6: ! @f6
.cfi_startproc
! %bb.0:
st %fp, [--%sp]
<...>
ld -8[%fp], %fp
.Lfunc_end0:
.size f6, .Lfunc_end0-f6
.cfi_endproc
! -- End function
```
Test being affected by upcoming patch, so regenerate it.
Reviewers: RKSimon, jpienaar
Reviewed By: RKSimon
Subscribers: jyknight, fedor.sergeev, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62545
llvm-svn: 362019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Appears identical to powerpc64{,le}.
Regenerate test that is being affected by upcoming patch.
Reviewers: RKSimon
Reviewed By: RKSimon
Subscribers: nemanjai, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62339
llvm-svn: 361543
|
|
|
|
| |
llvm-svn: 361538
|
|
|
|
|
|
|
|
|
|
|
| |
Again, a mixture of march and triple, with majority being march:
llvm/test/CodeGen/Mips$ grep -ri triple | wc -l
818
llvm/test/CodeGen/Mips$ grep -ri march | wc -l
1457
llvm-svn: 361521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Another target that prefers to use `-march` in tests
```
llvm/test/CodeGen/SPARC$ grep -ri mtriple | wc -l
25
llvm/test/CodeGen/SPARC$ grep -ri march | wc -l
165
```
This test is being affected by a further patch,
so regenerate it to better visualize the changes
Reviewers: RKSimon, dcederman, gberry
Reviewed By: RKSimon
Subscribers: jyknight, fedor.sergeev, jrtc27, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62242
llvm-svn: 361381
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r360889 added new llround builtin functions. This patch adds their
signatures for the WebAssembly backend.
It also adds wasm32 support to utils/update_llc_test_checks.py, since
that's the script other targets are using for their testcases for this
feature.
Differential Revision: https://reviews.llvm.org/D62207
llvm-svn: 361327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Was looking into supporting `(srl (shl x, c1), c2)` with c1 != c2 in dagcombiner,
this test changes, but makes `update_llc_test_checks.py` unhappy.
**Many** AMDGPU tests specify `-march`, not `-mtriple`, which results in `update_llc_test_checks.py`
defaulting to x86 asm function detection heuristics, which don't work here.
I propose to fix this by adding an infrastructure to map from `-march` to `-mtriple`,
in the UpdateTestChecks tooling.
Reviewers: RKSimon, MaskRay, arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62099
llvm-svn: 361101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Was looking into supporting `(srl (shl x, c1), c2)` with c1 != c2 in dagcombiner,
this test changes, but makes `update_llc_test_checks.py` unhappy
Reviewers: RKSimon
Reviewed By: RKSimon
Subscribers: javed.absar, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62097
llvm-svn: 361100
|
|
|
|
|
|
|
|
|
|
|
| |
On mingw/i686, local labels don't start with a leading period.
Also escape the leading period, as it previously could match
any char.
Differential Revision: https://reviews.llvm.org/D61254
llvm-svn: 359497
|
|
|
|
| |
llvm-svn: 355186
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
MCJIT can't handle R_X86_64_GOT64 yet.
llvm-svn: 335300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: spatel, jyknight
Reviewed By: spatel
Subscribers: fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D45809
llvm-svn: 330401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
As discussed on D45272
llvm-svn: 329270
|
|
|
|
|
|
| |
Towards merging them as mentioned on D45272
llvm-svn: 329265
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42654
llvm-svn: 323718
|