These lit configuration files are really Python source code. Using the
.py file extension helps editors and tools use the correct language
mode. LLVM and Clang already use this convention for lit configuration,
this change simply applies it to all of compiler-rt.
Reviewers: vitalybuka, dberris
Differential Revision: https://reviews.llvm.org/D63658
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364591 91177308-0d34-0410-b5e6-96231b3b80d8
- Merge r364427 (GSYM lib) more: It was missing the new unit test
(as pointed out by llvm/utils/gn/build/sync_source_lists_from_cmake.py),
and it had some superfluous deps not present in the cmake build.
- Merge r364474 (clang DependencyScanning lib) more: The deps didn't
quite match cmake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364501 91177308-0d34-0410-b5e6-96231b3b80d8
This allows later passes (in particular InstCombine) to optimize more
cases.
One that's important to us is `memcmp(p, q, constant) < 0` and memcmp(p, q, constant) > 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364412 91177308-0d34-0410-b5e6-96231b3b80d8
r363233 rewrote a bunch of the Intrin Emitter code, however the new
function to update the arg codes did not properly consider a pointer to
an any. This patch adds that logic.
Differential Revision: https://reviews.llvm.org/D63507
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364364 91177308-0d34-0410-b5e6-96231b3b80d8
When I executed gn.py gen out/gn I got the following error:
ERROR at //compiler-rt/lib/builtins/BUILD.gn:162:7: Only source, header, and object files belong in the sources of a static_library. //compiler-rt/lib/builtins/emutls.c is not one of the valid types.
"emutls.c ",
^----------
See //compiler-rt/lib/BUILD.gn:3:5: which caused the file to be included.
"//compiler-rt/lib/builtins",
^---------------------------
It turns out to be that the latest gn doesn't accept ill-format file name. And the emutls.c above has a trailing space.
Remove the trailing space should work.
Patch By: myhsu
Differential Revision: https://reviews.llvm.org/D63449
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364162 91177308-0d34-0410-b5e6-96231b3b80d8
Simple little utility which takes a opt logfile generated with "opt -print-before-all -print-module-scope -o /dev/null <args> 2&>1", and splits into a series of individual "chunk-X.ll" files. The intended purpose is to help automate one step in failure reduction.
The imagined workflow is:
New crasher bug reported against clang or other frontend
Frontend run with -emit-llvm equivalent and manually confirmed that opt -O2 <emit.ll> crashes
Run this splitter script
Manually map pass name to invocation command (next on the to automate list)
Run bugpoint on last chunk file + manual command
I chose to dump every chunk rather than only the last since miscompile debugging frequently requires either manual step by step reduction, or cross feeding IR into different compiler versions. Not an immediate target, but there may be applications.
Differential Revision: https://reviews.llvm.org/D63461
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363884 91177308-0d34-0410-b5e6-96231b3b80d8
It seems macOS lets you have ArrayRef<const X> even though this is apparently
forbidden by the language standard (Thanks MSVC++ for the clear error message).
Removed the problematic const's to fix this.
(It also seems I'm not receiving buildbot emails anymore and I'm trying to find
out why. In the mean time I'll be polling lab.llvm.org to hopefully see if/when
failures occur)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363753 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add an AdditionalEncoding class which can be used to define additional encodings
for a given instruction. This causes the disassembler to add an additional
encoding to its matching tables that map to the specified instruction.
Usage:
def ADD1 : Instruction {
bits<8> Reg;
bits<32> Inst;
let Size = 4;
let Inst{0-7} = Reg;
let Inst{8-14} = 0;
let Inst{15} = 1; // Continuation bit
let Inst{16-31} = 0;
...
}
def : AdditionalEncoding<ADD1> {
bits<8> Reg;
bits<16> Inst; // You can also have bits<32> and it will still be a 16-bit encoding
let Size = 2;
let Inst{0-3} = 0;
let Inst{4-7} = Reg;
let Inst{8-15} = 0;
...
}
with those definitions, llvm-mc will successfully disassemble both of these:
0x01 0x00
0x10 0x80 0x00 0x00
to:
ADD1 r1
Depends on D52366
Reviewers: bogner, charukcs
Reviewed By: bogner
Subscribers: nlguillemot, nhaehnle, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D52369
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363744 91177308-0d34-0410-b5e6-96231b3b80d8
When running LLDB lit tests on Windows, the system selects a debug version
of Python, which was issuing lots of ResourceWarnings about files that
weren't closed. There are two kinds of them, and each test triggered one
of each.
This patch fixes one kind by ensuring TestRunner explicitly close the
temporary files created for routing stderr. This is important on Windows
but has no net effect on Posix systems.
The remaining ResourceWarnings are more elusive; the bug may lie in
the Python library subprocess.py, and it may be Windows-specific.
Differential Revision: https://reviews.llvm.org/D63102
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363700 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363656 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363452 91177308-0d34-0410-b5e6-96231b3b80d8
The NVPTX target is a bit unusual in that it's the only target without a
disassembler, and one of three targets without an asm parser (and the
first one of those three in the gn build). NVPTX doesn't have those
because it's not a binary format.
The CMake build checks for the existence of
{AsmParser,Disassembler}/CMakeLists.txt when setting
LLVM_ENUM_ASM_PARSERS / LLVM_ENUM_DISASSEBLERS
(http://llvm-cs.pcc.me.uk/CMakeLists.txt#744). The GN build doesn't want
to hit the disk for things like this, so instead I'm adding explicit
`targets_with_asm_parsers` and `targets_with_disassemblers` lists. Since
both are needed rarely, they are defined in their own gni files.
Differential Revision: https://reviews.llvm.org/D63210
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363437 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the cycle between MCTargetDesc and TargetInfo is gone
(see revisions 360709 360718 360722 360724 360726 360731 360733 360735 360736),
remove the dependency from TargetInfo on MCTargetDesc:tablegen. In most
targets, this makes MCTargetDesc:tablegen have just a single use, so
inline it there.
For AArch64, ARM, and RISCV there's still a similar cycle between
MCTargetDesc and Utils, so the MCTargetDesc:tablegen indirection is
still needed there.
Differential Revision: https://reviews.llvm.org/D63200
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363436 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure that the bash script written by lit TestRunner is open with UTF-8
encoding when using Python 3. Otherwise, attempt to write non-ASCII
characters causes UnicodeEncodeError. This happened e.g. with
the following LLD test:
UNRESOLVED: lld :: ELF/format-binary-non-ascii.s (657 of 2119)
******************** TEST 'lld :: ELF/format-binary-non-ascii.s' FAILED ********************
Exception during script execution:
Traceback (most recent call last):
File "/home/mgorny/llvm-project/llvm/utils/lit/lit/worker.py", line 63, in _execute_test
result = test.config.test_format.execute(test, lit_config)
File "/home/mgorny/llvm-project/llvm/utils/lit/lit/formats/shtest.py", line 25, in execute
self.execute_external)
File "/home/mgorny/llvm-project/llvm/utils/lit/lit/TestRunner.py", line 1644, in executeShTest
res = _runShTest(test, litConfig, useExternalSh, script, tmpBase)
File "/home/mgorny/llvm-project/llvm/utils/lit/lit/TestRunner.py", line 1590, in _runShTest
res = executeScript(test, litConfig, tmpBase, script, execdir)
File "/home/mgorny/llvm-project/llvm/utils/lit/lit/TestRunner.py", line 1157, in executeScript
f.write('{ ' + '; } &&\n{ '.join(commands) + '; }')
UnicodeEncodeError: 'ascii' codec can't encode character '\xa3' in position 274: ordinal not in range(128)
Differential Revision: https://reviews.llvm.org/D63254
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363388 91177308-0d34-0410-b5e6-96231b3b80d8
Merging the two bits shrinks the context table from 16384 bytes to 8192 bytes.
Remove the ATTRIBUTE_BITS macro and just create an enum directly. Then fix the ATTR_max define to be 8192 to reflect the table size so we stop hardcoding it separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363330 91177308-0d34-0410-b5e6-96231b3b80d8
