Summary:
This patch allows the use of LIT's ShTest format in the libc++ test suite. ShTests have the suffix '.sh.cpp'. It also introduces a series of other changes. These changes are:
- More functionality including parsing test metadata has been moved into LIT.
- LibcxxTestFormat now supports multi-part suffixes.
- the `CXXCompiler` functionality has been used to shrink the size of LibcxxTestFormat.
- The recursive loading of the site config has been turned into `libcxx.test.config.loadSiteConfig` so it can be used with libc++abi.
- Temporary files are now created in the build directory of libc++. This follows how it is down in ShTest.
- `not.py` was added as a utility executable that mirrors the functionality of LLVM's `not` executable.
- The first ShTest test was added under test/libcxx/double_include.sh.cpp
Reviewers: jroelofs, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7073
llvm-svn: 226844
Currently, we're adding a uint64_t describing the current subtarget so
that matching can check whether the specified register is valid.
However, we want to move to a bitset for those bits (x86 has more than
64 of them).
This can't live in a union so it's probably better to do the checks
early (especially as there are only 3 of them).
llvm-svn: 226841
The ELF format is used on Windows by the MCJIT engine. Thus, on Windows, the
ELFObjectWriter can encounter symbols mangled using the MS Visual Studio C++
name mangling. Symbols mangled using the MSVC C++ name mangling can legally
have "@@@" as a substring. The EFLObjectWriter should not interpret the "@@@"
substring as specifying GNU-style symbol versioning. The ELFObjectWriter
therefore check for the MSVC C++ name mangling prefix which is either "?", "@?",
"imp_?" or "imp_?@".
llvm-svn: 226830
Without -funwind-tables, the compiler won't generate the unwinding
table for these C functions. However, the functions in libunwind,
such as `_Unwind_Backtrace()`, WILL unwind stack to get the backtrace.
llvm-svn: 226823
If libcxxabi is compiled as a shared library, and the
executable references the user-defined personality routines
(e.g. __gxx_personality_v0), then the pointer comparison in
Unwind-EHABI.cpp won't work. This is due to the fact that
the PREL31 will point to the PLT stubs for the personality
routines (in the executable), while the __gxx_personality_v0
symbol reference is yet another (different) PLT stub (in the
libunwind.)
This will cause _Unwind_Backtrace() stops to unwind the frame
whenever it reaches __gxx_personality_v0(). This CL fix the
problem by calling the user-defined personality routines
with an undocumented API for force unwinding.
llvm-svn: 226822
By attaching an extra integer tag to heap origins, we are able
to distinguish between uninits
- created by heap allocation,
- created by heap deallocation (i.e. use-after-free),
- created by __msan_allocated_memory call,
- etc.
See https://code.google.com/p/memory-sanitizer/issues/detail?id=35.
llvm-svn: 226821
This CL adds a new compilation flags LIBCXXABI_USE_LLVM_UNWINDER
to specify whether the LLVM unwinder is enabled. Besides, all
unwinder-specific code are guarded with this definition.
Now, libc++abi will be able to use the unwinding routine from libgcc
when LIBCXXABI_USE_LLVM_UNWINDER is disabled.
llvm-svn: 226819
This commit partially reverts r219629.
This functions are not a part of ARM EHABI specification, and AFAIK,
the de facto implementation does not export these functions.
Without this change, any programs compiled with this unwind.h
will be incompatible with other implementations due to linkage
error.
llvm-svn: 226818
This patch is the result of applying fixes of the ContainerSizeEmpty Clang-Tidy
checker which was committed recently.
http://reviews.llvm.org/D7085
Patch by Gábor Horváth!
llvm-svn: 226817
This solves PR22276.
Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead.
Differential Revision: http://reviews.llvm.org/D7093
Fixed recommit of r226811.
llvm-svn: 226816
This solves PR22276.
Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead.
Differential Revision: http://reviews.llvm.org/D7093
llvm-svn: 226811
The problem occurs when after vectorization we have type
<2 x i32>. This type is promoted to <2 x i64> and then requires
additional efforts for expanding loads and truncating stores.
I added EXPAND / TRUNCATE attributes to the masked load/store
SDNodes. The code now contains additional shuffles.
I've prepared changes in the cost estimation for masked memory
operations, it will be submitted separately.
llvm-svn: 226808
Type MVT::i1 became legal in KNL, but store operation can't be narrowed to this type,
since the size of VT (1 bit) is not equal to its actual store size(8 bits).
Added a test provided by David (dag@cray.com)
llvm-svn: 226805
Use the struct instead of a std::pair<Value *, Value *>. This makes a
Range an obviously immutable object, and we can now assert that a
range is well-typed (Begin->getType() == End->getType()) on its
construction.
llvm-svn: 226804
There are places where the inductive range check elimination pass
depends on two llvm::Values or llvm::SCEVs to be of the same
llvm::Type when they do not need to be. This patch relaxes those
restrictions (by bailing out of the optimization if the types
mismatch), and adds test cases to trigger those paths.
These issues were found by bootstrapping clang with IRCE running in
the -O3 pass ordering.
Differential Revision: http://reviews.llvm.org/D7082
llvm-svn: 226793
Even with the current limit on the number of alias checks, the containing loop has quadratic complexity.
This begins to hurt for blocks containing > 1K load/store instructions.
This commit introduces a limit for the loop count. It reduces the runtime for such very large blocks.
llvm-svn: 226792
Eric Fiselier