std::make_heap is currently implemented by iteratively applying a
siftup-type algorithm. Since sift-up is O(ln n), this gives
std::make_heap a worst case time complexity of O(n ln n).
The C++ standard mandates that std::make_heap make no more than O(3n)
comparisons, this makes our std::make_heap out of spec.
Fix this by introducing an implementation of __sift_down and switch
std::make_heap to create the heap using it.
This gives std::make_heap linear time complexity in the worst case.
This fixes PR20161.
llvm-svn: 213615
DAG into a helper function.
This adds a trip through the (very minimal) verification logic in
a bunch of places that were missing it, but shouldn't have any other
impact outside of refactoring. I'm hoping to use this to do more clever
things when DAG nodes are inserted into the graph.
llvm-svn: 213612
a bug in 2010 when they were added but are adding no value today.
In fact, they are utter lies. NodeAllocator is used to allocate almost
all of these node types. I don't know what we were trying to assert
here, and the docs don't give any answer. Until we once again stumble
upon a bug needing help, let's clear the path for improvements.
llvm-svn: 213610
file not in the test/ area). Backing out now so that this test isn't part of
the 3.5 branch.
Original commit message: "TableGen: Allow AddedComplexity values to be negative
[...]"
llvm-svn: 213596
Windows ARM indicates __va_start as a variadic function. However, the function
itself is treated as having 4 formal arguments:
- (out) pointer to the va_list
- (in) address of the last named argument
- (in) slot size for the type of the last argument
- address of the last named argument
The last argument does not seem to have any bearing on codegen, and thus is not
explicitly type checked at this point.
Unlike the previous handling for __va_start, it does not currently validate if
the parameter is the last named parameter (it seems that MSVC currently accepts
this).
llvm-svn: 213595
If function parameters have default values, and that of the second
parameter is parsed with errors, function declaration would have
a parameter without default value that follows a parameter with
that. Such declaration breaks logic of selecting overloaded
function. As a solution, put opaque object as default value in such case.
This patch fixes PR20055.
Differential Revision: http://reviews.llvm.org/D4378
llvm-svn: 213594
Summary:
This pragma is very rare. We could *hypothetically* lower some uses of
it down to @llvm.global_ctors, but given that GlobalOpt isn't able to
optimize prioritized global ctors today, there's really no point.
If we wanted to do this in the future, I would check if the section used
in the pragma started with ".CRT$XC" and had up to two characters after
it. Those two characters could form the 16-bit initialization priority
that we support in @llvm.global_ctors. We would have to teach LLVM to
lower prioritized global ctors on COFF as well.
This should let us compile some silly uses of this pragma in WebKit /
Blink.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4549
llvm-svn: 213593
1) Preserve ref qualification state in a local variable while parsing a nested name. Previously, the state was recorded in the shared db reference and could therefore be overwritten when parsing multiple levels of nested names (e.g.: when a qualified name has qualified template args.)
2) Address an off-by-one error when testing whether or not a thunk is non-virtual. This resulted in the demangled identifying all thunks as non-virtual.
llvm-svn: 213591
Both /showIncludes and /E write to stdout. Allowing both results
in interleaved output and an error when double-closing the file
descriptor, intended to catch issues like this.
llvm-svn: 213589
Over time the symbols and relocations have changed for dwarf unwind info
in the __eh_frame section. Add test cases for older and new style.
llvm-svn: 213585
Previously it was hard-coded to 1.0, which meant the installer would
not install the plugin over previous versions.
This commit makes us use LLVM's major.minor.patch version from cmake,
or whatever CLANG_FORMAT_VS_VERSION is set to when configuring the build.
It's pretty dirty to update a configuration file in the source directory
from the cmake build like this. However, the plugin build is already
dirty in this regard since it builds in the source dir when visual studio,
and then copies out the resulting vsix.
llvm-svn: 213584
As it turns out, the capture tracker named CaptureBefore used by AA, and now
available via the PointerMayBeCapturedBefore function, would have been
more-aptly named CapturedBeforeOrAt, because it considers captures at the
instruction provided. This is not always what one wants, and it is difficult to
get the strictly-before behavior given only the current interface. This adds an
additional parameter which controls whether or not you want to include
captures at the provided instruction. The default is not to include the
instruction provided, so that 'Before' matches its name.
No functionality change intended.
llvm-svn: 213582
LLDWrapPython.cpp is a generated file. This contains a double assignment to the
same value, which causes GCC to emit a warning about sequence point evaluation
causing a use-before-init. Simply silence the warning.
llvm-svn: 213575
This fixes a couple of asserts when analyzing comparisons involving
C11 atomics that were uncovered by r205608 when we extended the
applicability of -Wtautological-constant-out-of-range-compare.
llvm-svn: 213573
GCC believes it may be possible to not return a value from the switch:
lib/Target/R600/SIRegisterInfo.cpp:187:1: warning: control reaches end of non-void function [-Wreturn-type]
Add an unreachable label to indicate that this is not possible and still permit
switch coverage checking.
llvm-svn: 213572
We should update the usages to all of the results;
otherwise, we might get assertion failure or SEGV during
the type legalization of ATOMIC_CMP_SWAP_WITH_SUCCESS
with two or more illegal types.
For example, in the following sequence, both i8 and i1
might be illegal in some target, e.g. armv5, mipsel, mips64el,
%0 = cmpxchg i8* %ptr, i8 %desire, i8 %new monotonic monotonic
%1 = extractvalue { i8, i1 } %0, 1
Since both i8 and i1 should be legalized, the corresponding
ATOMIC_CMP_SWAP_WITH_SUCCESS dag will be checked/replaced/updated
twice.
If we don't update the usage to *ALL* of the results in the
first round, the DAG for extractvalue might be processed earlier.
The GetPromotedInteger() will result in assertion failure,
because its operand (i.e. the success bit of cmpxchg) is not
promoted beforehand.
llvm-svn: 213569
Timur Iskhodzhanov