It turns out that terminatepad gives little benefit over a cleanuppad
which calls the termination function. This is not sufficient to
implement fully generic filters but MSVC doesn't support them which
makes terminatepad a little over-designed.
Depends on D15478.
Differential Revision: http://reviews.llvm.org/D15479
llvm-svn: 255522
We'd like to remove support for terminatepad from LLVM. To do this, we
need to move Clang off of it first. The intent behind terminatepad was
to carefully model exception specifications for the MSVC personality.
However, we don't support exception specifications for the MSVC
personality and neither does MSVC. Instead, MSVC supports
all-or-nothing exception specifications. We can model this limited
usage using cleanuppads which call std::terminate.
Differential Revision: http://reviews.llvm.org/D15478
llvm-svn: 255521
When FastISel fails to translate an instruction it hands off code
generation to SelectionDAG. Before it does so, it may have generated
local value instructions to feed phi nodes in successor blocks. These
instructions will then be generated again by SelectionDAG, causing
duplication and less efficient code, including extra spill
instructions.
Patch by Wolfgang Pieb!
Differential Revision: http://reviews.llvm.org/D11768
llvm-svn: 255520
This is the second in a set of patches for soft float support for ppc32,
it enables soft float operations.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D13700
llvm-svn: 255516
This patch enables soft float support for ppc32 architecture and fixes
the ABI for variadic functions. This is the first in a set of patches
for soft float support in LLVM.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D13351
llvm-svn: 255515
This change should not change the behavior of Polly today, but it allows
external constants to be remapped e.g. when targetting multiple LLVM modules.
llvm-svn: 255506
This reverts commit r255471.
Johannes raised in the post-commit review of r255471 the concern that PHI
writes in non-affine regions with two exiting blocks are not really MUST_WRITE,
but we just know that at least one out of the set of all possible PHI writes
will be executed. Modeling all PHI nodes as MUST_WRITEs is probably save, but
adding the needed documentation for such a special case is probably not worth
the effort. Michael will be proposing a new patch that ensures only a single
PHI_WRITE is created for non-affine regions, which - besides other benefits -
should also allow us to use a single well-defined MUST_WRITE for such PHI
writes.
(This is not a full revert, but the condition and documentation have been
slightly extended)
llvm-svn: 255503
- Removed support for hexagonv3 and earlier.
- Added handling of hexagonv55 and hexagonv60.
- Added handling of target features (hvx, hvx-double).
- Updated paths to reflect current directory layout.
llvm-svn: 255502
Now with variadic support for msan on aarch6 there is no need for
XFAIL signal_stress_test anymore. Also to garantee aligned stores
for the FP/SIMD arguments enforce the '__msan_va_arg_tls' alignment
to sizeof the SIMD register (16).
llvm-svn: 255496
This patch add support for variadic argument for AArch64. All the MSAN
unit tests are not passing as well the signal_stress_test (currently
set as XFAIl for aarch64).
llvm-svn: 255495
We're using the dispatch group itself to synchronize (to call Release() and Acquire() on it), but in dispatch group notifications, the group can already be disposed/deallocated. This causes a later assertion failure at `DCHECK_EQ(*meta, 0);` in `MetaMap::AllocBlock` when the same memory is reused (note that the failure only happens in debug builds).
Fixing this by retaining the group and releasing it in the notification. Adding a stress test case that reproduces this.
Differential Revision: http://reviews.llvm.org/D15380
llvm-svn: 255494
Summary:
Previously the add_test_categories would simply overwrite the current set of categories for a
method. This change makes the decorator truly "add" categories, by extending the current set of
categories instead of replacing it.
To do this, I have:
- replaced the getCategories() property on a method (which was itself a method), with a simple
list property "categories". This makes add_test_categories easier to implement, and test
categories isn't something which should change between calls anyway.
- rewritten the getCategoriesForTest function to merge method categories with the categories of
the test case. Previously, it would just use the method categories if they were present. I have
also greatly simplified this method. Originally, it would use a lot of introspection to enable
it being called on various types of objects. Based on my tests, it was only ever being called
on a test case. The new function uses much less introspection then the preivous one, so we
should easily catch any stray uses, if there are any, as they will generate exceptions now.
Reviewers: zturner, tfiala, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15451
llvm-svn: 255493
The safestack overflow.c test is currently failing on an aarch64
buildbot with a segfault, but it is currently passing on other
configuration.
This patch silent the issue for now on aarch64 by setting to all
supported architectures the 'stable-runtime' configure and set
the test to requires it.
llvm-svn: 255491
In conditional store merging, we were creating PHIs when we didn't
need to. If the value to be predicated isn't defined in the block
we're predicating, then it doesn't need a PHI at all (because we only
deal with triangles and diamonds, any value not in the predicated BB
must dominate the predicated BB).
This fixes a large code size increase in some benchmarks in a popular embedded benchmark suite.
llvm-svn: 255489
Revision 251405 added AlwaysBreak to support Google's JavaScript style. This
changeset complete existing AlignsAfterOpenBracket tests to exercise
AlwaysBreak for C++.
I thought this would be worthwhile. With this option we can support request
from http://lists.llvm.org/pipermail/cfe-dev/2015-May/042942.html, that had
been requested a few times. This also partially solve related Bug 23422 and is
probably sufficient for most people.
AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
BinPackArguments = false;
BinPackParameters = false;
With these setting we obtain this formatting:
void fooWithAVeryLongParamList(
int firstParameter,
int secondParameter
int lastParameter)
{
object.alsoThisDoenstFitSoIBreakImmidiatly(
firstParameter,
secondParameter,
lastParameter);
}
Patch by Jean-Philippe Dufraigne, thank you.
llvm-svn: 255486
It's O(N^2) because it does a simple walk through the existing types to
find duplicates, but that will be fixed in a follow-up commit to use a
mapping data structure of some kind.
llvm-svn: 255482
Before this commit, only the region's entry block was assumed to always
execute in a non-affine subregion. We replace this by a test whether it
dominates the exit block (this necessarily includes the entry block)
which should be more accurate.
llvm-svn: 255473
LLVM's IR guarantees that a value definition occurs before any use, and
also the value of a PHI must be one of the incoming values, "written"
in one of the incoming blocks. Hence, such writes are never conditional
in the context of a non-affine subregion.
llvm-svn: 255471
Summary:
This is http://reviews.llvm.org/D13746 but instead of including <array>,
a stub is provided.
This check flags all array subscriptions on static arrays and
std::arrays that either have a non-compile-time-constant index or are
out of bounds.
Dynamic accesses into arrays are difficult for both tools and humans to
validate as safe. array_view is a bounds-checked, safe type for
accessing arrays of data. at() is another alternative that ensures
single accesses are bounds-checked. If iterators are needed to access an
array, use the iterators from an array_view constructed over the array.
This rule is part of the "Bounds safety" profile of the C++ Core
Guidelines, see
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds2-only-index-into-arrays-using-constant-expressions
Reviewers: alexfh, sbenza, bkramer, aaron.ballman
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15030
llvm-svn: 255470
David Majnemer