| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 302983
|
|
|
|
| |
llvm-svn: 302974
|
|
|
|
|
|
|
|
| |
We already counted the number of bits in the RHS so its pretty cheap to just check if the RHS is 1.
Differential Revision: https://reviews.llvm.org/D33154
llvm-svn: 302953
|
|
|
|
|
|
|
|
| |
reread it from the LHS which might be aliased with Quotient or Remainder.
This helped the compiler generate better code for the single word case. It was able to remember that the bit width was still a single word when it created the Remainder APInt and not create code for it possibly being multiword.
llvm-svn: 302952
|
|
|
|
|
|
| |
udiv and urem already had the same assert.
llvm-svn: 302931
|
|
|
|
|
|
|
|
| |
and udivrem. NFC
At this point in the code rhsWords is guaranteed to be non-zero and less than or equal to lhsWords. So if lhsWords is 1, rhsWords must also be 1. urem alread had the check removed so this makes all 3 consistent.
llvm-svn: 302930
|
|
|
|
|
|
| |
instead of reusing the original.
llvm-svn: 302882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APInt.
Summary:
This adds a resize method to APInt that manages deleting/allocating storage for an APInt and changes its bit width. Use this to simplify code in copy assignment and divide.
The assignment code in particular was overly complicated. Treating every possible case as a separate implementation. I'm also pretty sure the clearUnusedBits code at the end was unnecessary. Since we always copying whole words from the source APInt. All unused bits should be clear in the source.
Reviewers: hans, RKSimon
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33073
llvm-svn: 302863
|
|
|
|
| |
llvm-svn: 302816
|
|
|
|
| |
llvm-svn: 302815
|
|
|
|
| |
llvm-svn: 302806
|
|
|
|
|
|
| |
Conversion rules allow automatic casting of nullptr to any pointer type.
llvm-svn: 302780
|
|
|
|
|
|
| |
Turns out udivrem can write its output to the same location as one of its inputs so the extra temporary isn't needed.
llvm-svn: 302772
|
|
|
|
|
|
| |
writing back over the original value.
llvm-svn: 302770
|
|
|
|
|
|
|
|
| |
This time it actually occurred to me to change the #defines
to actually test the pre-processed out codepath. Hopefully
this time it works.
llvm-svn: 302752
|
|
|
|
|
|
|
| |
TaskGroup and Latch need to be in llvm::parallel::detail, not
in llvm::detail.
llvm-svn: 302751
|
|
|
|
| |
llvm-svn: 302749
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D33024
llvm-svn: 302748
|
|
|
|
|
|
| |
shorten code.
llvm-svn: 302716
|
|
|
|
|
|
|
|
|
|
| |
method directly. Do a better job of reusing allocations while looping. NFCI
This lets toString take advantage of the degenerate case checks in udivrem and is just generally cleaner.
One minor downside of this is that the divisor APInt now needs to be the same size as Tmp which requires an additional allocation. But we were doing a poor job of reusing allocations before so the new code should still be an improvement.
llvm-svn: 302704
|
|
|
|
|
|
| |
divide code. Use Lo_32/Hi_32/Make_64 helpers instead of casts and shifts. NFCI
llvm-svn: 302703
|
|
|
|
| |
llvm-svn: 302702
|
|
|
|
|
|
| |
in the function. NFC
llvm-svn: 302701
|
|
|
|
|
|
| |
initialization.
llvm-svn: 302626
|
|
|
|
|
|
| |
reimplementinging it.
llvm-svn: 302625
|
|
|
|
|
|
|
|
| |
The description says it returns the number of words needed to represent the results. But the way it was coded it always returns (lhsWords + rhsWords) or (lhsWords + rhsWords - 1). But the result could be even smaller than that and it wouldn't tell you.
No one uses the result today so rather than try to fix it, just remove it.
llvm-svn: 302551
|
|
|
|
|
|
|
|
| |
in udiv and urem. NFC
The default constructor does the same thing.
llvm-svn: 302487
|
|
|
|
| |
llvm-svn: 302486
|
|
|
|
|
|
|
|
| |
the earlier loop. NFC
The value of 'i' is always the smaller of DstParts and SrcParts so we can just use that fact to write all the code in terms of SrcParts and DstParts.
llvm-svn: 302408
|
|
|
|
|
|
| |
operator. NFC
llvm-svn: 302407
|
|
|
|
| |
llvm-svn: 302406
|
|
|
|
| |
llvm-svn: 302403
|
|
|
|
|
|
| |
This makes multiply similar to add, sub, xor, and, and or.
llvm-svn: 302402
|
|
|
|
|
|
| |
This can happen at least on NetBSD.
llvm-svn: 302263
|
|
|
|
| |
llvm-svn: 302246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case multiply size
Currently multiply is implemented in operator*=. Operator* makes a copy and uses operator*= to modify the copy.
Operator*= itself allocates a temporary buffer to hold the multiply result as it computes it. Then copies it to the buffer in *this.
Operator*= attempts to bound the size of the result based on the number of active bits in its inputs. It also has a couple special cases to handle 0 inputs without any memory allocations or multiply operations. The best case is that it calculates a single word regardless of input bit width. The worst case is that it calculates the a 2x input width result and drop the upper bits.
Since operator* uses operator*= it incurs two allocations, one for a copy of *this and one for the temporary allocation. Neither of these allocations are kept after the method operation is done.
The main usage in the backend appears to be ConstantRange::multiply which uses operator* rather than operator*=.
This patch moves the multiply operation to operator* and implements operator*= using it. This avoids the copy in operator*. operator* now allocates a result buffer sized the same width as its inputs no matter what. This buffer will be used as the buffer for the returned APInt. Finally, we reuse tcMultiply to implement the multiply operation. This function is capable of not calculating additional upper words that will be discarded.
This change does lose the special optimizations for the inputs using less words than their size implies. But it also removed the getActiveBits calls from all multiplies. If we think those optimizations are important we could look at providing additional bounds to tcMultiply to limit the computations.
Differential Revision: https://reviews.llvm.org/D32830
llvm-svn: 302171
|
|
|
|
|
|
| |
ArchKind is passed to the function, but it's also a type.
llvm-svn: 302081
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, each CPU has to manually specify the extensions it supports,
even though they have to be a superset of the base arch extensions.
And when there's redundant data there's stale data, so most of the CPUs
lie about the features they support (almost none lists AEK_FP).
Instead, do the saner thing: add the optional extensions on top of the
base extensions provided by the architecture.
The ARM TargetParser has the same behavior.
Differential Revision: https://reviews.llvm.org/D32780
llvm-svn: 302078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was reverted due to a "missing" file, but in reality
what happened was that I renamed a file, and then due to
a merge conflict both the old file and the new file got
added to the repository. This led to an unused cpp file
being in the repo and not referenced by any CMakeLists.txt
but #including a .h file that wasn't in the repo. In an
even more unfortunate coincidence, CMake didn't report the
unused cpp file because it was in a subdirectory of the
folder with the CMakeLists.txt, and not in the same directory
as any CMakeLists.txt.
The presence of the unused file was then breaking certain
tools that determine file lists by globbing rather than
by what's specified in CMakeLists.txt
In any case, the fix is to just remove the unused file from
the patch set.
llvm-svn: 302042
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Reapplied - this time without changing line endings of existing files.
Differential Revision: https://reviews.llvm.org/D32769
llvm-svn: 302041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being the larger member
Currently several places assume the VAL member is always at least the same size as pVal. In particular for a memcpy in the move assignment operator. While this is a true assumption, it isn't good practice to assume this.
This patch gives the union a name so we can write the memcpy in terms of the union itself. This also adds a similar memcpy to the move constructor where we previously just copied using VAL directly.
This patch is mostly just a mechanical addition of the U in front of VAL and pVAL everywhere. But several constructors had to be modified since we can't directly initializer a field of named union from the initializer list.
Differential Revision: https://reviews.llvm.org/D30629
llvm-svn: 302040
|
|
|
|
| |
llvm-svn: 302038
|
|
|
|
|
|
|
|
| |
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Differential Revision: https://reviews.llvm.org/D32769
llvm-svn: 302028
|
|
|
|
|
|
|
|
|
|
|
| |
The "macosx" OS type is still the canonical type. In the future "macos" will
become the canonical OS type (but we will still support "macosx").
rdar://27043820
Differential Revision: https://reviews.llvm.org/D32748
llvm-svn: 302011
|
|
|
|
|
|
|
|
|
| |
The patch is failing to add StringTableStreamBuilder.h, but that isn't
even discovered because the corresponding StringTableStreamBuilder.cpp
isn't added to any CMakeLists.txt file and thus never built. I think
this patch is just incomplete.
llvm-svn: 302002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had knowledge of how to serialize and deserialize
a string table inside of DebugInfo/PDB, but the string table
that it serializes contains a piece that is actually considered
CodeView and can appear outside of a PDB. We already have logic
in llvm-readobj and MCCodeView to read and write this format,
so it doesn't make sense to duplicate the logic in DebugInfoPDB
as well.
This patch makes codeview::StringTable (for writing) and
codeview::StringTableRef (for reading), updates DebugInfoPDB
to use these classes for its own writing, and updates llvm-readobj
to additionally use StringTableRef for reading.
It's a bit more difficult to get MCCodeView to use this for
writing, but it's a logical next step.
llvm-svn: 301986
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D32728
llvm-svn: 301940
|
|
|
|
|
|
| |
I think this method is probably too complex to be inlined.
llvm-svn: 301901
|
|
|
|
|
|
| |
This makes setBit/clearBit more consistent with setBits which is already inlined.
llvm-svn: 301900
|
|
|
|
|
|
|
|
| |
Patch by: Gergely Angeli!
Differential Revision: https://reviews.llvm.org/D31936
llvm-svn: 301807
|