Summary: This helps to avoid worries about the "dry run flag" while testing.
Reviewers: jyknight, rnk, mehdi_amini
Subscribers: bollu, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64697
llvm-svn: 366023
for 'test-suite', 'lnt', 'zorg', and 'www'.
This is done by looking at the pathname of the git remote named
'origin', which is not 100% reliable, but should work in most cases.
llvm-svn: 365917
When only building targets without assembly parsers (e.g. `llvm_targets_to_build
= ["NVPTX"]`), `all_targets` is empty and causes GN to warn about an
assigned-but-unused variable.
Differential Revision: https://reviews.llvm.org/D31727
llvm-svn: 365897
Summary:
This improves readability of LIT output: previously
error messages gets emitted that say that there was no error:
error: command reached timeout: False
Patch by Alexey Sachkov.
Reviewers: ddunbar, mgorny, modocache
Reviewed By: mgorny
Subscribers: delcypher, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64240
llvm-svn: 365895
Summary:
Recently I ran into the following issue:
./update_test_checks.py /path/not-existing-file.ll
The script was silent and I was suprised why the real test file hadn't been updated.
Solution:
Emit warning if we detect this problem.
Reviewers: lebedev.ri, spatel, jdoerfert, nikic
Reviewed By: lebedev.ri, spatel, jdoerfert, nikic
Subscribers: jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64572
llvm-svn: 365818
Similar to `FILECHECK_OPTS` for FileCheck, `LIT_OPTS` makes it easy to
adjust lit behavior when running the test suite via ninja. For
example:
```
$ LIT_OPTS='--time-tests -vv --filter=threadprivate' \
ninja check-clang-openmp
```
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D64135
llvm-svn: 365313
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
Since these are in a custom list, `gn format` doesn't automatically sort
them.
Now their order matches the CMake build.
No additions or deletions, this just sorts the files that are there.
llvm-svn: 365277
Some out of tree backend require larger vector type. Since maintaining the changes out of tree is difficult due to the many manual changes needed when adding a new type we are adding it even if no backend currently use it.
Differential Revision: https://reviews.llvm.org/D64141
Patch by Thomas Raoux!
llvm-svn: 365274
When a Tablegen instruction description uses `OperandWithDefaultOps`,
isel patterns for that instruction don't have to fill in the default
value for the operand in question. But the flip side is that they
actually //can't// override the defaults even if they want to.
This will be very inconvenient for the Arm backend, when we start
wanting to write isel patterns that generate the many MVE predicated
vector instructions, in the form with predication actually enabled. So
this small Tablegen fix makes it possible to write an isel pattern
either with or without values for a defaulted operand, and have the
default values filled in only if they are not overridden.
If all the defaulted operands come at the end of the instruction's
operand list, there's a natural way to match them up to the arguments
supplied in the pattern: consume pattern arguments until you run out,
then fill in any missing instruction operands with their default
values. But if defaulted and non-defaulted operands are interleaved,
it's less clear what to do. This does happen in existing targets (the
first example I came across was KILLGT, in the AMDGPU/R600 backend),
and of course they expect the previous behaviour (that the default for
those operands is used and a pattern argument is not consumed), so for
backwards compatibility I've stuck with that.
Reviewers: nhaehnle, hfinkel, dmgreen
Subscribers: mehdi_amini, javed.absar, tpr, kristof.beyls, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63814
llvm-svn: 365114
This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/.
This is needed to avoid a circular dependency when using the bitstream
code for parsing optimization remarks.
Since Bitcode uses Core for the IR part:
libLLVMRemarks -> Bitcode -> Core
and Core uses libLLVMRemarks to generate remarks (see
IR/RemarkStreamer.cpp):
Core -> libLLVMRemarks
we need to separate the Bitstream and Bitcode part.
For clang-doc, it seems that it doesn't need the whole bitcode layer, so
I updated the CMake to only use the bitstream part.
Differential Revision: https://reviews.llvm.org/D63899
llvm-svn: 365091
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
Disabled CMake get_git_version as it is meaningless for this in-tree
build, and hardcoded a null version.
Not using get_git_version avoids a refresh of the git index that is
executed by get_git_version. Refreshing the index can take a
considerable amount of time if the index needs to be refreshed
(particularly with the mono repo). This situation can arise when
building shared source on a host in VMs.
Differential Revision: https://reviews.llvm.org/D63925
llvm-svn: 364742
Create separate natvis ptr and int views for PointerIntPair.
These are convenient in watch Windows and will be used by
Clang visualizers to be checked in shortly
Also, removed deref views as the MSVC na format has
done the same thing natively since MSVC2013.
llvm-svn: 364723
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
llvm-svn: 364591
- 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.
llvm-svn: 364501
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.
llvm-svn: 364412
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
llvm-svn: 364364
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
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
llvm-svn: 364162
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
llvm-svn: 363884
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)
llvm-svn: 363753
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
llvm-svn: 363744
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
llvm-svn: 363700
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
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
llvm-svn: 363437
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
llvm-svn: 363436
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
llvm-svn: 363388
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.
llvm-svn: 363330
Summary:
This test fails to link shared libraries because tries to run
a copied version of clang-check to see if the mock version of libcxx
in the same directory can be loaded dynamically. Since the test is
specifically designed not to look in the default just-built lib
directory, it must be disabled when building with
BUILD_SHARED_LIBS=ON.
Currently only disabling it on Darwin and basing it on the
enable_shared flag.
Reviewed By: ilya-biryukov
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61697
llvm-svn: 363298
This patch uses the mechanism from D62995 to strengthen the
definitions of the reduction intrinsics by letting the scalar
result/accumulator type be overloaded from the vector element type.
For example:
; The LLVM LangRef specifies that the scalar result must equal the
; vector element type, but this is not checked/enforced by LLVM.
declare i32 @llvm.experimental.vector.reduce.or.i32.v4i32(<4 x i32> %a)
This patch changes that into:
declare i32 @llvm.experimental.vector.reduce.or.v4i32(<4 x i32> %a)
Which has the type-constraint more explicit and causes LLVM to check
the result type with the vector element type.
Reviewers: RKSimon, arsenm, rnk, greened, aemerson
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D62996
llvm-svn: 363240
Extend the mechanism to overload intrinsic arguments by using either
backward or forward references to the overloadable arguments.
In for example:
def int_something : Intrinsic<[LLVMPointerToElt<0>],
[llvm_anyvector_ty], []>;
LLVMPointerToElt<0> is a forward reference to the overloadable operand
of type 'llvm_anyvector_ty' and would allow intrinsics such as:
declare i32* @llvm.something.v4i32(<4 x i32>);
declare i64* @llvm.something.v2i64(<2 x i64>);
where the result pointer type is deduced from the element type of the
first argument.
If the returned pointer is not a pointer to the element type, LLVM will
give an error:
Intrinsic has incorrect return type!
i64* (<4 x i32>)* @llvm.something.v4i32
Reviewers: RKSimon, arsenm, rnk, greened
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D62995
llvm-svn: 363233
r363016 let lld-link and llvm-lib share the /machine: parsing code.
This lets llvm-cvtres share it as well.
Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't
need llvm-lib's dependencies on BinaryFormat and BitReader) and I
couldn't find a good place to put this code. Since it's just a few
lines, put it in lib/Object for now.
Differential Revision: https://reviews.llvm.org/D63120
llvm-svn: 363144
Users are exepcted to pass all .res files to the linker, which then
merges all the resource in all .res files into a tree structure and then
converts the final tree structure to a .obj file with .rsrc$01 and
.rsrc$02 sections and then links that.
If the user instead passes several .obj files containing such resources,
the correct thing to do would be to have custom code to merge the trees
in the resource sections instead of doing normal section merging -- but
link.exe rejects if multiple resource obj files are passed in with
LNK4078, so let lld-link do that too instead of silently writing broken
.rsrc sections in that case.
The only real way to run into this is if users manually convert .res
files to .obj files by running cvtres and then handing the resulting
.obj files to lld-link instead, which in practice likely never happens.
(lld-link is slightly stricter than link.exe now: If link.exe is passed
one .obj file created by cvtres, and a .res file, for some reason it
just emits a warning instead of an error and outputs strange looking
data. lld-link now errors out on mixed input like this.)
One way users could accidentally run into this is the following
scenario: If a .res file is passed to lib.exe, then lib.exe calls
cvtres.exe on the .res file before putting it in the output .lib.
(llvm-lib currently doesn't do this.)
link.exe's /wholearchive seems to only add obj files referenced from the
static library index, but lld-link current really adds all files in the
archive. So if lld-link /wholearchive is used with .lib files produced
by lib.exe and .res files were among the files handed to lib.exe, we
previously silently produced invalid output, but now we error out.
link.exe's /wholearchive semantics on the other hand mean that it
wouldn't load the resource object files from the .lib file at all.
Since this scenario is probably still an unlikely corner case,
the difference in behavior here seems fine -- and lld-link might have to
change to use link.exe's /wholearchive semantics in the future anyways.
Vaguely related to PR42180.
Differential Revision: https://reviews.llvm.org/D63109
llvm-svn: 363078
This reverts r362990 (git commit 374571301d)
This was causing linker warnings on Darwin:
ld: warning: direct access in function 'llvm::initializeEvexToVexInstPassPass(llvm::PassRegistry&)'
from file '../../lib/libLLVMX86CodeGen.a(X86EvexToVex.cpp.o)' to global weak symbol
'void std::__1::__call_once_proxy<std::__1::tuple<void* (&)(llvm::PassRegistry&),
std::__1::reference_wrapper<llvm::PassRegistry>&&> >(void*)' from file '../../lib/libLLVMCore.a(Verifier.cpp.o)'
means the weak symbol cannot be overridden at runtime. This was likely caused by different translation
units being compiled with different visibility settings.
llvm-svn: 363028
Summary:
For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF
this change makes all symbols in the target specific libraries hidden
by default.
A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these
libraries public, which is mainly needed for the definitions of the
LLVMInitialize* functions.
This patch reduces the number of public symbols in libLLVM.so by about
25%. This should improve load times for the dynamic library and also
make abi checker tools, like abidiff require less memory when analyzing
libLLVM.so
One side-effect of this change is that for builds with
LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that
access symbols that are no longer public will need to be statically linked.
Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1):
nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l
36221
nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l
26278
Reviewers: chandlerc, beanz, mgorny, rnk, hans
Reviewed By: rnk, hans
Subscribers: Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D54439
llvm-svn: 362990
Summary:
Use a set in getReqFeatures() in RISCVCompressInstEmitter instead of a map
because the index we save is not needed.
This also fixes bug 41666.
Reviewers: llvm-commits, apazos, asb, nickdesaulniers
Reviewed By: asb
Subscribers: Jim, nickdesaulniers, rbar, johnrusso, simoncook, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61412
llvm-svn: 362968
Visualizer for the simple case of APInt (uints < 2^64)
as will be required for Clang ConstantArrayType visualizer.
Also, removed obsolete VS2013 SmallVectorVisualizer as VS2013
is no longer supported.
llvm-svn: 362860
In LLDB, where tests run with the debug version of Python, we get a
series of deprecation warnings because escape sequences like `\(` are
being treated as part of the string literal rather than an escape for
the regexp pattern.
NFC intended.
Differential Revision: https://reviews.llvm.org/D62882
llvm-svn: 362846
Summary:
It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open
and POSIX compatibility mode, to work around stray macros and other
bugs in the headers provided by the system and build compiler.
This patch adds the config to cmake to build with _XOPEN_SOURCE defined
on AIX with a few exceptions. Google Test internals require access to
platform specific thread info constructs on AIX so in that case we build
with _ALL_SOURCE defined instead. Libclang also uses header which needs
_ALL_SOURCE on AIX so we leave that as is as well.
We also add building on AIX with the large file API and doing CMake
header checks with X/OPEN definitions so the results are consistent with
the environment that will be present in the build.
Reviewers: hubert.reinterpretcast, xingxue, andusy
Reviewed By: hubert.reinterpretcast
Subscribers: mgorny, jsji, cfe-commits, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D62533
llvm-svn: 362808
lib.exe doesn't allow creating .lib files with object files that have
differing machine types. Update llvm-lib to match.
The motivation is to make it possible to infer the machine type of a
.lib file in lld, so that it can warn when e.g. a 32-bit .lib file is
passed to a 64-bit link (PR38965).
Fixes PR38782.
Differential Revision: https://reviews.llvm.org/D62913
llvm-svn: 362798
The ISD::STRICT_ nodes used to implement the constrained floating-point
intrinsics are currently never passed to the target back-end, which makes
it impossible to handle them correctly (e.g. mark instructions are depending
on a floating-point status and control register, or mark instructions as
possibly trapping).
This patch allows the target to use setOperationAction to switch the action
on ISD::STRICT_ nodes to Legal. If this is done, the SelectionDAG common code
will stop converting the STRICT nodes to regular floating-point nodes, but
instead pass the STRICT nodes to the target using normal SelectionDAG
matching rules.
To avoid having the back-end duplicate all the floating-point instruction
patterns to handle both strict and non-strict variants, we make the MI
codegen explicitly aware of the floating-point exceptions by introducing
two new concepts:
- A new MCID flag "mayRaiseFPException" that the target should set on any
instruction that possibly can raise FP exception according to the
architecture definition.
- A new MI flag FPExcept that CodeGen/SelectionDAG will set on any MI
instruction resulting from expansion of any constrained FP intrinsic.
Any MI instruction that is *both* marked as mayRaiseFPException *and*
FPExcept then needs to be considered as raising exceptions by MI-level
codegen (e.g. scheduling).
Setting those two new flags is straightforward. The mayRaiseFPException
flag is simply set via TableGen by marking all relevant instruction
patterns in the .td files.
The FPExcept flag is set in SDNodeFlags when creating the STRICT_ nodes
in the SelectionDAG, and gets inherited in the MachineSDNode nodes created
from it during instruction selection. The flag is then transfered to an
MIFlag when creating the MI from the MachineSDNode. This is handled just
like fast-math flags like no-nans are handled today.
This patch includes both common code changes required to implement the
new features, and the SystemZ implementation.
Reviewed By: andrew.w.kaylor
Differential Revision: https://reviews.llvm.org/D55506
llvm-svn: 362663
A std::array is implemented as a template with an array inside a struct.
Older versions of clang, like 3.6, require an extra set of curly braces
around std::array initializations to avoid warnings.
The C++ language was changed regarding this by CWG 1270. So more modern
tool chains does not complain even if leaving out one level of braces.
llvm-svn: 362360
This changed updates the MSVC Visualizer to work with the recent change
of PointerUnion into a variadic template. As an extra bonus, we
fix some bit rot in the SmallPtrSet visualizer as well
llvm-svn: 362345
Fix the misleadingly indentation introduced in rL362064. This will get rid of
the compiler warning, and it was actually a bug. This change will be used and
tested in D62669.
llvm-svn: 362211
If an assembly instruction has to mention an input operand name twice,
for example the MVE VMOV instruction that accesses two lanes of the
same vector by writing 'vmov r1, r2, q0[3], q0[1]', then the obvious
way to write its AsmString is to include the same operand (here $Qd)
twice. But this causes the AsmMatcher generator to omit that
instruction completely from the match table, on the basis that the
generator isn't clever enough to deal with the duplication.
But you need to have _some_ way of dealing with an instruction like
this - and in this case, where the mnemonic is shared with many other
instructions that the AsmMatcher does handle, it would be very painful
to take it out of the AsmMatcher system completely.
A nicer way is to add a custom AsmMatchConverter routine, and let that
deal with the problem if the autogenerated converter can't. But that
doesn't work, because TableGen leaves the instruction out of its table
_even_ if you provide a custom converter.
Solution: this change, which makes TableGen relax the restriction on
duplicated operands in the case where there's a custom converter.
Patch by: Simon Tatham
Differential Revision: https://reviews.llvm.org/D60695
llvm-svn: 362066
This is a new special identifier which you can use as a default in
OperandWithDefaultOps. The idea is that you use it for an input
operand of an instruction that's tied to an output operand, and its
semantics are that (in the default case) the input operand's value is
not used at all.
The detailed effect is that when instruction selection emits the
instruction in the form of a pre-regalloc MachineInstr, it creates an
IMPLICIT_DEF node to use as that input.
If you're creating an MCInst with explicit register names, then the
right handling would be to set the input operand to the same register
as the output one (honouring the tie) and to add the 'undef' flag
indicating that that register is deemed to acquire a new don't-care
definition just before we read it. But I haven't done that in this
commit, because there was no need to - no Tablegen backend seems to
autogenerate default fields in an MCInst.
Patch by: Simon Tatham
Differential Revision: https://reviews.llvm.org/D60696
llvm-svn: 362064
Summary: This also normalizes the config feature that represents the windows platform to "system-windows" as opposed to having both "windows" and "system-windows"
Reviewers: asmith, probinson
Subscribers: delcypher, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61798
llvm-svn: 361998
Summary:
clangd needs them to function properly, even though they are not
strictly required for the build.
Reviewers: thakis
Reviewed By: thakis
Subscribers: MaskRay, jkorous, arphaman, llvm-commits, kadircet
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62480
llvm-svn: 361828
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
Summary:
A commit may, for some reason, have `llvm-svn:` in it multiple times. It may even take up the whole line and look identical to what gets added automatically when svn commits land in github.
To workaround this, make changes to both lookups:
1) When doing the git -> svn lookup, make sure to go through the whole message, and:
a) Only look for llvm-svn starting at the beginning of the line (excluding the whitespace that `git log` adds).
b) Take the last one (at the end of the commit message), if there are multiple matches.
2) When doing the svn -> git lookup, look through a sizeable but still reasonably small number of git commits (10k, about 4-5 months right now), and:
a) Only consider commits with the '^llvm-svn: NNNNNN' we expect, and
b) Only consider those that also follow the same git -> svn matching above. (Error if it's not exactly one commit).
Reviewers: jyknight
Reviewed By: jyknight
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60017
llvm-svn: 361532
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:
Terminology introduced by [[#]] blocks is confusing and does not
integrate well with existing terminology.
First, variables referred by [[]] blocks are called "pattern variables"
while the text a CHECK directive needs to match is called a "CHECK
pattern". This is inconsistent with variables in [[#]] blocks since
[[#]] blocks are also found in CHECK pattern yet those variables are
called "numeric variable".
Second, the replacing of both [[]] and [[#]] blocks by the value of the
variable or expression they contain is represented by a
FileCheckPatternSubstitution class. The naming refers to being a
substitution in a CHECK pattern but could be wrongly understood as being
a substitution of a pattern variable.
Third and lastly, comments use "numeric expression" to refer both to the
[[#]] blocks as well as to the numeric expressions these blocks contain
which get evaluated at match time.
This patch solves these confusions by
- calling variables in [[]] and [[#]] blocks as string and numeric
variables respectively;
- referring to [[]] and [[#]] as substitution *blocks*, with the former
being a string substitution block and the latter a numeric
substitution block;
- calling [[]] and [[#]] blocks to be replaced by the value of a
variable or expression they contain a substitution (as opposed to
definition when these blocks are used to defined a variable), with the
former being a string substitution and the latter a numeric
substitution;
- renaming the FileCheckPatternSubstitution as a FileCheckSubstitution
class with FileCheckStringSubstitution and
FileCheckNumericSubstitution subclasses;
- restricting the use of "numeric expression" to refer to the expression
that is evaluated in a numeric substitution.
While numeric substitution blocks only support numeric substitutions of
numeric expressions at the moment there are plans to augment numeric
substitution blocks to support numeric definitions as well as both a
numeric definition and numeric substitution in the same numeric
substitution block.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: hiraditya, arichardson, probinson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62146
llvm-svn: 361445
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
zlib/nozlib, asan/not_asan, msan/not_msan, ubsan/not_ubsan.
We still have two other ways to express the absence of a feature.
First, we have the '!' operator to invert the sense of a keyword. For
example, given a feature that depends on zlib being unavailable, its
test can say:
REQUIRES: !zlib
Second, if a test doesn't play well with some features, such as
sanitizers, that test can say:
UNSUPPORTED: asan, msan
The different ways of writing these exclusions both have the same
technical effect, but have different implications to the reader.
llvm-svn: 360603
The tablegen groups only need public_deps for inc files included
(possibly transitively) in other targets. Move inc files that are
internan to the MCTargetDesc libraries into regular deps.
Related to the changes that merged InstPrinter into MCTargetDesc
(360484, 360486 etc).
llvm-svn: 360600
This commit appears to be breaking stage-2 builds on GreenDragon. The
OpenMP wrappers for cmath and math.h are copied into the root of the
resource directory and cause a cyclic dependency in module 'Darwin':
Darwin -> std -> Darwin. This blows up when CMake is testing for modules
support and breaks all stage 2 module builds, including the ThinLTO bot
and all LLDB bots.
CMake Error at cmake/modules/HandleLLVMOptions.cmake:497 (message):
LLVM_ENABLE_MODULES is not supported by this compiler
llvm-svn: 360192
Nico Weber