This is a recommit of r264414 after fixing the buildbot failure caused by
incompatible use of std::vector.erase().
The original message:
Add erase() which returns an iterator pointing to the next element after the
erased one. This makes it possible to erase selected elements while iterating
over the SetVector :
while (I != E)
if (test(*I))
I = SetVector.erase(I);
else
++I;
Reviewers: qcolombet, mcrosier, MatzeB, dblaikie
Subscribers: dberlin, dblaikie, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18281
llvm-svn: 264450
Summary:
Add erase() which returns an iterator pointing to the next element after the
erased one. This makes it possible to erase selected elements while iterating
over the SetVector :
while (I != E)
if (test(*I))
I = SetVector.erase(I);
else
++I;
Reviewers: qcolombet, mcrosier, MatzeB, dblaikie
Subscribers: dberlin, dblaikie, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18281
llvm-svn: 264414
Summary:
Loading IR with debug info improves MDString::get() from 19ms to 10ms.
This is a rework of D16597 with adding an "emplace" method on the StringMap
to avoid requiring the MDString move ctor to be public.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17920
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264386
Summary:
StringMap ctor accepts an initialize size, but expect it to be
rounded to the next power of 2. The ctor can handle that directly
instead of expecting clients to round it. Also, since the map will
resize itself when 75% full, take this into account an initialize
a larger initial size to avoid any growth.
Reviewers: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18344
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264385
Summary:
Just running the loop in the unittests for a few more iterations
(till 48) exhibit that the condition on the limit was not handled
properly in r263522.
Rewrite the test to use a class to count move/copies that happens
when inserting into the map.
Also take the opportunity to refactor the logic to compute the
number of buckets required for a given number of entries in the map.
Use this when constructing a DenseMap with a desired size given to
the constructor (and add a tests for this).
Reviewers: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18345
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264384
The BumpPtrAllocator currently doesn't handle zero length allocations well.
The discussion for how to fix that is ongoing. However, there's no need
for StringRef::copy to actually allocate anything here anyway, so just
return StringRef() when we get a zero length copy.
Reviewed by David Blaikie
llvm-svn: 264201
MSVC as usual:
C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/ADT/STLExtras.h(120):
error C2100: illegal indirection
C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/IR/Instructions.h(3966):
note: see reference to class template instantiation
'llvm::mapped_iterator<llvm::User::op_iterator,llvm::CatchSwitchInst::DerefFnTy>'
being compiled
This reverts commit e091dd63f1f34e043748e28ad160d3bc17731168.
llvm-svn: 263760
In some places, like InstCombine, we resize a DenseMap to fit the elements
we intend to put in it, then insert those elements (to avoid continual
reallocations as it grows). But .resize(foo) doesn't actually do what
people think; it resizes to foo buckets (which is really an
implementation detail the user of DenseMap probably shouldn't care about),
not the space required to fit foo elements. DenseMap grows if 3/4 of its
buckets are full, so this actually causes one forced reallocation every
time instead of avoiding a reallocation.
This patch makes .resize(foo) do the intuitive thing: it grows to the size
necessary to fit foo elements without new allocations.
Also include a test to verify that .resize() actually does what we think it
does.
llvm-svn: 263522
Add support for trimming a single kind of character from a StringRef.
This makes the common case of trimming null bytes much neater. It's also
probably a bit speedier too, since it avoids creating a std::bitset in
find_{first,last}_not_of.
llvm-svn: 260925
As support expands to more runtimes, we'll need to
distinguish between more than just HSA and unknown.
This also lets us stop using unknown everywhere.
llvm-svn: 260790
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
llvm-svn: 258861
Summary:
The problem here is that an enum class can not be implicitly converted to an
integer. That assumption snuck back into PointerIntPair. This commit fixes the
issue and more importantly adds some unittests to make sure that we do not break
this again.
rdar://23594806
Reviewers: gribozavr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16131
llvm-svn: 257574
type.
This makes it easy and safe to use a set of flags as one elmenet of
a tagged union with pointers. There is quite a bit of code that has
historically done this by casting arbitrary integers to "pointers" and
assuming that this was safe and reliable. It is neither, and has started
to rear its head by triggering safety asserts in various abstractions
like PointerLikeTypeTraits when the integers chosen are invariably poor
choices for *some* platform and *some* situation. Not to mention the
(hopefully unlikely) prospect of one of these integers actually getting
allocated!
With this, it will be straightforward to build type safe abstractions
like this without being error prone. The abstraction itself is also
remarkably simple thanks to the implicit conversion.
This use case and pattern was also independently created by the folks
working on Swift, and they're going to incrementally add any missing
functionality they find.
Differential Revision: http://reviews.llvm.org/D15844
llvm-svn: 257284
This is a much more general and powerful form of PointerUnion. It
provides a reasonably complete sum type (from type theory) for
pointer-like types. It has several significant advantages over the
existing PointerUnion infrastructure:
1) It allows more than two pointer types to participate without awkward
nesting structures.
2) It directly exposes the tag so that it is convenient to write
switches over the possible members.
3) It can re-use the same type for multiple tag values, something that
has been worked around by either abusing PointerIntPair or defining
nonce types and doing unsafe pointer casting.
4) It supports customization of the PointerLikeTypeTraits used for
specific member types. This means it could (in theory) be used even
with types that are over-aligned on allocation to expose larger
numbers of bits to the tag.
All in all, I think it is at least complimentary to the existing
infrastructure, and a strict improvement for some use cases.
Differential Revision: http://reviews.llvm.org/D15843
llvm-svn: 257282
We didn't actually statically check this, and so it worked 25% of the
time for me. =/ Really sorry it took so long to fix, I shouldn't leave
the commit log editor window open without saving and landing the commit.
=[
llvm-svn: 256528
Summary:
This follows D14577 to treat ARMv6-J as an alias for ARMv6,
instead of an architecture in its own right.
The functional change is that the default CPU when targeting ARMv6-J
changes from arm1136j-s to arm1136jf-s, which is currently used as
the default CPU for ARMv6; both are, in fact, ARMv6-J CPUs.
The J-bit (Jazelle support) is irrelevant to LLVM, and it doesn't
affect code generation, attributes, optimizations, or anything else,
apart from selecting the default CPU.
Reviewers: rengolin, logan, compnerd
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14755
llvm-svn: 253675
Useful utility function; this wasn't too hard to do before, but also wasn't
obviously discoverable. Make it explicit. Reviewed offline by Michael
Gottesman.
llvm-svn: 253254
Summary:
* ARMv6KZ is the "canonical" name, given in the ARMARM
* ARMv6Z is an "official abbreviation" for it, mentioned in the ARMARM
* ARMv6ZK is a popular misspelling, which we should support as an alias.
The patch corrects the handling of the names.
Functional changes:
* ARMv6Z no longer treated as an architecture in its own right
* ARMv6ZK renamed to ARMv6KZ, accepting ARMv6ZK as an alias
* arm1176jz-s and arm1176jzf-s recognized as ARMv6ZK, instead of ARMv6K
* default ARMv6K CPU changed to arm1176j-s
Reviewers: rengolin, logan, compnerd
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14568
llvm-svn: 253206
Re-implement `ilist_node::getNextNode()` and `getPrevNode()` without
relying on the sentinel having a "next" pointer. Instead, get access to
the owning list and compare against the `begin()` and `end()` iterators.
This only works when the node *can* get access to the owning list. The
new support is in `ilist_node_with_parent<>`, and any class `Ty`
inheriting from `ilist_node<NodeTy>` that wants `getNextNode()` and/or
`getPrevNode()` should inherit from
`ilist_node_with_parent<NodeTy, ParentTy>` instead. The requirements:
- `NodeTy` must have a `getParent()` function that returns the parent.
- `ParentTy` must have a `getSublistAccess()` static that, given a(n
ignored) `NodeTy*` (to determine which list), returns a member field
pointer to the appropriate `ilist<>`.
This isn't the cleanest way to get access to the owning list, but it
leverages the API already used in the IR hierarchy (see, e.g.,
`Instruction::getSublistAccess()`).
If anyone feels like ripping out the calls to `getNextNode()` and
`getPrevNode()` and replacing with direct iterator logic, they can also
remove the access function, etc., but as an incremental step, I'm
maintaining the API where it's currently used in tree.
If these requirements are *not* met, call sites with access to the ilist
can call `iplist<NodeTy>::getNextNode(NodeTy*)` directly, as in
ilistTest.cpp.
Why rewrite this?
The old code was broken, calling `getNext()` on a sentinel that possibly
didn't have a "next" pointer at all! The new code avoids that
particular flavour of UB (see the commit message for r252538 for more
details about the "lucky" memory layout that made this function so
interesting).
There's still some UB here: the end iterator gets downcast to `NodeTy*`,
even when it's a sentinel (which is typically
`ilist_half_node<NodeTy*>`). I'll tackle that in follow-up commits.
See this llvm-dev thread for more details:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html
What's the danger?
There might be some code that relies on `getNextNode()` or
`getPrevNode()` *never* returning `nullptr` -- i.e., that relies on them
being broken when the sentinel is an `ilist_half_node<NodeTy>`. I tried
to root out those cases with the audits I did leading up to r252380, but
it's possible I missed one or two. I hope not.
(If (1) you have out-of-tree code, (2) you've reverted r252380
temporarily, and (3) you get some weird crashes with this commit, then I
recommend un-reverting r252380 and auditing the compile errors looking
for "strange" implicit conversions.)
llvm-svn: 252694
This complements CopyConstructorNotSmallTest. If we are testing the copy
constructor in such a way, we should also probably test assignment in the same
way.
llvm-svn: 251736
GNU tools require elfiamcu to take up the entire OS field, so, e.g.
i?86-*-linux-elfiamcu is not considered a legal triple.
Make us compatible.
Differential Revision: http://reviews.llvm.org/D14081
llvm-svn: 251390
This adds support for the i?86-*-elfiamcu triple, which indicates the IAMCU psABI is used.
Differential Revision: http://reviews.llvm.org/D13977
llvm-svn: 251222
This patch adds the underlying infrastructure for an AVR backend to be included into LLVM. It is the first of a series of patches aimed at moving the out-of-tree AVR backend into the tree.
It consists of adding a new`Triple` target 'avr'.
llvm-svn: 250492
and assert when mask is too large to apply in the small case,
previously the extra words were silently ignored.
clang-format the entire function to match current code standards.
This is a rewrite of r247972 which was reverted in r247983 due to
warning and possible UB on 32-bits hosts.
llvm-svn: 247993
Extend mask value to 64 bits before taking its complement and assert when mask is
too large to apply in the small case (previously the extra words were silently ignored).
http://reviews.llvm.org/D11890
Patch by James Touton!
llvm-svn: 247972
with the StringRef::split method when used with a MaxSplit argument
other than '-1' (which nobody really does today, but which should
actually work).
The spec claimed both to split up to MaxSplit times, but also to append
<= MaxSplit strings to the vector. One of these doesn't make sense.
Given the name "MaxSplit", let's go with it being a max over how many
*splits* occur, which means the max on how many strings get appended is
MaxSplit+1. I'm not actually sure the implementation correctly provided
this logic either, as it used a really opaque loop structure.
The implementation was also playing weird games with nullptr in the data
field to try to rely on a totally opaque hidden property of the split
method that returns a pair. Nasty IMO.
Replace all of this with what is (IMO) simpler code that doesn't use the
pair returning split method, and instead just finds each separator and
appends directly. I think this is a lot easier to read, and it most
definitely matches the spec. Added some tests that exercise the corner
cases around StringRef() and StringRef("") that all now pass.
I'll start using this in code in the next commit.
llvm-svn: 247249
on StringRef. Finding and splitting on a single character is
substantially faster than doing it on even a single character StringRef
-- we immediately get to a *very* tuned memchr call this way.
Even nicer, we get to this even in a debug build, shaving 18% off the
runtime of TripleTest.Normalization, helping PR23676 some more.
llvm-svn: 247244
The purpose is to allow templated wrapper to work with either
ArrayRef or any convertible operation:
template<typename Container>
void wrapper(const Container &Arr) {
impl(makeArrayRef(Arr));
}
with Container being a std::vector, a SmallVector, or an ArrayRef.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247214
of its strings when expanding the string literals from the macros, and
push all of the APIs to be StringRef instead of C-string APIs.
This (remarkably) removes a very non-trivial number of strlen calls. It
even deletes code and complexity from one of the primary users -- Clang.
llvm-svn: 246374
This is something like nullopt in std::experimental::optional. Optional
could already be constructed from None, so this seems like an obvious
extension from there.
I have a use in a future patch for Clang, though it may not go that
way/end up used - so this seemed worth committing now regardless.
llvm-svn: 245518
This causes the other special members (like move and copy construction,
and move assignment) to come through for free. Some code in clang was
depending on the (deprecated, in the original code) copy ctor. Now that
there's no user-defined special members, they're all available without
any deprecation concerns.
llvm-svn: 244835
For example of mingw-w64-g++-4.8.1,
llvm/unittests/ADT/ArrayRefTest.cpp: In member function 'virtual void {anonymous}::ArrayRefTest_AllocatorCopy_Test::TestBody()':
llvm/unittests/ADT/ArrayRefTest.cpp:56:40: internal compiler error: in count_type_elements, at expr.c:5523
} Array3Src[] = {{"hello"}, {"world"}};
^
Please submit a full bug report,
with preprocessed source if appropriate.
llvm-svn: 244017
This reverts commit r243567, which ultimately reapplies r243563.
The fix here was to use std::enable_if for overload resolution. Thanks to David
Blaikie for lots of help on this, and for the extra tests!
Original commit message follows:
For cases where we needed a foreach loop in reverse over a container,
we had to do something like
for (const GlobalValue *GV : make_range(TypeInfos.rbegin(),
TypeInfos.rend())) {
This provides a convenience method which shortens this to
for (const GlobalValue *GV : reverse(TypeInfos)) {
There are 2 versions of this, with a preference to the rbegin() version.
The first uses rbegin() and rend() to construct an iterator_range.
The second constructs an iterator_range from the begin() and end() methods
wrapped in std::reverse_iterator's.
Reviewed by David Blaikie.
llvm-svn: 243581
This reverts commit r243563.
The GCC buildbots were extremely unhappy about this. Reverting while
we discuss a better way of doing overload resolution.
llvm-svn: 243567
For cases where we needed a foreach loop in reverse over a container,
we had to do something like
for (const GlobalValue *GV : make_range(TypeInfos.rbegin(),
TypeInfos.rend())) {
This provides a convenience method which shortens this to
for (const GlobalValue *GV : reverse(TypeInfos)) {
There are 2 versions of this, with a preference to the rbegin() version.
The first uses rbegin() and rend() to construct an iterator_range.
The second constructs an iterator_range from the begin() and end() methods
wrapped in std::reverse_iterator's.
Reviewed by David Blaikie.
llvm-svn: 243563
Summary:
1. Fix return value in `SparseBitVector::operator&=`.
2. Add checks if SBV is being assigned is invoking SBV.
Reviewers: dberlin
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11342
Committed on behalf of sl@
llvm-svn: 242693
Summary:
This patch changes the way APInt is compared with a value of type uint64_t.
Before the uint64_t value was truncated to the size of APInt before comparison.
Now the comparison takes into account full 64-bit precision.
Test Plan: Unit tests added. No regressions. Self-hosted check-all done as well.
Reviewers: chandlerc, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10655
llvm-svn: 241204
This unbreaks TripleTest.Normalization. We'll have to come up with a new
plan for the OS component of the target triple for WebAssembly.
llvm-svn: 241041
While often you want to use something specialized like StringMap, when
the strings already have persistent storage a normal densemap over them
can be more efficient.
This can't go into StringRef.h because of really obnoxious header chains
from the hashing code to the endian detection code to CPU feature
detection code to StringMap.
llvm-svn: 240528
This commit moves the APSInt initialization code that's used by
the LLLexer class into a new APSInt constructor that constructs
APSInts from strings.
This change is useful for MIR Serialization, as it would allow
the MILexer class to use the same APSInt initialization as
LLexer when parsing immediate machine operands.
llvm-svn: 240436
`LLVM_ENABLE_MODULES` builds sometimes fail because `Intrinsics.td`
needs to regenerate `Instrinsics.h` before anyone can include anything
from the LLVM_IR module. Represent the dependency explicitly to prevent
that.
llvm-svn: 239796
This allows us to match armv6m to default to thumb, but will also be used by
Clang's driver and remove the current incomplete copy in it.
llvm-svn: 238036
Simplifying Triple::parseARMArch, leaving all the parsing to ARMTargetParser.
This commit also adds AArch64 detection to ARMTargetParser canonicalization,
and a two RedHat arch names (v{6,7}hl, meaning hard-float / little-endian).
Adding enough unit tests to cover the basics. Clang checks fine.
llvm-svn: 237902
First ARMTargetParser FIXME, conservatively changing the way we parse CPUs
in the back-end. Still not perfect, with a lot of special cases, but moving
towards a more generic solution.
Moving all logic to the target parser made some unwritten assumptions
about architectures in Clang to break. I've added a lot of architectures
required by Clang, and default to CPUs that Clang believes it should
(and I agree).
I've also added a lot of unit tests, with the correct CPU for each
architecture, and Clang seems to be working correctly, too.
It also became clear that using "unsigned ID" as the argument for the get
methods makes it hard to know what ID, so I also changed the argument names
to match the enum type names.
llvm-svn: 237797
Restructure Triple::getARMCPUForArch so that invalid values will
return nullptr, while retaining the behaviour that an argument
specifying no particular architecture version will give a default
CPU. This will be used by clang to give an error on invalid -march
values.
Also restructure the extraction of the architecture version from
the MArch string a little to hopefully make what it's doing clearer.
Differential Revision: http://reviews.llvm.org/D9599
llvm-svn: 236845
Iteration over all permutations didn't really work,
due to evolution of the underlying enums.
Differential Revision: http://reviews.llvm.org/D9057
llvm-svn: 236251
Summary: This patch fixes step D4 of Knuth's division algorithm implementation. Negative sign of the step result was not always detected due to incorrect "borrow" handling.
Test Plan: Unit test that reveals the bug included.
Reviewers: chandlerc, yaron.keren
Reviewed By: yaron.keren
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9196
llvm-svn: 235699
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
Summary:
When the arch is given as "arm" clang uses the default target CPU from
LLVM to determine what the real arch should be (i.e. "arm" becomes
"armv4t" because LLVM's getARMCPUForArch falls back to "arm7tdmi").
Default to "cortex-a8" so that we end up with "armv7" in clang.
the nacl-direct.c test in clang also covers this case.
Differential Revision: http://reviews.llvm.org/D8589
llvm-svn: 233321
APInt uses Knuth's D algorithm for long division. In rare cases the
implementation applied a transformation that was not needed.
Added unit tests for long division. KnuthDiv() procedure is fully covered.
There is a case in APInt::divide() that I believe is never used (marked with
a comment) as all users of divide() handle trivial cases earlier.
Patch by Pawel Bylica!
http://reviews.llvm.org/D8448
llvm-svn: 233312
CloudABI is a POSIX-like runtime environment built around the concept of
capability-based security. More details:
https://github.com/NuxiNL/cloudlibc
CloudABI uses its own ELFOSABI number. This number has been allocated by
the maintainers of ELF a couple of days ago.
Reviewed by: echristo
llvm-svn: 231681
Accidentally committed a few more of these cleanup changes than
intended. Still breaking these out & tidying them up.
This reverts commit r231135.
llvm-svn: 231136
There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you want to reuse an iterator
variable to iterate another node, that's perfectly acceptable. Just
don't mix comparisons between iterators into disjoint sequences, as
usual.
llvm-svn: 231135
Without this, use of this copy ctor is deprecated in C++11 due to the
presence of a user-declared dtor.
Marking the class final is just a little extra security that there are
no further derived classes that may then end up using the intermediate
base class's copy assignment operator and cause slicing to occur.
I didn't bother marking the other (non-test) base class final, since it
has reference members so it won't have any implicit assignment operators
anyway. Open to ideas on that, though.
We probably want a warning about use of a slicing assignment operator,
then I wouldn't worry so much about marking the class as final.
llvm-svn: 231114
With initializer lists there is a really neat idiomatic way to write
this, 'ArrayRef.equals({1, 2, 3, 4, 5})'. Remove the equal method which
always had a hard limit on the number of arguments. I considered
rewriting it with variadic templates but that's not really a good fit
for a function with homogeneous arguments.
'ArrayRef == {1, 2, 3, 4, 5}' would've been even more awesome, but C++11
doesn't allow init lists with binary operators.
llvm-svn: 230907
I just realized that the specialized metadata node patch I'm about to
commit won't compile on old compilers. Bump `hash_combine()`'s support
for non-variadic templates to 18 (I tested this by reversing the logic
in the #ifdef).
llvm-svn: 228629
Add some API to `APSInt` to make it easier to compare with `int64_t`.
- `APSInt::compareValues(APSInt, APSInt)` returns 1, -1 or 0 for
greater, lesser, or equal, doing the right thing for mismatched
"has-sign" and bitwidths. This is just like `isSameValue()` (and is
now the implementation of it).
- `APSInt::get(int64_t)` gets a signed `APSInt`.
- `operator<(int64_t)`, etc., are implemented trivially via `get()`
and `compareValues()`.
- Also added `APSInt::getUnsigned(uint64_t)` to make it easier to test
`compareValues()`.
llvm-svn: 228239
suffix it seems:
# ./config.guess
earmv7hfeb-unknown-netbsd7.99.4
Extend the triple parsing to support this. Avoid running the ARM parser
multiple times because StringSwitch is not lazy.
Reviewers: Renato Golin, Tim Northover
Differential Revision: http://reviews.llvm.org/D7166
llvm-svn: 227085
This patch adds a check for underflow when truncating results back to lower
precision at the end of an FMA. The additional sign handling logic in
APFloat::fusedMultiplyAdd should only be performed when the result of the
addition step of the FMA (in full precision) is exactly zero, not when the
result underflows to zero.
Unit tests for this case and related signed zero FMA results are included.
Fixes <rdar://problem/18925551>.
llvm-svn: 225123
This appears to have broken at least the windows build bots due to
compile errors in the predicate that didn't simply supress the overload.
I'm not sure what the fix is, and the bots have been broken for a long
time now so I'm just reverting until Michael can figure out a fix.
llvm-svn: 225064
If the template specialization for externally managed sets in
PostOrderIterator call too far out of sync with each other, this unit
test will fail to build. This is especially useful for developers who
may not build Clang (the only in-tree user) every time.
llvm-svn: 222447
As detailed at http://llvm.org/PR20728, due to an internal overflow in
APFloat::multiplySignificand the APFloat::fusedMultiplyAdd method can return
incorrect results for x87DoubleExtended (x86_fp80) values. This commonly
manifests as incorrect constant folding of libm fmal calls on x86. E.g.
fmal(1.0L, 1.0L, 3.0L) == 0.0L (should be 4.0L)
This patch fixes PR20728 by adding an extra bit to the significand for
intermediate results of APFloat::multiplySignificand, avoiding the overflow.
llvm-svn: 222374
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
A subtle bug was found where attempting to copy a non-const function_ref
lvalue would actually invoke the generic forwarding constructor (as it
was a closer match - being T& rather than the const T& of the implicit
copy constructor). In the particular case this lead to a dangling
function_ref member (since it had referenced the function_ref passed by
value to its ctor, rather than the outer function_ref that was still
alive)
SFINAE the converting constructor to not be considered if the copy
constructor is available and demonstrate that this causes the copy to
refer to the original functor, not to the function_ref it was copied
from. (without the code change, the test would fail as Y would be
referencing X and Y() would see the result of the mutation to X, ie: 2)
llvm-svn: 221753
This operation is analogous to its counterpart in DenseMap: It allows lookup
via cheap-to-construct keys (provided that getHashValue and isEqual are
implemented for the cheap key-type in the DenseMapInfo specialization).
Thanks to Chandler for the review.
llvm-svn: 220168
to what we actually want ilogb implementation. This makes everything
*much* easier to deal with and is actually what we want when using it
anyways.
llvm-svn: 219474
code using it more readable.
Also add a copySign static function that works more like the standard
function by accepting the value and sign-carying value as arguments.
No interesting logic here, but tests added to cover the basic API
additions and make sure they do something plausible.
llvm-svn: 219453
This can be used for in-place initialization of non-moveable types.
For compilers that don't support variadic templates, only up to four
arguments are supported. We can always add more, of course, but this
should be good enough until we move to a later MSVC that has full
support for variadic templates.
Inspired by std::experimental::optional from the "Library Fundamentals" C++ TS.
Reviewed by David Blaikie.
llvm-svn: 218732
This takes a single argument convertible to T, and
- if the Optional has a value, returns the existing value,
- otherwise, constructs a T from the argument and returns that.
Inspired by std::experimental::optional from the "Library Fundamentals" C++ TS.
llvm-svn: 218618
It's not clear what the semantics of a self-move should be. The
consensus appears to be that a self-move should leave the object in a
moved-from state, which is what our existing move assignment operator
does.
However, the MSVC 2013 STL will perform self-moves in some cases. In
particular, when doing a std::stable_sort of an already sorted APSInt
vector of an appropriate size, one of the merge steps will self-move
half of the elements.
We don't notice this when building with MSVC, because MSVC will not
synthesize the move assignment operator for APSInt. Presumably MSVC
does this because APInt, the base class, has user-declared special
members that implicitly delete move special members. Instead, MSVC
selects the copy-assign operator, which defends against self-assignment.
Clang, on the other hand, selects the move-assign operator, and we get
garbage APInts.
llvm-svn: 215478
Remove the MinGW32 and Cygwin types from the OSType enumeration. These values
are represented via environments of Windows. It is a source of confusion and
needlessly clutters the code. The cost of doing this is that we must sink the
check for them into the normalization code path along with the spelling.
Addresses PR20592.
llvm-svn: 215303
checking whether the ArrayRef is equal to an explicit list of arguments.
This is particularly easy to implement even without variadic templates
because ArrayRef happens to be homogeneously typed. As a consequence we
can use a "clever" wrapper type and default arguments to capture in
a single method many arguments as well as *how many* arguments the user
specified.
Thanks to Dave Blaikie for helping me pull together this little helper.
Suggestions for how to improve or generalize it are of course welcome.
I'll be using it immediately in my follow-up patch. =D
llvm-svn: 214041
Add a `MapVector::remove_if()` that erases items in bulk in linear time,
as opposed to quadratic time for repeated calls to `MapVector::erase()`.
llvm-svn: 213090
Actually update the changed indexes in the map portion of `MapVector`
when erasing from the middle. Add a unit test that checks for this.
Note that `MapVector::erase()` is a linear time operation (it was and
still is). I'll commit a new method in a moment called
`MapVector::remove_if()` that deletes multiple entries in linear time,
which should be slightly less painful.
llvm-svn: 213084
The slice(N, M) interface is powerful but not concise when wanting to
drop a few elements off of an ArrayRef, fix this by adding a drop_back
method.
llvm-svn: 212370
Certain versions of GCC (~4.7) couldn't handle the SFINAE on access
control, but with "= delete" (hidden behind a macro for portability)
this issue is worked around/addressed.
Patch by Agustín Bergé
llvm-svn: 211525
Unfortunately there's no way to elegantly do this with pre-canned
algorithms. Using a generating iterator doesn't work because you default
construct for each element, then move construct into the actual slot
(bad for copy but non-movable types, and a little unneeded overhead even
in the move-only case), so just write it out manually.
This solution isn't exception safe (if one of the element's ctors calls
we don't fall back, destroy the constructed elements, and throw on -
which std::uninitialized_fill does do) but SmallVector (and LLVM) isn't
exception safe anyway.
llvm-svn: 210495
To test cases that involve actual repetition (> 1 elements), at least
one element before the insertion point, and some elements of the
original range that still fit in that range space after insertion.
Actually we need coverage for the inverse case too (where no elements
after the insertion point fit into the previously allocated space), but
this'll do for now, and I might end up rewriting bits of SmallVector to
avoid that special case anyway.
llvm-svn: 210436
Specifically this caused inserting an element from a SmallVector into
itself when such an insertion would cause a reallocation. We have code
to handle this for non-reallocating cases, but it's not robust against
reallocation.
llvm-svn: 210430
(& because it makes it easier to test, this also improves
correctness/performance slightly by moving the last element in an insert
operation, rather than copying it)
llvm-svn: 210429
Because we don't have a separate negate( ) function, 0 - NaN does double-duty as the IEEE-754 negate( ) operation, which (unlike most FP ops) *does* attach semantic meaning to the signbit of NaN.
llvm-svn: 210428
This would cause the last element in a range to be in a moved-from state
after an insert at a non-end position, losing that value entirely in the
process.
Side note: move_backward is subtle. It copies [A, B) to C-1 and down.
(the fact that it decrements both the second and third iterators before
the first movement is the subtle part... kind of surprising, anyway)
llvm-svn: 210426
When we were moving from a larger vector to a smaller one but didn't
need to re-allocate, we would move-assign over uninitialized memory in
the target, then move-construct that same data again.
llvm-svn: 207663
It's fishy to be changing the `std::vector<>` owned by the iterator, and
no one actual does it, so I'm going to remove the ability in a
subsequent commit. First, update the users.
<rdar://problem/14292693>
llvm-svn: 207252
This generalises the object file type parsing to all Windows environments. This
is used by cygwin as well as MSVC environments for MCJIT. This also makes the
triple more similar to Chandler's suggestion of a separate field for the object
file format.
llvm-svn: 205219
If the environment is unknown and no object file is provided, then assume an
"MSVC" environment, otherwise, set the environment to the object file format.
In the case that we have a known environment but a non-native file format for
Windows (COFF) which is used for MCJIT, then append the custom file format to
the triple as an additional component.
This fixes the MCJIT tests on Windows.
llvm-svn: 205130
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
Construct a uniform Windows target triple nomenclature which is congruent to the
Linux counterpart. The old triples are normalised to the new canonical form.
This cleans up the long-standing issue of odd naming for various Windows
environments.
There are four different environments on Windows:
MSVC: The MS ABI, MSVCRT environment as defined by Microsoft
GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries
Itanium: The MSVCRT environment + libc++ built with Itanium ABI
Cygnus: The Cygwin environment which uses custom libraries for everything
The following spellings are now written as:
i686-pc-win32 => i686-pc-windows-msvc
i686-pc-mingw32 => i686-pc-windows-gnu
i686-pc-cygwin => i686-pc-windows-cygnus
This should be sufficiently flexible to allow us to target other windows
environments in the future as necessary.
llvm-svn: 204977
This reverts commit r203374.
Ambiguities in assign... oh well. I'm just going to revert this and
probably not try to recommit it as it's not terribly important.
llvm-svn: 203375
Move a common utility (assign(iter, iter)) into SmallVector (some of the
others could be moved there too, but this one seemed particularly
generic) and replace repetitions overrides with using directives.
And simplify SmallVector::assign(num, element) while I'm here rather
than thrashing these files (that cause everyone to rebuild) again.
llvm-svn: 203374
Previously, the assertions in PointerIntPair would try to calculate the value
(1 << NumLowBitsAvailable); the inferred type here is 'int', so if there were
more than 31 bits available we'd get a shift overflow.
Also, add a rudimentary unit test file for PointerIntPair.
llvm-svn: 203273
This is a preliminary setup change to support a renaming of Windows target
triples. Split the object file format information out of the environment into a
separate entity. Unfortunately, file format was previously treated as an
environment with an unknown OS. This is most obvious in the ARM subtarget where
the handling for macho on an arbitrary platform switches to AAPCS rather than
APCS (as per Apple's needs).
llvm-svn: 203160
The interaction between defaulted operators and move elision isn't
totally obvious, add a unit test so it doesn't break unintentionally.
llvm-svn: 202662
it interoperate (minimally) with std::unique_ptr<T>. This is part of my
plan to migrate LLVM to use std::unique_ptr with a minimal impact on
out-of-tree code.
Patch by Ahmed Charles with some minor cleanups (and bool casts) by me.
llvm-svn: 202608
In theory, Clang should figure out how to parse this correctly without
typename, but since this is the last TU that Clang falls back on in the
self-host, I'm going to compromise and check for __clang__.
And now Clang can self-host on -win32 without fallback! The 'check' and
'check-clang' targets both pass.
llvm-svn: 201358
There are a couple of interesting things here that we want to check over
(particularly the expecting asserts in StringRef) and get right for general use
in ADT so hold back on this one. For clang we have a workable templated
solution to use in the meanwhile.
This reverts commit r200187.
llvm-svn: 200194
(1) Add llvm_expect(), an asserting macro that can be evaluated as a constexpr
expression as well as a runtime assert or compiler hint in release builds. This
technique can be used to construct functions that are both unevaluated and
compiled depending on usage.
(2) Update StringRef using llvm_expect() to preserve runtime assertions while
extending the same checks to static asserts in C++11 builds that support the
feature.
(3) Introduce ConstStringRef, a strong subclass of StringRef that references
compile-time constant strings. It's convertible to, but not from, ordinary
StringRef and thus can be used to add compile-time safety to various interfaces
in LLVM and clang that only accept fixed inputs such as diagnostic format
strings that tend to get misused.
llvm-svn: 200187
This was due to arithmetic overflow in the getNumBits() computation. Now we
cast BitWidth to a uint64_t so that does not occur during the computation. After
the computation is complete, the uint64_t is truncated when the function
returns.
I know that this is not something that is likely to happen, but it *IS* a valid
input and we should not blow up.
llvm-svn: 199609
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
llvm-svn: 198685
This functionality was enabled by r198374. Here's a test to ensure it
works and we don't regress it.
Based on a patch by Maciej Piechotka.
llvm-svn: 198377
Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful
option and can give surprising results (like tail calls being disabled).
5.0 seems like a reasonable compromise as a platform that's still interesting
to some people.
rdar://problem/15567348
llvm-svn: 196912
Enhance the tests to actually require moves in C++11 mode, in addition
to testing the moved-from state. Further enhance the tests to cover
copy-assignment into a moved-from object and moving a large-state
object. (Note that we can't really test small-state vs. large-state as
that isn't an observable property of the API really.) This should finish
addressing review on r195239.
llvm-svn: 195261
r195239, as well as a comment about the fact that assigning over
a moved-from object was in fact tested. Addresses some of the review
feedback on r195239.
llvm-svn: 195260
Somehow, this ADT got missed which is moderately terrifying considering
the efficiency of move for it.
The code to implement move semantics for it is pretty horrible
currently but was written to reasonably closely match the rest of the
code. Unittests that cover both copying and moving (at a basic level)
added.
llvm-svn: 195239
This patch places class definitions in implementation files into anonymous
namespaces to prevent weak vtables. This eliminates the need of providing an
out-of-line definition to pin the vtable explicitly to the file.
llvm-svn: 195092
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 195064
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
llvm-svn: 194997
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
This bug only bit the C++98 build bots because all of the actual uses
really do move. ;] But not *quite* ready to do the whole C++11 switch
yet, so clean it up. Also add a unit test that catches this immediately.
llvm-svn: 194548
r-value references. I still want to test that when we have them,
llvm_move is actually a move.
Have I mentioned that I really want to move to C++11? ;]
llvm-svn: 194318
Clang managed to never instantiate the copy constructor. Added tests to
ensure this path is tested.
We could still use tests for the polymorphic nature. Those coming up
next.
llvm-svn: 194317
unique ownership smart pointer which is *deep* copyable by assuming it
can call a T::clone() method to allocate a copy of the owned data.
This is mostly useful with containers or other collections of uniquely
owned data in C++98 where they *might* copy. With C++11 we can likely
remove this in favor of move-only types and containers wrapped around
those types.
llvm-svn: 194315
startswith_lower is ocassionally useful and I think worth adding.
endwith_lower is added for completeness.
Differential Revision: http://llvm-reviews.chandlerc.com/D2041
llvm-svn: 193706
Jun Bum Lim