Summary:
lit's `OneCommandFileTest` class implements an abstract method that
raises if called. However, it raises by referencing an undefined
symbol. Instead, raise explicitly by throwing a `NotImplementedError`.
This is clearer, and appeases Python linters.
Patch By Brian Gesiak!
Reviewers: ddunbar, echristo, beanz
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25170
llvm-svn: 283090
Summary:
In Python, `None` is a singleton, so checking whether a variable is
`None` may be done with `is` or `is not`. This has a slight advantage
over equiality comparisons `== None` and `!= None`, since `__eq__` may
be overridden in Python to produce sometimes unexpected results.
Using `is None` and `is not None` is also recommended practice in
https://www.python.org/dev/peps/pep-0008:
> Comparisons to singletons like `None` should always be done with `is` or
> `is not`, never the equality operators.
Patch by Brian Gesiak!
Reviewers: ddunbar, echristo, beanz
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25168
llvm-svn: 283088
The PPC branch-selection pass, which performs branch relaxation, needs to
account for the padding that might be introduced to satisfy block alignment
requirements. We were assuming that the first block was at offset zero (i.e.
had the alignment of the function itself), but under the ELFv2 ABI, a global
entry function prologue is added to the first block, and it is a
two-instruction sequence (i.e. eight-bytes long). If the function has 16-byte
alignment, the fact that the first block is eight bytes offset from the start
of the function is relevant to calculating where padding will be added in
between later blocks.
Unfortunately, I don't have a small test case.
llvm-svn: 283086
I don't know for sure that we truly needs this, but its the only vector load that isn't rematerializable. Making it consistent allows it to not be a special case in the td files.
llvm-svn: 283083
These are missing dependencies that have been exposed in builds as a result of my change to make lldb libraries depend on CLANG_TABLEGEN_TARGETS instead of libclang.
llvm-svn: 283081
This was first landed in rL283058 and subsequenlty reverted since a
change this depends on (rL283057) was buggy and had to be reverted.
llvm-svn: 283079
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.
An earlier version of this change was landed as rL283057 which had a
use-after-free bug. This new version has a fix for that bug, and a (C++
unittests/) test case that would have triggered it rL283057.
llvm-svn: 283078
Install the 'clang-cpp' symlink used to spawn the preprocessor. The code
handling this suffix is already included in Driver. FreeBSD is already
creating such a symlink in ports, and a similar one was requested
by Gentoo/FreeBSD team. The goal is to handle software that takes a C
preprocessor via a variable but does not handle passing options
correctly (i.e. 'clang -E' does not work).
Bug: https://bugs.gentoo.org/478810
Differential Revision: https://reviews.llvm.org/D25161
llvm-svn: 283075
Preemptively scrubbing these to avoid a bot fail as in PR30443:
https://llvm.org/bugs/show_bug.cgi?id=30443
I'm nearly done with a patch to fix these cases, so not trying very
hard to do better for the temporary win.
I plan to use better checks than what the script produces for the vectorized cases.
llvm-svn: 283072
To allow broadcast loads of a non-zero'th vector element, lowerVectorShuffleAsBroadcast can replace a load with a new load with an adjusted address, but unfortunately we weren't ensuring that the new load respected the same dependencies.
This patch adds a TokenFactor and updates all dependencies of the old load to reference the new load instead.
Bug found during internal testing.
Differential Revision: https://reviews.llvm.org/D25039
llvm-svn: 283070
* Use lexical binding, as recommended for new libraries.
* Fix customization variable (set correct group and type).
* Create a new customization group for the library.
* Autoload the main clang-rename command so that users don't have to explicitly load the library.
* Correctly translate between file and buffer positions using bufferpos-to-filepos (if available) or a fallback.
* Don't invoke the shell, it's not necessary and adds complexity.
* Save clang-rename output in a buffer and display that on failure.
* Save all buffers before calling clang-rename. This is required anyway and prevents data loss when the buffer is later reverted.
* In revert-buffer, use keywords instead of t for Boolean arguments to improve readability.
* Don't reset buffer modes when reverting.
* Emacs treats the character after a symbol as part of the symbol, while clang-rename doesn't; resolve this inconsistency.
* Formatting.
Patch by Philipp Stephani!
Reviewers: omtcyfz
Differential Revision: https://reviews.llvm.org/D25156
llvm-svn: 283067
Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.
Patch mostly by EricWF.
Reviewers: rnk, cfe-commits, rsmith, EricWF
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D25130
llvm-svn: 283064
Reapplying the patch after modifying the test case.
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341
This patch disables alias to available_externally definitions.
Reviewers: eugenis, rsmith
Differential Revision: https://reviews.llvm.org/D24682
llvm-svn: 283063
They've broken the sanitizer-bootstrap bots. Reverting while I investigate.
Original commit messages:
r283057: "[ConstantRange] Make getEquivalentICmp smarter"
r283058: "[SCEV] Rely on ConstantRange instead of custom logic; NFCI"
llvm-svn: 283062
Enable soft-float support on PPC64, as the backend now supports it. Also, the
backend now uses -hard-float instead of +soft-float, so set the target features
accordingly.
Fixes PR26970.
llvm-svn: 283061
This change enables soft-float for PowerPC64, and also makes soft-float disable
all vector instruction sets for both 32-bit and 64-bit modes. This latter part
is necessary because the PPC backend canonicalizes many Altivec vector types to
floating-point types, and so soft-float breaks scalarization support for many
operations. Both for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware floating-point
also disables vector instructions (embedded targets without hardware floating
point support are unlikely to have Altivec, etc. and operating system kernels
desiring not to use floating-point registers to lower syscall cost are unlikely
to want to use vector registers either). If someone needs this to work, we'll
need to change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is enabled,
hardware floating-point support needs to be expressed as a positive feature,
like the others, and not a negative feature, because target features cannot
have dependencies on the disabling of some other feature. So +soft-float has
now become -hard-float.
Fixes PR26970.
llvm-svn: 283060
As per the PE COFF spec (section 8.3, Import Name Type)
Offset: 18 Size 2 bits Name: Type
Offset: 20 Size 3 bits Name: Name Type
Offset: 20 added based on 18+2
Partially commited as rL279069
Differential Revision: https://reviews.llvm.org/D23540
llvm-svn: 283055
The libc-provided isnan/isinf/isfinite macro implementations are specifically
designed to function correctly, even in the presence of -ffast-math (or, more
specifically, -ffinite-math-only). As such, on most implementation, these
either always turn into external function calls (e.g. glibc) or are
specifically function calls when FINITE_MATH_ONLY is defined (e.g. Darwin).
Our implementation of complex arithmetic makes heavy use of isnan/isinf/isfinite
to deal with corner cases involving non-finite quantities. This was problematic
in two respects:
1. On systems where these are always function calls (e.g. Linux/glibc), there was a
performance penalty
2. When compiling with -ffast-math, there was a significant performance
penalty (in fact, on Darwin and systems with similar implementations, the code
may in fact be slower than not using -ffast-math, because the inline
definitions provided by libc become unavailable to prevent the checks from
being optimized out).
Eliding these inf/nan checks in -ffast-math mode is consistent with what
happens with libstdc++, and in my experience, what users expect. This is
critical to getting high-performance code when using complex<T>. This change
replaces uses of those functions on basic floating-point types with calls to
__builtin_isnan/isinf/isfinite, which Clang will always expand inline. When
using -ffast-math (or -ffinite-math-only), the optimizer will remove the checks
as expected.
Differential Revision: https://reviews.llvm.org/D18639
llvm-svn: 283051
Chris Bieneman