[APInt] Normalize naming on keep constructors / predicate methods.

This renames the primary methods for creating a zero value to `getZero`
instead of `getNullValue` and renames predicates like `isAl

[APInt] Normalize naming on keep constructors / predicate methods.

This renames the primary methods for creating a zero value to `getZero`
instead of `getNullValue` and renames predicates like `isAllOnesValue`
to simply `isAllOnes`. This achieves two things:

1) This starts standardizing predicates across the LLVM codebase,
following (in this case) ConstantInt. The word "Value" doesn't
convey anything of merit, and is missing in some of the other things.

2) Calling an integer "null" doesn't make any sense. The original sin
here is mine and I've regretted it for years. This moves us to calling
it "zero" instead, which is correct!

APInt is widely used and I don't think anyone is keen to take massive source
breakage on anything so core, at least not all in one go. As such, this
doesn't actually delete any entrypoints, it "soft deprecates" them with a
comment.

Included in this patch are changes to a bunch of the codebase, but there are
more. We should normalize SelectionDAG and other APIs as well, which would
make the API change more mechanical.

Differential Revision: https://reviews.llvm.org/D109483

show more ...

[lldb] Fix compilation after removal of APInt::toString

[lldb/Utility] Polish the Scalar class

This patch is mostly about removing the "Category" enum, which was
very useful when the Type enum contained a large number of types, but
now the two are comple

[lldb/Utility] Polish the Scalar class

This patch is mostly about removing the "Category" enum, which was
very useful when the Type enum contained a large number of types, but
now the two are completely identical.

It also removes some other artifacts like unused typedefs and macros.

show more ...

[lldb/Utility] Use APSInt in the Scalar class

This enables us to further simplify some code because it no longer needs
to switch on the signedness of the type (APSInt handles that).

[lldb] Fix gcc 5.4.0 compile error

Specify type when constructing PromotionKeys,
this fixes error:
"chosen constructor is explicit in copy-initialization"
when compiling lldb with GCC 5.4.0.

This i

[lldb] Fix gcc 5.4.0 compile error

Specify type when constructing PromotionKeys,
this fixes error:
"chosen constructor is explicit in copy-initialization"
when compiling lldb with GCC 5.4.0.

This is due to std::tuple having an explicit
default constructor, see:
http://cplusplus.github.io/LWG/lwg-defects.html#2193

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D86690

show more ...

[lldb/Utility] Remove some Scalar type accessors

Now that the number of Scalar "types" has been reduced, these don't make
sense anymore.

[lldb/Utility] Simplify Scalar handling of float types

Similarly to D85836, collapse all Scalar float types to a single enum
value, and use APFloat semantics to differentiate between. This
simplifie

[lldb/Utility] Simplify Scalar handling of float types

Similarly to D85836, collapse all Scalar float types to a single enum
value, and use APFloat semantics to differentiate between. This
simplifies the code, and opens to door to supporting other floating
point semantics (which would be needed for fully supporting
architectures with more interesting float types such as PPC).

Differential Revision: https://reviews.llvm.org/D86220

show more ...

[lldb/Utility] Simplify and generalize Scalar class

The class contains an enum listing all host integer types as well as
some non-host types. This setup is a remnant of a time when this class
was ac

[lldb/Utility] Simplify and generalize Scalar class

The class contains an enum listing all host integer types as well as
some non-host types. This setup is a remnant of a time when this class
was actually implemented in terms of host integer types. Now that we are
using llvm::APInt, they are mostly useless and mean that each function
needs to enumerate all of these cases even though it treats most of them
identically.

I only leave e_sint and e_uint to denote the integer signedness, but I
want to remove that in a follow-up as well.

Removing these cases simplifies most of these functions, with the only
exception being PromoteToMaxType, which can no longer rely on a simple
enum comparison to determine what needs to be promoted.

This also makes the class ready to work with arbitrary integer sizes, so
it does not need to be modified when someone needs to add a larger
integer size.

Differential Revision: https://reviews.llvm.org/D85836

show more ...

[lldb/Utility] Simplify Scalar::PromoteToMaxType

The function had very complicated signature, because it was trying to
avoid making unnecessary copies of the Scalar object. However, this
class is no

[lldb/Utility] Simplify Scalar::PromoteToMaxType

The function had very complicated signature, because it was trying to
avoid making unnecessary copies of the Scalar object. However, this
class is not hot enough to worry about these kinds of optimizations. My
making copies unconditionally, we can simplify the function and all of
its call sites.

Differential Revision: https://reviews.llvm.org/D85906

show more ...

[lldb/Utility] Clean up Scalar constructors

- move initialization to initializer lists
- make desctructor non-virtual (nothing else is)
- fix long double constructor so that it actually works

[lldb] Eliminate unneeded value parameters in Utility (NFC)

Eliminates value parameter for types that are not trivially copyable.

[lldb/Utility] Simplify Scalar::SetValueFromData

The function was fairly complicated and didn't support new bigger
integer sizes. Use llvm function for loading an APInt from memory to
write a unifie

[lldb/Utility] Simplify Scalar::SetValueFromData

The function was fairly complicated and didn't support new bigger
integer sizes. Use llvm function for loading an APInt from memory to
write a unified implementation for all sizes.

show more ...

[lldb/Utility] Rewrite Scalar::SetValueFromCString

The function's reliance on host types meant that it was needlessly
complicated, and did not handle the newer (wider) types. Rewrite it in
terms of

[lldb/Utility] Rewrite Scalar::SetValueFromCString

The function's reliance on host types meant that it was needlessly
complicated, and did not handle the newer (wider) types. Rewrite it in
terms of APInt/APFloat functions to save code and improve functionality.

show more ...

[lldb/Utility] Simplify Scalar float accessors

Make use of APFloat conversion methods to avoid needing to switch based
on the stored value type.

[lldb/Utility] Fix float->integral conversions in Scalar APInt getters

These functions were doing a bitcast on the float value, which is not
consistent with the other getters, which were doing a num

[lldb/Utility] Fix float->integral conversions in Scalar APInt getters

These functions were doing a bitcast on the float value, which is not
consistent with the other getters, which were doing a numeric conversion
(47.0 -> 47). Change these to do numeric conversions too.

show more ...

[lldb/Utility] Merge Scalar::Get(Value)TypeAsCString

[lldb/Utility] Simplify more Scalar methods

A lot of the methods handle all integral and all floating point types
the same way. They can be changed to switch on the category of the type,
instead of

[lldb/Utility] Simplify more Scalar methods

A lot of the methods handle all integral and all floating point types
the same way. They can be changed to switch on the category of the type,
instead of the actual type, saving a lot of boilerplate.

This patch does that for the methods where I could be reasonably certain
of their expected semantics.

show more ...

[lldb] Fix type conversion in the Scalar getters

Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
co

[lldb] Fix type conversion in the Scalar getters

Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
conversions done in the getter methods.

These functions had a subtle bug: when extending the type, they used the
signedness of the *target* type in order to determine whether to do
sign-extension or zero-extension. This is not how things work in C,
which uses the signedness of the *source* type. I.e., C does
(sign-)extension before it does signed->unsigned conversion, and not the
other way around.

This means that: (unsigned long)(int)-1
is equal to (unsigned long)0xffffffffffffffff
and not (unsigned long)0x00000000ffffffff

Unsurprisingly, we have accumulated code which depended on this
inconsistent behavior. It mainly manifested itself as code calling
"ULongLong/SLongLong" as a way to get the value of the Scalar object in
a primitive type that is "large enough". Previously, the ULongLong
conversion did not do sign-extension, but now it does.

This patch makes the Scalar getters consistent with the declared
semantics, and fixes the couple of call sites that were using it
incorrectly.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D82772

show more ...

[lldb] Scalar re-fix UB in float->int conversions

The refactor in 48ca15592f1 reintroduced UB when converting out-of-bounds
floating point numbers to integers -- the behavior for ULongLong() was
ori

[lldb] Scalar re-fix UB in float->int conversions

The refactor in 48ca15592f1 reintroduced UB when converting out-of-bounds
floating point numbers to integers -- the behavior for ULongLong() was
originally fixed in r341685, but did not survive my refactor because I
based my template code on one of the methods which did not have this
fix.

This time, I apply the fix to all float->int conversions, instead of
just the "double->unsigned long long" case. I also use a slightly
simpler version of the code, with fewer round-trips
(APFloat->APSInt->native_int vs
APFloat->native_float->APInt->native_int).

I also add some unit tests for the conversions.

show more ...

[lldb/Scalar] Fix undefined behavior

Fix UBSan error detected in TestDataFormatterObjCCF.py and
TestDataFormatterObjCNSDate.py:

Scalar.cpp:698:27: runtime error: -4.96303e+08 is outside the range o

[lldb/Scalar] Fix undefined behavior

Fix UBSan error detected in TestDataFormatterObjCCF.py and
TestDataFormatterObjCNSDate.py:

Scalar.cpp:698:27: runtime error: -4.96303e+08 is outside the range of
representable values of type 'unsigned long long'.

show more ...

[lldb] Deduplicate Scalar integral getters

These functions all follow the same pattern. Use template functions to
deduplicate.

[lldb] Rewrite Scalar::Promote

This function was implementing c-like promotion rules by switching on
the both types. C promotion rules are complicated, but they are not
*that* complicated -- they ba

[lldb] Rewrite Scalar::Promote

This function was implementing c-like promotion rules by switching on
the both types. C promotion rules are complicated, but they are not
*that* complicated -- they basically boil down to:
- wider types trump narrower ones
- unsigned trump signed
- floating point trumps integral

With a couple of helper functions, we can rewrite the function in terms
of these rules and greatly reduce the size and complexity of this
function.

show more ...

[lldb] Rewrite Scalar::GetBytes

This function was modifying and returning pointers to static storage,
which meant that any two accesses to different Scalar objects could
potentially race (depending

[lldb] Rewrite Scalar::GetBytes

This function was modifying and returning pointers to static storage,
which meant that any two accesses to different Scalar objects could
potentially race (depending on which types the objects were storing and
the host endianness).

In the new version the user is responsible for providing a buffer into
which this method will store its binary representation. The main caller
(RegisterValue::GetBytes) already has one such buffer handy, so this did
not require any major rewrites.

To make that work, I've needed to mark the RegisterValue value buffer
mutable -- not an ideal solution, but definitely better than modifying
global storage. This could be further improved by changing
RegisterValue::GetBytes to take a buffer too.

show more ...

[lldb] Refactor Scalar::TruncOrExtendTo

The "type" argument to the function is mostly useless -- the only
interesting aspect of it is signedness. Pass signedness directly and
compute the value of bi

[lldb] Refactor Scalar::TruncOrExtendTo

The "type" argument to the function is mostly useless -- the only
interesting aspect of it is signedness. Pass signedness directly and
compute the value of bits and signedness fields -- that's exactly
what the single caller of this function does.

show more ...

[lldb] Remove Scalar operator= overloads

The are not needed as Scalar is implicitly constructible from all of
these types (so the compiler will use a combination of a constructor +
move assignment i

[lldb] Remove Scalar operator= overloads

The are not needed as Scalar is implicitly constructible from all of
these types (so the compiler will use a combination of a constructor +
move assignment instead), and they make it very easy for implementations
of assignment and construction operations to diverge.

show more ...