| Age | Commit message (Collapse) | Author |
|---|
|
In line with a std proposal to introduce std::clmul, and in preparation
to introduce a clmul intrinsic, implement carry-less multiply primitives
for APIntOps, clmul[rh].
Ref: https://isocpp.org/files/papers/P3642R3.html
|
|
These operations are required for #153151.
|
|
qp is already of uint64_t.
|
|
Adds `mulsExtended` and `muluExtended` methods to `APInt`, as suggested
in #153293.
These are based on the `MULDQ` and `MULUDQ` x86 intrinsics.
|
|
lo/himasks (#141108)
Fixes #141098
|
|
|
|
Added APInt::clearBits(unsigned loBit, unsigned hiBit) that clears bits within a certain range.
Fixes #136550
---------
Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk>
|
|
Remove erroneous extra semicolon in:
https://github.com/llvm/llvm-project/pull/122788
Co-authored-by: ImanHosseini <imanhosseini.17@gmail.com>
|
|
I am trying to calculate power function for APFloat, APInt to constant
fold vector reductions: https://github.com/llvm/llvm-project/pull/122450
I need this utility to fold N `mul`s into power.
---------
Co-authored-by: ImanHosseini <imanhosseini.17@gmail.com>
Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
|
|
|
|
Use an arithmetic shift for the last word copy when BitShift!=0. This
avoids an explicit sign extend after the shift.
|
|
The purpose is to save an extra memset in both cases:
1. When `int64_t(val) < 0`, zeroing out is redundant as the subsequent
for-loop will initialize to `val .. 0xFFFFF ....`. Instead we should
only create an uninitialized buffer, and transform the slow for-loop
into a memset to initialize the higher words to `0xFF`.
2. In the other case, first we create an uninitialized array (`new
int64_t[]`) and _then_ we zero it out with `memset`. But this can be
combined in one operation with `new int64_t[]()`, which
default-initializes the array.
On one example where use of APInt was heavy, this improved compile time
by 1%.
|
|
If the uint64_t constructor is used, assert that the value is actually a
signed or unsigned N-bit integer depending on whether the isSigned flag
is set. Provide an implicitTrunc flag to restore the previous behavior,
where the argument is silently truncated instead.
In this commit, implicitTrunc is enabled by default, which means that
the new assertions are disabled and no actual change in behavior occurs.
The plan is to flip the default once all places violating the assertion
have been fixed. See #80309 for the scope of the necessary changes.
The primary motivation for this change is to avoid incorrectly specified
isSigned flags. A recurring problem we have is that people write
something like `APInt(BW, -1)` and this works perfectly fine -- until
the code path is hit with `BW > 64`. Most of our i128 specific
miscompilations are caused by variants of this issue.
The cost of the change is that we have to specify the correct isSigned
flag (and make sure there are no excess bits) for uses where BW is
always <= 64 as well.
|
|
In order to guarantee that extracting 64 bits doesn't require more than
2 words, the word size would need to be 64 bits or more. If the word
size was smaller than 64, like 32, you may need to read 3 words to get
64 bits.
|
|
|
|
|
|
tcFullMultiply. NFCI (#88202)
The tcMultiplyPart routine has a flag that says whether to add to the
accumulator or overwrite it. By using the overwrite mode on the first
iteration we don't need to initialize the accumulator to zero.
Note, the initialization in tcFullMultiply was only initializing the
first rhsParts of dst. tcMultiplyPart always overwrites the rhsParts+1
part that just contains the last carry. The first write to each part of
dst past rhsParts is a carry write so that's how the upper part of dst
is initialized.
|
|
multiplicativeInverse. (#87655)
This allows the subtract to reuse the storage of T. T will be assigned
over by the condition on the next iteration. I think assigning over a
moved from value should be ok.
|
|
All callers have been changed to use the new simpler overload with an
implicit modulus of 2^BitWidth. The old form was never used or tested
with non-power-of-two modulus anyway.
|
|
The current APInt::multiplicativeInverse takes a modulus which can be
any value, but all in-tree callers use a power of two. Moreover, most
callers want to use two to the power of the width of an existing APInt,
which is awkward because 2^N is not representable as an N-bit APInt.
Add a new overload of multiplicativeInverse which implicitly uses
2^BitWidth as the modulus.
|
|
Fixes #84207
|
|
for mlir fold to avoid too many overflow state check
|
|
Removing the extension to FullWidth should make them much more efficient
in the 64-bit case, because 65-bit APInts use a separate allocation for
their bits.
|
|
Supports both signed and unsigned expansions.
SelectionDAG now calls the APInt implementation of these functions.
Fixes #84211.
|
|
Add functionality to APInt::toString() that allows it to insert
separators between groups of digits, using the C++ literal
separator ' between groups.
Fixes issue #58228
Reviewers: @AaronBallman, @cjdb, @tbaederr
|
|
This showed up in https://reviews.llvm.org/D153308
Reviewed By: courbet, nikic
Differential Revision: https://reviews.llvm.org/D153356
|
|
D111241 added support for extractBits() with zero width. Extend this
to extractBitsAsZExtValue() as well for consistency (in which case
it will always return zero).
Differential Revision: https://reviews.llvm.org/D151788
|
|
Add overloads of sshl_ov, ushl_ov, sshl_sat and ushl_sat that take the
shift amount as unsigned instead of APInt. This matches what we do for
the normal shift operators and can help to avoid creating temporary
APInts in some cases.
Differential Revision: https://reviews.llvm.org/D151420
|
|
This will be used in implementing arbitrary precision support to
FileCheck's numeric variables and expressions.
Reviewed By: foad, RKSimon
Differential Revision: https://reviews.llvm.org/D150879
|
|
|
|
library.
This makes a code a bit more clear and also gets rid of C4146 warning
on MSVC compiler:
'unary minus operator applied to unsigned type, result still unsigned'.
In case uint64_t variable is initialized or compared against -1U expression,
which corresponds to 32-bit constant, UINT_MAX macro is used to preserve
NFC semantics; -1ULL is replaced with UINT64_MAX.
Reviewed By: dblaikie, craig.topper
Differential Revision: https://reviews.llvm.org/D143942
|
|
|
|
|
|
partMSB and partLSB never get 0 as the argument. That is, we don't
rely on find{First,Last}Set's ability to return
std::numeric_limits<T>::max() on input 0.
This patch replaces partLSB and partMSB with llvm::countr_zero and
llvm::Log2_64, respectively.
FWIW, nobody in LLVM (except unit test MathExtrasTest.cpp) relies on
find{First,Last}Set's ability to return std::numeric_limits<T>::max()
on input 0.
|
|
|
|
|
|
This patch uses the default parameters of countTrailingZeros,
findFirstSet, and findLastSet, which are ZB_Width, ZB_Max, and ZB_Max,
respectively.
|
|
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
|
|
These files no longer use llvm::Optional.
|
|
|
|
|
|
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This is already included in APInt.h
|
|
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D128570
|
|
This reverts commit 5fe5aa284efed1ee1492e1f266351b35f0a8bb69.
|
|
|
|
Differential Revision: https://reviews.llvm.org/D125559
|
|
Most clients only used these methods because they wanted to be able to
extend or truncate to the same bit width (which is a no-op). Now that
the standard zext, sext and trunc allow this, there is no reason to use
the OrSelf versions.
The OrSelf versions additionally have the strange behaviour of allowing
extending to a *smaller* width, or truncating to a *larger* width, which
are also treated as no-ops. A small amount of client code relied on this
(ConstantRange::castOp and MicrosoftCXXNameMangler::mangleNumber) and
needed rewriting.
Differential Revision: https://reviews.llvm.org/D125557
|
|
Allow zext, sext, trunc, truncUSat and truncSSat to extend or truncate
to the same bit width, which is a no-op.
Disallowing this forced clients to use workarounds like using
zextOrTrunc (even though they never wanted truncation) or zextOrSelf
(even though they did not want its strange behaviour of allowing a
*smaller* bit width, which is also treated as a no-op).
Differential Revision: https://reviews.llvm.org/D125556
|
|
WG14 adopted N2775 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2775.pdf)
at our Feb 2022 meeting. This paper adds a literal suffix for
bit-precise types that automatically sizes the bit-precise type to be
the smallest possible legal _BitInt type that can represent the literal
value. The suffix chosen is wb (for a signed bit-precise type) which
can be combined with the u suffix (for an unsigned bit-precise type).
The preprocessor continues to operate as-if all integer types were
intmax_t/uintmax_t, including bit-precise integer types. It is a
constraint violation if the bit-precise literal is too large to fit
within that type in the context of the preprocessor (when still using
a pp-number preprocessing token), but it is not a constraint violation
in other circumstances. This allows you to make bit-precise integer
literals that are wider than what the preprocessor currently supports
in order to initialize variables, etc.
|
