| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
We already have a function toHex that will convert a string like
"\xFF\xFF" to the string "FFFF", but we do not have one that goes
the other way - i.e. to convert a textual string representing a
sequence of hexadecimal characters into the corresponding actual
bytes. This patch adds such a function.
llvm-svn: 301356
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ashrInPlace.
This patch adds an in place version of ashr to match lshr and shl which were recently added.
I've tried to make this similar to the lshr code with additions to handle the sign extension. I've also tried to do this with less if checks than the current ashr code by sign extending the original result to a word boundary before doing any of the shifting. This removes a lot of the complexity of determining where to fill in sign bits after the shifting.
Differential Revision: https://reviews.llvm.org/D32415
llvm-svn: 301198
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: SUSE's ARM triples end with -gnueabi even though they are hard-float. This requires special handling of SUSE ARM triples. Hence we need a way to differentiate the SUSE as vendor. This CL adds that.
Reviewers: chandlerc, compnerd, echristo, rengolin
Reviewed By: rengolin
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D32426
llvm-svn: 301174
|
| |
|
|
|
|
|
|
| |
multi word.
Previously single word would always return 0 regardless of the original sign. Multi word would return all 0s or all 1s based on the original sign. Now single word takes into account the sign as well.
llvm-svn: 301159
|
| |
|
|
|
|
|
|
| |
constructor mask off any excess bits.
The current code is trying to be clever with shifts to avoid needing to clear unused bits. But it looks like the compiler is unable to optimize out the unused bit handling in the APInt constructor. Given this its better to just use SignExtend64 and have more readable code.
llvm-svn: 301133
|
| |
|
|
|
|
|
|
|
|
| |
a bug in the shift by BitWidth handling."
This reverts commit r301094, as it broke all ARM self-hosting bots.
PR32754.
llvm-svn: 301110
|
| |
|
|
|
|
|
|
| |
in the shift by BitWidth handling.
For single word, shift by BitWidth was always returning 0, but for multiword it was based on original sign. Now single word matches multi word.
llvm-svn: 301094
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D32302
llvm-svn: 301014
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
snprinf
This should fix the bug https://bugs.llvm.org/show_bug.cgi?id=12906
To print the FP constant AsmWriter does the following:
1) convert FP value to String (actually using snprintf function which is locale dependent).
2) Convert String back to FP Value
3) Compare original and got FP values. If they are not equal just dump as hex.
The problem happens on the 2nd step when APFloat does not expect group delimiter or
fraction delimiter other than period symbol and so on, which can be produced on the
first step if LLVM library is used in an environment with corresponding locale set.
To fix this issue the locale independent APFloat:toString function is used.
However it prints FP values slightly differently than snprintf does. Specifically
it suppress trailing zeros in significant, use capital E and so on.
It results in 117 test failures during make check.
To avoid this I've also updated APFloat.toString a bit to pass make check at least.
Reviewers: sberg, bogner, majnemer, sanjoy, timshen, rnk
Reviewed By: timshen, rnk
Subscribers: rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D32276
llvm-svn: 300943
|
| |
|
|
|
|
|
|
|
| |
This was failing due to the use of assigning a Mask to an
unsigned, rather than to a BitWord. But most systems do not
have sizeof(unsigned) == sizeof(unsigned long), so the mask
was getting truncated.
llvm-svn: 300857
|
| |
|
|
|
|
|
| |
This is causing test failures on Linux / BSD systems. Reverting
while I investigate.
llvm-svn: 300852
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
another without creating temporary APInts
This question comes up in many places in SimplifyDemandedBits. This makes it easy to ask without allocating additional temporary APInts.
The BitVector class provides a similar functionality through its (IMHO badly named) test(const BitVector&) method. Though its output polarity is reversed.
I've provided one example use case in this patch. I plan to do more as a follow up.
Differential Revision: https://reviews.llvm.org/D32258
llvm-svn: 300851
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D32244
llvm-svn: 300848
|
| |
|
|
|
|
|
|
| |
methods aren't called with values larger than BitWidth."
This includes a fix to clamp a right shift of larger than BitWidth in DAG combining.
llvm-svn: 300816
|
| |
|
|
|
|
|
|
| |
methods aren't called with values larger than BitWidth."
This is failing a self host debug build.
llvm-svn: 300813
|
| |
|
|
|
|
|
|
| |
called with values larger than BitWidth.
The underlying tcShiftRight/tcShiftLeft functions support the larger bit widths but the APInt interface shouldn't rely on that.
llvm-svn: 300811
|
| |
|
|
|
|
| |
tcShiftLeft and use it to implement operator<<=.
llvm-svn: 300526
|
| |
|
|
|
|
|
|
|
|
|
|
| |
single implementation
This merges the two different multiword shift right implementations into a single version located in tcShiftRight. lshrInPlace now calls tcShiftRight for the multiword case.
I retained the memmove fast path from lshrInPlace and used a memset for the zeroing. The for loop is basically tcShiftRight's implementation with the zeroing and the intra-shift of 0 removed.
Differential Revision: https://reviews.llvm.org/D32114
llvm-svn: 300503
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was added to work around a bug in MSVC 2013's implementation of stable_sort. That bug has been fixed as of MSVC 2015 so we shouldn't need this anymore.
Technically the current implementation has undefined behavior because we only protect the deleting of the pVal array with the self move check. There is still a memcpy of that.VAL to VAL that isn't protected. In the case of self move those are the same local and memcpy is undefined for src and dst overlapping.
This reduces the size of the opt binary on my local x86-64 build by about 4k.
Differential Revision: https://reviews.llvm.org/D32116
llvm-svn: 300477
|
| |
|
|
|
|
| |
This was throwing an assert because we determined the intra-word shift amount by subtracting the size of the full word shift from the total shift amount. But we failed to account for the fact that we clipped the full word shifts by total words first. To fix this just calculate the intra-word shift as the remainder of dividing by bits per word.
llvm-svn: 300405
|
| |
|
|
|
|
| |
Example strings taken from here: http://www.let.rug.nl/~kleiweg/lev/
llvm-svn: 300312
|
| |
|
|
|
|
|
|
|
|
|
| |
Switch from Euclid's algorithm to Stein's algorithm for computing GCD. This
avoids the (expensive) APInt division operation in favour of bit operations.
Remove all memory allocation from within the GCD loop by tweaking our `lshr`
implementation so it can operate in-place.
Differential Revision: https://reviews.llvm.org/D31968
llvm-svn: 300252
|
| |
|
|
| |
llvm-svn: 299873
|
| |
|
|
|
|
|
|
|
|
|
|
| |
BitVector had methods for searching for the first and next
set bits, but it did not have analagous methods for finding
the first and next unset bits. This is useful when your ones
and zeros are grouped together and you want to iterate over
ranges of ones and zeros.
Differential Revision: https://reviews.llvm.org/D31802
llvm-svn: 299857
|
| |
|
|
|
|
|
|
| |
This will be used in LCSSA to speed up the canonicalization.
Differential Revision: https://reviews.llvm.org/D31694
llvm-svn: 299660
|
| |
|
|
|
|
|
|
|
|
| |
class. Implement them without memory allocation for multiword
This moves the isMask and isShiftedMask functions to be class methods. They now use the MathExtras.h function for single word size and leading/trailing zeros/ones or countPopulation for the multiword size. The previous implementation made multiple temorary memory allocations to do the bitwise arithmetic operations to match the MathExtras.h implementation.
Differential Revision: https://reviews.llvm.org/D31565
llvm-svn: 299362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of integerPart. Make APINT_BITS_PER_WORD and APINT_WORD_SIZE public.
This patch is one step to attempt to unify the main APInt interface and the tc functions used by APFloat.
This patch adds a WordType to APInt and uses that in all the tc functions. I've added temporary typedefs to APFloat to alias it to integerPart to keep the patch size down. I'll work on removing that in a future patch.
In future patches I hope to reuse the tc functions to implement some of the main APInt functionality.
I may remove APINT_ from BITS_PER_WORD and WORD_SIZE constants so that we don't have the repetitive APInt::APINT_ externally.
Differential Revision: https://reviews.llvm.org/D31523
llvm-svn: 299341
|
| |
|
|
|
|
|
|
|
|
| |
in MathExtras.h
This removes a parameter from the routine that was responsible for a lot of the issue. It was a bit count that had to be set to the BitWidth of the APInt and would get passed to getLowBitsSet. This guaranteed the call to getLowBitsSet would create an all ones value. This was then compared to (V | (V-1)). So the only shifted masks we detected had to have the MSB set.
The one in tree user is a transform in InstCombine that never fires due to earlier transforms covering the case better. I've submitted a patch to remove it completely, but for now I've just adapted it to the new interface for isShiftedMask.
llvm-svn: 299273
|
| |
|
|
| |
llvm-svn: 299257
|
| |
|
|
|
|
|
|
| |
The previous version was prone to intermediate rounding or overflow.
Differential Revision: https://reviews.llvm.org/D29346
llvm-svn: 299256
|
| |
|
|
|
|
| |
in the multiword case. Rewrite getHiBits to use the class method version of lshr instead of the one in APIntOps. NFCI
llvm-svn: 299243
|
| |
|
|
| |
llvm-svn: 299197
|
| |
|
|
|
|
|
|
|
|
| |
APIntOps::isShiftedMask is.
Did you know that 0 is a shifted mask? But 0x0000ff00 and 0x000000ff aren't? At least we get 0xff000000 right.
I only see one usage of this function in the code base today and its in InstCombine. I think its protected against 0 being misreported as a mask. I guess we just don't have tests for the missed cases.
llvm-svn: 299187
|
| |
|
|
| |
llvm-svn: 298867
|
| |
|
|
| |
llvm-svn: 298841
|
| |
|
|
|
|
|
| |
The issue was trying to advance past the end of the iterator
when computing the end() iterator.
llvm-svn: 298461
|
| |
|
|
|
|
|
| |
This is causing crashes in clang, so reverting until the problem
is figured out.
llvm-svn: 298440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringMap's iterators did not support LLVM's
iterator_facade_base, which made it unusable in various
STL algorithms or with some of our range adapters.
This patch makes both StringMapConstIterator as well as
StringMapIterator support iterator_facade_base.
With this in place, it is easy to make an iterator adapter
that iterates over only keys, and whose value_type is
StringRef. So I add StringMapKeyIterator as well, and
provide the method StringMap::keys() that returns a
range that can be iterated.
Differential Revision: https://reviews.llvm.org/D31171
llvm-svn: 298436
|
| |
|
|
| |
llvm-svn: 298427
|
| |
|
|
|
|
| |
suffix
llvm-svn: 297674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were some issues in the implementation of enumerate()
preventing it from being used in various contexts. These were
all related to the fact that it did not supporter llvm's
iterator_facade_base class. So this patch adds support for that
and additionally exposes a new helper method to_vector() that
will evaluate an entire range and store the results in a
vector.
Differential Revision: https://reviews.llvm.org/D30853
llvm-svn: 297633
|
| |
|
|
| |
llvm-svn: 297460
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently have to insert bits via a temporary variable of the same size as the target with various shift/mask stages, resulting in further temporary variables, all of which require the allocation of memory for large APInts (MaskSizeInBits > 64).
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::insertBits() helper method which avoids the temporary memory allocation and masks/inserts the raw bits directly into the target.
Differential Revision: https://reviews.llvm.org/D30780
llvm-svn: 297458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Similar to SmallPtrSet, this makes find and count work with both const
referneces and const pointers.
Reviewers: dblaikie
Subscribers: llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D30713
llvm-svn: 297424
|
| |
|
|
| |
llvm-svn: 297423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix SmallPtrSet::iterator behaviour and creation ReverseIterate is true.
- Any function that creates an iterator now uses
SmallPtrSet::makeIterator, which creates an iterator that
dereferences to the given pointer.
- In reverse-iterate mode, initialze iterator::End with "CurArray"
instead of EndPointer.
- In reverse-iterate mode, the current node is iterator::Buffer[-1].
iterator::operator* and SmallPtrSet::makeIterator are the only ones
that need to know.
- Fix the assertions for reverse-iterate mode.
This fixes the tests Danny B added in r297182, and adds a couple of
others to confirm that dereferencing does the right thing, regardless of
how the iterator was found, and that iteration works correctly from each
return from find.
llvm-svn: 297234
|
| |
|
|
| |
llvm-svn: 297225
|
| |
|
|
| |
llvm-svn: 297182
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
their memory allocation to be reused when possible
This extends an earlier change that did similar for add and sub operations.
With this first patch we lose the fastpath for the single word case as operator&= and friends don't support it. This can be added there if we think that's important.
I had to change some functions in the APInt class since the operator overloads were moved out of the class and can't be used inside the class now. The getBitsSet change collides with another outstanding patch to implement it with setBits. But I didn't want to make this patch dependent on that series.
I've also removed the Or, And, Xor functions which were rarely or never used. I already commited two changes to remove the only uses of Or that existed.
Differential Revision: https://reviews.llvm.org/D30612
llvm-svn: 297121
|
| |
|
|
| |
llvm-svn: 297115
|