We need to be able to load and store s128 for memcpy inlining, where we want to
generate Q register mem ops. Making these legal also requires that we add some
support in other instructions. Regbankselect should also know about these since
they have no GPR register class that can hold them, so need special handling to
live on the FPR bank.
Differential Revision: https://reviews.llvm.org/D65166
llvm-svn: 366857
This fixes the unchecked-error assertion at runtime.
Expected<T> must be checked before access or destruction. Expected<T>
value was in success state. (Note: Expected<T> values in success mode
must still be checked prior to being destroyed).
llvm-svn: 366853
On slower machines the vscode testcases were sometimes hanging:
1910 ? Sl 0:00 | \_ /usr/bin/python .../llvm/tools/lldb/test/dotest.py ... -p TestVSCode_setBreakpoints.py
2649 ? Sl 0:00 | \_ .../build/bin/lldb-vscode
2690 ? S 0:00 | \_ .../build/bin/lldb-server gdbserver --fd=9 --native-regs --setsid
2708 ? t 0:00 | \_ .../build/lldb-test-build.noindex/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.test_functionality/a.out
A reproducer of the racy bug for send_recv():
# self.send_packet(command)
#+ import time
#+ time.sleep(1)
# done = False
I guess `request_continue` was probably originally intended to be synchronous
but then it isn't and this code has been leftover there.
Differential revision: https://reviews.llvm.org/D65163
llvm-svn: 366850
This exposes better support to use a string table with a format through
an actual new remark::Format, called yaml-strtab.
This can now be used with -fsave-optimization-record=yaml-strtab.
llvm-svn: 366849
Currently PowerPC backend emits code like this:
r3 = li 0
std r3, 264(r1)
r3 = li 0
std r3, 272(r1)
This patch fixes that and other cases where a register already contains a value that is loaded so we will get:
r3 = li 0
std r3, 264(r1)
std r3, 272(r1)
Differential Revision: https://reviews.llvm.org/D64220
llvm-svn: 366840
This ports r366573 from COFF to ELF.
There are now to toString(Archive::Symbol), one doing MSVC demangling
in COFF and one doing Itanium demangling in ELF, so rename these two
to toCOFFString() and to toELFString() to not get a duplicate symbol.
Nothing ever passes a raw Archive::Symbol to CHECK(), so these not
being part of the normal toString() machinery seems ok.
There are two code paths in the ELF linker that emits this type of
diagnostic:
1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test.
2. An additional one that's only used for libcalls if there's at least
one bitcode in the link, and if the libcall symbol is lazy, and
lazily loaded from an archive (i.e. not from a lazy .o file).
(This code path was added in r339301.) Since all libcall names so far
are C symbols and never mangled, the change there is not observable
and hence not covered by tests.
Differential Revision: https://reviews.llvm.org/D65095
llvm-svn: 366836
LegalizeDAG tries to legal the DAG by legalizing nodes before
their operands.
If we create a new node, we end up legalizing it after its operands.
This prevents some of the optimizations that can be done when the
operand is a build_vector since the build_vector will have been
legalized to something else.
Differential Revision: https://reviews.llvm.org/D65132
llvm-svn: 366835
Summary:
Looks like a typo, as that function actually returns void and is used
as such in libFuzzer code as well.
Reviewers: kcc, Dor1s
Reviewed By: Dor1s
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65160
llvm-svn: 366834
The original code failed to account for the fact that one exit can have a pointer exit count without all of them having pointer exit counts. This could cause two separate bugs:
1) We might exit the loop early, and leave optimizations undone. This is what triggered the assertion failure in the reported test case.
2) We might optimize one exit, then exit without indicating a change. This could result in an analysis invalidaton bug if no other transform is done by the rest of indvars.
Note that the pointer exit counts are a really fragile concept. They show up only when we have a pointer IV w/o a datalayout to provide their size. It's really questionable to me whether the complexity implied is worth it.
llvm-svn: 366829
The description in clang-format-diff.py is more useful than the one
in `clang-format-diff -h`, so use the same description in both places.
Differential Revision: https://reviews.llvm.org/D64998
llvm-svn: 366828
Summary:
Allow IntToPtrInst to carry !dereferenceable metadata tag.
This is valid since !dereferenceable can be only be applied to
pointer type values.
Change-Id: If8a6e3c616f073d51eaff52ab74535c29ed497b4
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64954
llvm-svn: 366826
While working on https://reviews.llvm.org/D40900, two tests were failing since __clear_cache
aborted. While libgcc's __clear_cache is just empty, this only happens because
gcc (in gcc/config/sparc/sparc.c (sparc32_initialize_trampoline, sparc64_initialize_trampoline))
emits flush insns directly.
The following patch mimics that.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64496
llvm-svn: 366822
Like other ELF targets, shared objects should be linked with -z defs on Solaris.
Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64484
llvm-svn: 366821
Clang :: Headers/max_align.c currently FAILs on 64-bit SPARC:
error: 'error' diagnostics seen but not expected:
File /vol/llvm/src/clang/dist/test/Headers/max_align.c Line 12: static_assert failed due to requirement '8 == _Alignof(max_align_t)' ""
1 error generated.
This happens because SuitableAlign isn't defined for SPARCv9 unlike SPARCv8
(which uses the default of 64 bits). gcc's sparc/sparc.h has
#define BIGGEST_ALIGNMENT (TARGET_ARCH64 ? 128 : 64)
This patch sets SuitableAlign to match and updates the corresponding testcase.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64487
llvm-svn: 366820
When we select the XRO variants of loads, we can pull in very specific shifts
(of the size of an element). E.g.
```
ldr x1, [x2, x3, lsl #3]
```
This teaches GISel to handle these when they're coming from shifts
specifically.
This adds a new addressing mode function, `selectAddrModeShiftedExtendXReg`
which recognizes this pattern.
This also packs this up with `selectAddrModeRegisterOffset` into
`selectAddrModeXRO`. This is intended to be equivalent to `selectAddrModeXRO`
in AArch64ISelDAGtoDAG.
Also update load-addressing-modes to show that all of the cases here work.
Differential Revision: https://reviews.llvm.org/D65119
llvm-svn: 366819
Summary:
We falsely state inequivalence if the template parameter is a
qualified/nonquialified template in the first/second instantiation.
Also, different kinds of TemplateName should be equal if the template
decl (if available) is equal (even if the name kind is different).
Reviewers: a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64241
llvm-svn: 366818
If all the demanded elts are from one operand and are inline, then we can use the operand directly.
The changes are mainly from SSE41 targets which has blendvpd but not cmpgtq, allowing the v2i64 comparison to be simplified as we only need the signbit from alternate v4i32 elements.
llvm-svn: 366817
llvm-ar outputs a strange error message when handling archives with
members larger than 4GB due to not checking file size when passing the
value as an unsigned 32 bit integer. This overflow issue caused
malformed archives to be created.:
https://bugs.llvm.org/show_bug.cgi?id=38058
This change allows for members above 4GB and will error in a case that
is over the formats size limit, a 10 digit decimal integer.
Differential Revision: https://reviews.llvm.org/D65093
llvm-svn: 366813
If the first target region in a program calls the push_tripcount
function, libomptarget didn't handle the offload policy correctly.
This could lead to unexpected error messages as seen in
http://lists.llvm.org/pipermail/openmp-dev/2019-June/002561.html
To solve this, add a check calling IsOffloadDisabled() as all other
entry points already do. If this method returns false, libomptarget
is effectively disabled.
Differential Revision: https://reviews.llvm.org/D64626
llvm-svn: 366810
While lowering test.set.loop.iterations, it wasn't checked how the
brcond was using the result and so the wls could branch to the loop
preheader instead of not entering it. The same was true for
loop.decrement.reg.
So brcond and br_cc and now lowered manually when using the hwloop
intrinsics. During this we now check whether the result has been
negated and whether we're using SETEQ or SETNE and 0 or 1. We can
then figure out which basic block the WLS and LE should be targeting.
Differential Revision: https://reviews.llvm.org/D64616
llvm-svn: 366809
Under certain execution conditions, the `not` command binds to the command the
output is piped to rather than the command piping the output. In this case, that
flips the return code of the FileCheck invocation, causing a failure when
FileCheck succeeds.
llvm-svn: 366805
It would be already handled by the non-inverted case if we were hoisting
the `not` in InstCombine, but we don't (granted, we don't sink it
in this case either), so this is a separate case.
llvm-svn: 366801
This way it will be more obvious that the problem is both
in cost threshold and in hardcoded benefit check,
plus will show how the instsimplify cleans this all in the end.
llvm-svn: 366800
This patch introduces the DAG version of SimplifyMultipleUseDemandedBits, which attempts to peek through ops (mainly and/or/xor so far) that don't contribute to the demandedbits/elts of a node - which means we can do this even in cases where we have multiple uses of an op, which normally requires us to demanded all bits/elts. The intention is to remove a similar instruction - SelectionDAG::GetDemandedBits - once SimplifyMultipleUseDemandedBits has matured.
The InstCombine version of SimplifyMultipleUseDemandedBits can constant fold which I haven't added here yet, and so far I've only wired this up to some basic binops (and/or/xor/add/sub/mul) to demonstrate its use.
We do see a couple of regressions that need to be addressed:
AMDGPU unsigned dot product codegen retains an AND mask (for ZERO_EXTEND) that it previously removed (but otherwise the dotproduct codegen is a lot better).
X86/AVX2 has poor handling of vector ANY_EXTEND/ANY_EXTEND_VECTOR_INREG - it prematurely gets converted to ZERO_EXTEND_VECTOR_INREG.
The code owners have confirmed its ok for these cases to fixed up in future patches.
Differential Revision: https://reviews.llvm.org/D63281
llvm-svn: 366799
A side effect of this commit was that it exchanged the order of types
and compile units in the output of SymbolVendor::Dump. A couple of PDB
tests dependened on that to assert the links between the two.
While it wouldn't be too hard to update the tests, the change of
ordering was not something I intended to do with that patch, and is easy
to restore the original order, so I do just that.
llvm-svn: 366798
Amara Emerson