| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This annoyed me a few times but was lazy so I haven't fixed it
until today, when the output of my debugger was too confusing.
llvm-svn: 293691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
For reference:
- Public headers should just declare the dump() method but not use
LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void MyClass::dump() {
// print stuff to dbgs()...
}
#endif
llvm-svn: 293359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There's a comment in XorSlowCase that says "0^0==1" which isn't true. 0 xored with 0 is still 0. So I don't think we need to clear any unused bits here.
Now there is no difference between XorSlowCase and AndSlowCase/OrSlowCase other than the operation being performed
Reviewers: majnemer, MatzeB, chandlerc, bkramer
Reviewed By: MatzeB
Subscribers: chfast, llvm-commits
Differential Revision: https://reviews.llvm.org/D28986
llvm-svn: 292873
|
|
|
|
| |
llvm-svn: 291147
|
|
|
|
| |
llvm-svn: 281450
|
|
|
|
|
|
|
|
|
|
| |
This patch changes LLVM_CONSTEXPR variable declarations to const
variable declarations, since LLVM_CONSTEXPR expands to nothing if the
current compiler doesn't support constexpr. In all of the changed
cases, it looks like the code intended the variable to be const instead
of sometimes-constexpr sometimes-not.
llvm-svn: 279696
|
|
|
|
|
|
|
|
| |
i64 -1, whose sign bit is the 0th one, can't be left shifted without invoking UB.
https://reviews.llvm.org/D23362
llvm-svn: 278280
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds versions of operator + and - which are optimized for the LHS/RHS of the
operator being RValue's. When an RValue is available, we can use its storage space
instead of allocating new space.
On code such as ConstantRange which makes heavy use of APInt's over 64-bits in size,
this results in significant numbers of saved allocations.
Thanks to David Blaikie for all the review and most of the code here.
llvm-svn: 276470
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: davide
Subscribers: davide, llvm-commits
Differential Revision: http://reviews.llvm.org/D21638
llvm-svn: 273851
|
|
|
|
| |
llvm-svn: 273727
|
|
|
|
|
|
| |
This fixes PR28294.
llvm-svn: 273722
|
|
|
|
|
|
|
| |
Avoids unnecessary copies. All changes audited & pass tests with asan.
No functional change intended.
llvm-svn: 272190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APInt::operator+(uint64_t) just forwarded to operator+(const APInt&).
Constructing the APInt for the RHS takes an allocation which isn't
required. Also, for APInt's in the slow path, operator+ would
call add() internally which iterates over both arrays of values. Instead
we can use add_1 and sub_1 which only iterate while there is something to do.
Using the memory for 'opt -O2 verify-uselistorder.lto.opt.bc -o opt.bc'
(see r236629 for details), this reduces the number of allocations from
23.9M to 22.7M.
llvm-svn: 270959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APInt::slt was copying the LHS and RHS in to temporaries then making
them unsigned so that it could use an unsigned comparision. It did
this even on the paths which were trivial to give results for, such
as the sign bit of the LHS being set while RHS was not set.
This changes the logic to return out immediately in the trivial cases,
and use an unsigned comparison in the remaining cases. But this time,
just use the unsigned comparison directly without creating any temporaries.
This works because, for example:
true = (-2 slt -1) = (0xFE ult 0xFF)
Also added some tests explicitly for slt with APInt's larger than 64-bits
so that this new code is tested.
Using the memory for 'opt -O2 verify-uselistorder.lto.opt.bc -o opt.bc'
(see r236629 for details), this reduces the number of allocations from
26.8M to 23.9M.
llvm-svn: 270881
|
|
|
|
|
|
|
|
|
|
|
| |
declarations (NFC)
Differential Revision: http://reviews.llvm.org/D19154
Patch by Eugene Kosov <claprix@yandex.ru>
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266524
|
|
|
|
| |
llvm-svn: 263945
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.
llvm-svn: 261270
|
|
|
|
|
|
|
|
|
| |
We always clear the unused bits in the most signifant word so there is
no need to mask them out in countLeadingZerosSlowCase().
Differential Revision: http://reviews.llvm.org/D16621
llvm-svn: 260911
|
|
|
|
| |
llvm-svn: 260910
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the code used getActiveBits() to determine the highest set
bit of each APInt first. However doing so requires the same amount of
memory accesses as simply comparing both numbers right away.
Removing all the active bit checks leads to simpler code and is faster
in my benchmark.
Differential Revision: http://reviews.llvm.org/D16620
llvm-svn: 260447
|
|
|
|
|
|
|
|
| |
r259192 post commit comment.
clang part in r259232, this is the LLVM part of the patch.
llvm-svn: 259240
|
|
|
|
|
|
| |
Apparently, the style needs to be agreed upon first.
llvm-svn: 240390
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 234158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
To complement getSplat. This is more general than the binary
decomposition method as it also handles non-pow2 splat sizes.
llvm-svn: 233195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Saves adding .str() call to any raw_ostream << SmallString usage
and a small step towards making .str() consistent in the ADTs by
removing one of the SmallString::str() use cases, discussion at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141013/240026.html
I'll update the Phabricator patch http://reviews.llvm.org/D6372
for review of the Twine SmallString support, it's more complex
than this one.
llvm-svn: 231763
|
|
|
|
|
|
| |
All supported platforms have half-way decent C99 support.
llvm-svn: 231679
|
|
|
|
|
|
|
|
| |
with countTrailingZeros
Update all callers.
llvm-svn: 228930
|
|
|
|
|
|
|
|
| |
This mirrors the behavior of APInt::udiv and APInt::urem. Some
architectures, like X86, have a single instruction which can compute
both division and remainder.
llvm-svn: 224217
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a transform that changes:
(x lshr C1) udiv C2
into:
x udiv (C2 << C1)
However, it is unsafe to do so if C2 << C1 discards any of C2's bits.
This fixes PR21255.
llvm-svn: 219634
|
|
|
|
| |
llvm-svn: 219588
|
|
|
|
|
|
| |
Saves a couple of expensive deep copies. NFC.
llvm-svn: 219487
|
|
|
|
| |
llvm-svn: 217597
|
|
|
|
|
|
| |
definition below all of the header #include lines, lib/Support edition.
llvm-svn: 206847
|
|
|
|
| |
llvm-svn: 205697
|
|
|
|
|
|
|
| |
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
llvm-svn: 200018
|
|
|
|
|
|
| |
Change tests for extractBit to test operator[].
llvm-svn: 197277
|
|
|
|
| |
llvm-svn: 197271
|
|
|
|
| |
llvm-svn: 183073
|
|
|
|
|
|
|
|
| |
use in APFloat IEEE-754R 2008 nextUp/nextDown function.
rdar://13852078
llvm-svn: 182801
|
|
|
|
| |
llvm-svn: 182680
|
|
|
|
|
|
| |
They are generally faster (at least not slower) than post-inc, post-dec.
llvm-svn: 177608
|
|
|
|
|
|
|
| |
require call cpp file anyway, so we wouldn't gain anything by keeping them
inline.
llvm-svn: 175579
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
|
|
|
| |
llvm-svn: 164767
|
|
|
|
|
|
| |
This caused 6 of 65k possible 8 bit udivs to be wrong.
llvm-svn: 160058
|