Actually use the `reference` typedef, and remove the private
redefinition of `pointer` since it has no users.
Using `reference` exposes a problem with r207257, which specified the
wrong `value_type` to `iterator_facade_base` (fixed that too).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207270 91177308-0d34-0410-b5e6-96231b3b80d8
Use the fancy new `iterator_facade_base` to add
`scc_iterator::operator->()`. Remove other definitions where
`iterator_facade_base` does the right thing.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207257 91177308-0d34-0410-b5e6-96231b3b80d8
These are long functions that really shouldn't be inlined. Otherwise,
no functionality change.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207249 91177308-0d34-0410-b5e6-96231b3b80d8
Functions declared in line in a class are inlined by default. There's
no reason for the `inline` keyword.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207248 91177308-0d34-0410-b5e6-96231b3b80d8
own CRTP base class for more general purpose use. Add some clarifying
comments for the exact way in which the adaptor uses it. Hopefully this
will help us write increasingly full featured iterators. This is
becoming important as they start to be used heavily inside of ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207072 91177308-0d34-0410-b5e6-96231b3b80d8
Boost's iterator_adaptor, and a specific adaptor which iterates over
pointees when wrapped around an iterator over pointers.
This is the result of a long discussion on IRC with Duncan Smith, Dave
Blaikie, Richard Smith, and myself. Essentially, I could use some subset
of the iterator facade facilities often used from Boost, and everyone
seemed interested in having the functionality in a reasonably generic
form. I've tried to strike a balance between the pragmatism and the
established Boost design. The primary differences are:
1) Delegating to the standard iterator interface names rather than
special names that then make up a second iterator-like API.
2) Using the name 'pointee_iterator' which seems more clear than
'indirect_iterator'. The whole business of calling the '*p' operation
'pointer indirection' in the standard is ... quite confusing. And
'dereference' is no better of a term for moving from a pointer to
a reference.
Hoping Duncan, and others continue to provide comments on this until
we've got a nice, minimal abstraction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207069 91177308-0d34-0410-b5e6-96231b3b80d8
r206916 was not logically the same as the previous code because the
goto statements did not create loop. This should be the same as the
previous code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206918 91177308-0d34-0410-b5e6-96231b3b80d8
Goto statements jumping into previous inner blocks are pretty confusing
to read even though in this case they are valid. No reason to not use
while loops there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206916 91177308-0d34-0410-b5e6-96231b3b80d8
This warning is disabled for the LLVM build,
but external users of the header can still
run into this.
Patch by Ke Bai
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206629 91177308-0d34-0410-b5e6-96231b3b80d8
Doesn't make sense to restrict this to BumpPtrAllocator. While there
replace an explicit loop with std::equal. Some standard libraries know
how to compile this down to a ::memcmp call if possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206615 91177308-0d34-0410-b5e6-96231b3b80d8
allocation libraries, may allow more efficient allocation and
deallocation. It at least makes the interface implementable by the JIT
memory manager.
However, this highlights problematic overloading between the void* and
the T* deallocation functions. I'm looking into a better way to do this,
but as it happens, it comes up rarely in the codebase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206265 91177308-0d34-0410-b5e6-96231b3b80d8
Also updated as many loops as I could find using df_begin/idf_begin -
strangely I found no uses of idf_begin. Is that just used out of tree?
Also a few places couldn't use df_begin because either they used the
member functions of the depth first iterators or had specific ordering
constraints (I added a comment in the latter case).
Based on a patch by Jim Grosbach. (Jim - you just had iterator_range<T>
where you needed iterator_range<idf_iterator<T>>)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206016 91177308-0d34-0410-b5e6-96231b3b80d8
Move the iterators into the range the same way the range's ctor moves
them into the members.
Also remove some redundant top level parens in the return statement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205993 91177308-0d34-0410-b5e6-96231b3b80d8
Convenience wrapper to make dealing with sub-ranges easier. Like the
iterator_range<> itself, if/when this sort of thing gets standards
blessing, it will be replaced by the official version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205987 91177308-0d34-0410-b5e6-96231b3b80d8
Using this file would result in an odr violation: it defines an llvm::Interval
class that conflicts with the one in Analysis/Interval.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205726 91177308-0d34-0410-b5e6-96231b3b80d8
It affected callee's stack pop in x86. It is one of devergences between cygwin and mingw since mingw-gcc-4.6.
Added testcases to llvm/test/CodeGen/X86/win32_sret.ll for cygwin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205688 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary step to lifting some of its configuration into
template parameters rather than runtime parameters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205140 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205090 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204977 91177308-0d34-0410-b5e6-96231b3b80d8
If we use a pair with an enum type this could create values outside
of the enum range. Avoid it by creating the bit pattern directly.
While there turn a dynamic assert into a static one. No functionality
change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204010 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203375 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203374 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203273 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203160 91177308-0d34-0410-b5e6-96231b3b80d8
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
Move the test for this class into the IR unittests as well.
This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202821 91177308-0d34-0410-b5e6-96231b3b80d8
remove_if that its predicate is adaptable. We don't actually need this,
we can write a generic adapter for any predicate.
This lets us remove some very wrong std::function usages. We should
never be using std::function for predicates to algorithms. This incurs
an *indirect* call overhead for every evaluation of the predicate, and
makes it very hard to inline through.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202742 91177308-0d34-0410-b5e6-96231b3b80d8
Breaks the MSVC build.
DataStream.cpp(44): error C2552: 'llvm::Statistic::Value' : non-aggregates cannot be initialized with initializer list
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202731 91177308-0d34-0410-b5e6-96231b3b80d8
With C++11 we finally have a standardized way to specify atomic operations. Use
them to replace the existing custom implemention. Sadly the translation is not
entirely trivial as std::atomic allows more fine-grained control over the
atomicity. I tried to preserve the old semantics as well as possible.
Differential Revision: http://llvm-reviews.chandlerc.com/D2915
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202730 91177308-0d34-0410-b5e6-96231b3b80d8
proposed std::iterator_pair which was in committee suggested to move
toward std::iterator_range. There isn't a formal paper yet, but there
seems little disagreement within the committee at this point so it seems
fine to provide our own version in the llvm namespace so we can easily
build range adaptors for the numerous iterators in LLVM's interfaces.
Note that I'm not really comfortable advocating a crazed range-based
migration just yet. The range stuff is still in a great deal of flux in
C++ and the committee hasn't entirely made up its mind (afaict) about
how it will work. So I'm mostly trying to provide the minimal
functionality needed to make writing easy and convenient range adaptors
for range based for loops easy and convenient. ;]
Subsequent patches will use this across the fundamental IR types, where
there are iterator views.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202686 91177308-0d34-0410-b5e6-96231b3b80d8
The interaction between defaulted operators and move elision isn't
totally obvious, add a unit test so it doesn't break unintentionally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202662 91177308-0d34-0410-b5e6-96231b3b80d8
Prevent a crash in the SmallDenseMap copy constructor whenever the other
map is not in small mode.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202206 91177308-0d34-0410-b5e6-96231b3b80d8
Now to copy a string into a BumpPtrAllocator and get a StringRef to the copy:
StringRef myCopy = myStr.copy(myAllocator);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200885 91177308-0d34-0410-b5e6-96231b3b80d8
iteration. This alows the majority of operations to be performed without
encoding a specific small size. It follows the model of
SmallVectorImpl<T>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200688 91177308-0d34-0410-b5e6-96231b3b80d8
'SmallPtrSetImplBase'. This more closely matches the organization of
SmallVector and should allow introducing a SmallPtrSetImpl which serves
the same purpose as SmallVectorImpl: isolating the element type from the
particular small size chosen. This in turn allows a lot of
simplification of APIs by not coding them against a specific small size
which is rarely needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200687 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200194 91177308-0d34-0410-b5e6-96231b3b80d8
StringRef is a low-level data wrapper that shouldn't know about language
strings like 'true' and 'false' whereas StringExtras is just the place for
higher-level utilities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200188 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200187 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199609 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
where it's only bool-like 1/0 result like std::set.count().
Some of the LLVM ADT already return unsigned count(), while
others return bool count().
This patch modifies SmallPtrSet, SmallSet, SparseSet count()
to return unsigned instead of bool:
1 instead of true
0 instead of false
More ADT to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197879 91177308-0d34-0410-b5e6-96231b3b80d8
Most users would be surprised if "isCOFF" and "isMachO" were simultaneously
true, unless they'd put the compiler in a box with a gun attached to a photon
detector.
This makes sure precisely one of the three formats is true for any triple and
simplifies some target logic based on that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196934 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196471 91177308-0d34-0410-b5e6-96231b3b80d8
class name. I think we're no longer using any compilers with
sufficiently broken ICN for this use case, but I'll watch the bots and
introduce a typedef without a reserved name if any yell at me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195793 91177308-0d34-0410-b5e6-96231b3b80d8
doxygen comments, make existing comments doxygen comments etc.
Also, switch commented-out debug helpers to #if-0-ed out debug helpers.
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195783 91177308-0d34-0410-b5e6-96231b3b80d8
This matches other empty() container functions in LLVM.
No actual usage problems discovered in this instance.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195562 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195261 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195239 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194548 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194315 91177308-0d34-0410-b5e6-96231b3b80d8
This problem was found and fixed by José Fonseca in March 2011 for
SmallPtrSet, committed r128566. But as far as I can tell, all other
llvm hash tables retain the same problem: the bucket count can grow
without bound while size() remains near constant by repeated
insert/erase cycles that tend to fill the container with tombstones.
Here is a demo that has been reduced to a trivial case:
int
main()
{
llvm::DenseSet<unsigned> d;
for (unsigned i = 0; i < 0xFFFFFFF; ++i)
{
d.insert(i);
d.erase(i);
}
}
While the container size() never grows above 1, the bucket count grows
like this:
nb = 64
nb = 128
nb = 256
nb = 512
nb = 1024
nb = 2048
nb = 4096
nb = 8192
nb = 16384
nb = 32768
nb = 65536
nb = 131072
nb = 262144
nb = 524288
nb = 1048576
nb = 2097152
nb = 4194304
nb = 8388608
nb = 16777216
nb = 33554432
nb = 67108864
nb = 134217728
nb = 268435456
The above program currently consumes a few GB ram. This patch brings
the memory consumption down by several orders of magnitude, and keeps
the bucket count at 64 for the above test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193689 91177308-0d34-0410-b5e6-96231b3b80d8
The underlying type of all plain enums in MSVC is 'int', even if the
enumerator contains large 32-bit unsigned values or values greater than
UINT_MAX. The only way to get a large or unsigned enum type is to
request it explicitly with the C++11 strong enum types feature.
However, since LLVM isn't C++11 yet, I had to add a conditional
LLVM_ENUM_INT_TYPE to Compiler.h to control its usage.
The motivating true positive for this change is compiling PointerIntPair
with MSVC for win64. The PointerIntMask value is supposed to be pointer
sized value of all ones with some low zeros. Instead, it's truncated to
32-bits! We are only saved later because it is sign extended back in
the AND with int64_t, and we happen to want all ones.
This silences lots of -Wmicrosoft warnings during a clang self-host
targeting Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191241 91177308-0d34-0410-b5e6-96231b3b80d8
This makes using array_pod_sort significantly safer. The implementation relies
on function pointer casting but that should be safe as we're dealing with void*
here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191175 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Made UnicodeCharSet a class, perform validity checking inside its
constructor instead of each isCharInSet call, use std::binary_search instead of
own implementation.
This patch comes with a necessary change in clang (sent separately).
Reviewers: jordan_rose, klimek
Reviewed By: klimek
CC: cfe-commits, rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1534
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189582 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This support will be utilized in things like clang to help check printf
format specifiers that are only valid when using the VSCRT.
Reviewers: rnk, asl, chandlerc
Reviewed By: chandlerc
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1455
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188935 91177308-0d34-0410-b5e6-96231b3b80d8
r187874 seems to have been missed by the build bot infrastructure, and
the subsequent commits to compiler-rt don't seem to be queuing up new
build requsets. Hopefully this will.
As it happens, having the space here is the more common formatting. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187879 91177308-0d34-0410-b5e6-96231b3b80d8
lld has a hashtable with StringRef keys; it needs to iterate over the keys in
*insertion* order. This is currently implemented as std::vector<StringRef> +
DenseMap<StringRef, T>. This will probably need a proper
DenseMapInfo<StringRef> if we don't want to lose memory/performance by
migrating to a different data structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187868 91177308-0d34-0410-b5e6-96231b3b80d8
for StringRef with a StringMap
The bug is that the empty key compares equal to the tombstone key.
Also added an assertion to DenseMap to catch similar bugs in future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187866 91177308-0d34-0410-b5e6-96231b3b80d8
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187179 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the implementation in include/llvm/Support/YAMLTraits.h.
Added a DenseMap type DITypeHashMap in DebugInfo.h:
DenseMap<std::pair<StringRef, unsigned>, MDNode*>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185852 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r185099.
Looks like both the ppc-64 and mips bots are still failing after I reverted this
change.
Since:
1. The mips bot always performs a clean build,
2. The ppc64-bot failed again after a clean build (I asked the ppc-64
maintainers to clean the bot which they did... Thanks Will!),
I think it is safe to assume that this change was not the cause of the failures
that said builders were seeing. Thus I am recomitting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185111 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r185095. This is causing a FileCheck failure on
the 3dnow intrinsics on at least the mips/ppc bots but not on the x86
bots.
Reverting while I figure out what is going on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185099 91177308-0d34-0410-b5e6-96231b3b80d8
The category which an APFloat belongs to should be dependent on the
actual value that the APFloat has, not be arbitrarily passed in by the
user. This will prevent inconsistency bugs where the category and the
actual value in APFloat differ.
I also fixed up all of the references to this constructor (which were
only in LLVM).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185095 91177308-0d34-0410-b5e6-96231b3b80d8
exponent_t is only used internally in APFloat and no exponent_t values are
exposed via the APFloat API. In light of such conditions it does not make any
sense to gum up the llvm namespace with said type. Plus it makes it clearer that
exponent_t is associated with APFloat.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184686 91177308-0d34-0410-b5e6-96231b3b80d8
IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184579 91177308-0d34-0410-b5e6-96231b3b80d8
The old isNormal is already functionally replaced by the method isFiniteNonZero
in r184350 and all references to said method were replaced in LLVM/clang in
r184356/134366.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184449 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:
1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184350 91177308-0d34-0410-b5e6-96231b3b80d8
building outside projects with a different compiler than that used to build
LLVM itself (eg switching between gcc and clang).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183650 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically the following work was done:
1. If the operation was not implemented, I implemented it.
2. If the operation was already implemented, I just moved its location
in the APFloat header into the IEEE-754R 5.7.2 section. If the name was
incorrect, I put in a comment giving the true IEEE-754R name.
Also unittests have been added for all of the functions which did not
already have a unittest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183179 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed in clang so one can check if the object needs the
destructor called after its memory was freed. This is useful when
creating many APInt/APFloat objects with placement new, where the
overhead of tracking the pointers for cleanup is significant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183100 91177308-0d34-0410-b5e6-96231b3b80d8
reject things like: "for (auto Entry : SomeStringMap)". Previously
this would copy the value but not the tail allocated string data
(the key).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182713 91177308-0d34-0410-b5e6-96231b3b80d8
BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.
This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181868 91177308-0d34-0410-b5e6-96231b3b80d8
