Skip to content

Conversation

@Michael137
Copy link
Member

There were a couple of quirks with this parameter:

  1. It wasn't being set consistently. E.g., vector types would be of count 1 but complex types would be 2. Hence, it wasn't clear what count was referring to.
  2. count was not being set if the input type was invalid, possibly leaving the input reference uninitialized.
  3. Only one callsite actually made use of count, and that in itself seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can implement one with a new TypeSystem API that does exactly that.

There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
   count `1` but complex types would be `2`. Hence, it wasn't clear what
   count was referring to.
2. `count` was not being set if the input type was invalid, possibly
   leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
   seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.
@llvmbot
Copy link
Member

llvmbot commented Oct 30, 2025

@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)

Changes

There were a couple of quirks with this parameter:

  1. It wasn't being set consistently. E.g., vector types would be of count 1 but complex types would be 2. Hence, it wasn't clear what count was referring to.
  2. count was not being set if the input type was invalid, possibly leaving the input reference uninitialized.
  3. Only one callsite actually made use of count, and that in itself seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can implement one with a new TypeSystem API that does exactly that.


Full diff: https://github.com/llvm/llvm-project/pull/165702.diff

8 Files Affected:

  • (modified) lldb/include/lldb/Symbol/CompilerType.h (+1-1)
  • (modified) lldb/include/lldb/Symbol/Type.h (+1-1)
  • (modified) lldb/include/lldb/Symbol/TypeSystem.h (+1-2)
  • (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+3-7)
  • (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h (+1-2)
  • (modified) lldb/source/Symbol/CompilerType.cpp (+5-5)
  • (modified) lldb/source/Symbol/Type.cpp (+2-2)
  • (modified) lldb/source/ValueObject/ValueObject.cpp (+2-4)
diff --git a/lldb/include/lldb/Symbol/CompilerType.h b/lldb/include/lldb/Symbol/CompilerType.h
index df8489a7fe582..1fcf255123d9f 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -400,7 +400,7 @@ class CompilerType {
   /// Return the size of the type in bits.
   llvm::Expected<uint64_t> GetBitSize(ExecutionContextScope *exe_scope) const;
 
-  lldb::Encoding GetEncoding(uint64_t &count) const;
+  lldb::Encoding GetEncoding() const;
 
   lldb::Format GetFormat() const;
 
diff --git a/lldb/include/lldb/Symbol/Type.h b/lldb/include/lldb/Symbol/Type.h
index e657357b942f1..02b43e300a83e 100644
--- a/lldb/include/lldb/Symbol/Type.h
+++ b/lldb/include/lldb/Symbol/Type.h
@@ -507,7 +507,7 @@ class Type : public std::enable_shared_from_this<Type>, public UserID {
 
   lldb::Format GetFormat();
 
-  lldb::Encoding GetEncoding(uint64_t &count);
+  lldb::Encoding GetEncoding();
 
   SymbolContextScope *GetSymbolContextScope() { return m_context; }
   const SymbolContextScope *GetSymbolContextScope() const { return m_context; }
diff --git a/lldb/include/lldb/Symbol/TypeSystem.h b/lldb/include/lldb/Symbol/TypeSystem.h
index 0ec3a28898329..40a80d8d09286 100644
--- a/lldb/include/lldb/Symbol/TypeSystem.h
+++ b/lldb/include/lldb/Symbol/TypeSystem.h
@@ -317,8 +317,7 @@ class TypeSystem : public PluginInterface,
   GetBitSize(lldb::opaque_compiler_type_t type,
              ExecutionContextScope *exe_scope) = 0;
 
-  virtual lldb::Encoding GetEncoding(lldb::opaque_compiler_type_t type,
-                                     uint64_t &count) = 0;
+  virtual lldb::Encoding GetEncoding(lldb::opaque_compiler_type_t type) = 0;
 
   virtual lldb::Format GetFormat(lldb::opaque_compiler_type_t type) = 0;
 
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 82dfe7e540717..61c5550423dfe 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4859,12 +4859,10 @@ TypeSystemClang::GetTypeBitAlign(lldb::opaque_compiler_type_t type,
   return {};
 }
 
-lldb::Encoding TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type,
-                                            uint64_t &count) {
+lldb::Encoding TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type) {
   if (!type)
     return lldb::eEncodingInvalid;
 
-  count = 1;
   clang::QualType qual_type = RemoveWrappingTypes(GetCanonicalQualType(type));
 
   switch (qual_type->getTypeClass()) {
@@ -4898,7 +4896,6 @@ lldb::Encoding TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type,
   case clang::Type::DependentVector:
   case clang::Type::ExtVector:
   case clang::Type::Vector:
-    // TODO: Set this to more than one???
     break;
 
   case clang::Type::BitInt:
@@ -5099,11 +5096,10 @@ lldb::Encoding TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type,
       const clang::ComplexType *complex_type =
           qual_type->getAsComplexIntegerType();
       if (complex_type)
-        encoding = GetType(complex_type->getElementType()).GetEncoding(count);
+        encoding = GetType(complex_type->getElementType()).GetEncoding();
       else
         encoding = lldb::eEncodingSint;
     }
-    count = 2;
     return encoding;
   }
 
@@ -5160,7 +5156,7 @@ lldb::Encoding TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type,
   case clang::Type::SubstBuiltinTemplatePack:
     break;
   }
-  count = 0;
+
   return lldb::eEncodingInvalid;
 }
 
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index 9e0a54209345d..11107c0fea4f6 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -837,8 +837,7 @@ class TypeSystemClang : public TypeSystem {
   GetBitSize(lldb::opaque_compiler_type_t type,
              ExecutionContextScope *exe_scope) override;
 
-  lldb::Encoding GetEncoding(lldb::opaque_compiler_type_t type,
-                             uint64_t &count) override;
+  lldb::Encoding GetEncoding(lldb::opaque_compiler_type_t type) override;
 
   lldb::Format GetFormat(lldb::opaque_compiler_type_t type) override;
 
diff --git a/lldb/source/Symbol/CompilerType.cpp b/lldb/source/Symbol/CompilerType.cpp
index 62c0ddf51c012..73da3127a98a3 100644
--- a/lldb/source/Symbol/CompilerType.cpp
+++ b/lldb/source/Symbol/CompilerType.cpp
@@ -793,10 +793,10 @@ CompilerType::GetTypeBitAlign(ExecutionContextScope *exe_scope) const {
   return {};
 }
 
-lldb::Encoding CompilerType::GetEncoding(uint64_t &count) const {
+lldb::Encoding CompilerType::GetEncoding() const {
   if (IsValid())
     if (auto type_system_sp = GetTypeSystem())
-      return type_system_sp->GetEncoding(m_type, count);
+      return type_system_sp->GetEncoding(m_type);
   return lldb::eEncodingInvalid;
 }
 
@@ -1093,10 +1093,10 @@ bool CompilerType::GetValueAsScalar(const lldb_private::DataExtractor &data,
   if (IsAggregateType()) {
     return false; // Aggregate types don't have scalar values
   } else {
-    uint64_t count = 0;
-    lldb::Encoding encoding = GetEncoding(count);
+    // FIXME: check that type is scalar instead of checking encoding?
+    lldb::Encoding encoding = GetEncoding();
 
-    if (encoding == lldb::eEncodingInvalid || count != 1)
+    if (encoding == lldb::eEncodingInvalid || (GetTypeInfo() & eTypeIsComplex))
       return false;
 
     auto byte_size_or_err = GetByteSize(exe_scope);
diff --git a/lldb/source/Symbol/Type.cpp b/lldb/source/Symbol/Type.cpp
index 952b2bdee1886..0c3246d238701 100644
--- a/lldb/source/Symbol/Type.cpp
+++ b/lldb/source/Symbol/Type.cpp
@@ -531,9 +531,9 @@ lldb::TypeSP Type::GetTypedefType() {
 
 lldb::Format Type::GetFormat() { return GetForwardCompilerType().GetFormat(); }
 
-lldb::Encoding Type::GetEncoding(uint64_t &count) {
+lldb::Encoding Type::GetEncoding() {
   // Make sure we resolve our type if it already hasn't been.
-  return GetForwardCompilerType().GetEncoding(count);
+  return GetForwardCompilerType().GetEncoding();
 }
 
 bool Type::ReadFromMemory(ExecutionContext *exe_ctx, lldb::addr_t addr,
diff --git a/lldb/source/ValueObject/ValueObject.cpp b/lldb/source/ValueObject/ValueObject.cpp
index 38b9f77e6ddda..aeea32f19ee2c 100644
--- a/lldb/source/ValueObject/ValueObject.cpp
+++ b/lldb/source/ValueObject/ValueObject.cpp
@@ -790,8 +790,7 @@ bool ValueObject::SetData(DataExtractor &data, Status &error) {
     return false;
   }
 
-  uint64_t count = 0;
-  const Encoding encoding = GetCompilerType().GetEncoding(count);
+  const Encoding encoding = GetCompilerType().GetEncoding();
 
   const size_t byte_size = llvm::expectedToOptional(GetByteSize()).value_or(0);
 
@@ -1669,8 +1668,7 @@ bool ValueObject::SetValueFromCString(const char *value_str, Status &error) {
     return false;
   }
 
-  uint64_t count = 0;
-  const Encoding encoding = GetCompilerType().GetEncoding(count);
+  const Encoding encoding = GetCompilerType().GetEncoding();
 
   const size_t byte_size = llvm::expectedToOptional(GetByteSize()).value_or(0);
 

Michael137 added a commit to Michael137/llvm-project that referenced this pull request Oct 30, 2025
…PointType

Similar motivation to llvm#165702.
It was unused in all callsites and inconsistent with other APIs like
`IsIntegerType` (which doesn't take a `count` parameter).

If we ever need a "how many elements does this type represent", we can implement one with a new TypeSystem API that does exactly that.
Copy link
Member

@bulbazord bulbazord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. It looks like this was added in anticipation of its usefulness rather than with purpose, but I didn't check that assumption.

@Michael137 Michael137 merged commit a6eac9e into llvm:main Oct 31, 2025
12 checks passed
@Michael137 Michael137 deleted the lldb/type-encoding-count branch October 31, 2025 09:08
Michael137 added a commit that referenced this pull request Oct 31, 2025
…PointType (#165707)

Similar motivation to #165702.
It was unused in all callsites and inconsistent with other APIs like
`IsIntegerType` (which doesn't take a `count` parameter).

If we ever need a "how many elements does this type represent", we can
implement one with a new TypeSystem API that does exactly that.

Some callsites checked for `count == 1` previously, but I suspect what
they intended to do is check for whether it's a vector type or complex
type, before reading the FP register. I'm somewhat confident that's the
case because the `TypeSystemClang::GetTypeInfo` currently incorrectly
sets the integer and floating point bits for complex and vector types
(will fix separately). But some architectures might choose to pass
single-element vectors in scalar registers. I should probably changes
these to check the vector element size.

All the `count == 2 && is_complex` were redundant because `count == 2`
iff `is_complex == true`. So I just removed the count check there.
llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request Oct 31, 2025
…:IsFloatingPointType (#165707)

Similar motivation to llvm/llvm-project#165702.
It was unused in all callsites and inconsistent with other APIs like
`IsIntegerType` (which doesn't take a `count` parameter).

If we ever need a "how many elements does this type represent", we can
implement one with a new TypeSystem API that does exactly that.

Some callsites checked for `count == 1` previously, but I suspect what
they intended to do is check for whether it's a vector type or complex
type, before reading the FP register. I'm somewhat confident that's the
case because the `TypeSystemClang::GetTypeInfo` currently incorrectly
sets the integer and floating point bits for complex and vector types
(will fix separately). But some architectures might choose to pass
single-element vectors in scalar registers. I should probably changes
these to check the vector element size.

All the `count == 2 && is_complex` were redundant because `count == 2`
iff `is_complex == true`. So I just removed the count check there.
DEBADRIBASAK pushed a commit to DEBADRIBASAK/llvm-project that referenced this pull request Nov 3, 2025
llvm#165702)

There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
count `1` but complex types would be `2`. Hence, it wasn't clear what
count was referring to.
2. `count` was not being set if the input type was invalid, possibly
leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.
DEBADRIBASAK pushed a commit to DEBADRIBASAK/llvm-project that referenced this pull request Nov 3, 2025
…PointType (llvm#165707)

Similar motivation to llvm#165702.
It was unused in all callsites and inconsistent with other APIs like
`IsIntegerType` (which doesn't take a `count` parameter).

If we ever need a "how many elements does this type represent", we can
implement one with a new TypeSystem API that does exactly that.

Some callsites checked for `count == 1` previously, but I suspect what
they intended to do is check for whether it's a vector type or complex
type, before reading the FP register. I'm somewhat confident that's the
case because the `TypeSystemClang::GetTypeInfo` currently incorrectly
sets the integer and floating point bits for complex and vector types
(will fix separately). But some architectures might choose to pass
single-element vectors in scalar registers. I should probably changes
these to check the vector element size.

All the `count == 2 && is_complex` were redundant because `count == 2`
iff `is_complex == true`. So I just removed the count check there.
Michael137 added a commit to swiftlang/llvm-project that referenced this pull request Nov 4, 2025
llvm#165702)

There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
count `1` but complex types would be `2`. Hence, it wasn't clear what
count was referring to.
2. `count` was not being set if the input type was invalid, possibly
leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.

(cherry picked from commit a6eac9e)
Michael137 added a commit to swiftlang/llvm-project that referenced this pull request Nov 4, 2025
Michael137 added a commit to swiftlang/llvm-project that referenced this pull request Nov 5, 2025
llvm#165702)

There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
count `1` but complex types would be `2`. Hence, it wasn't clear what
count was referring to.
2. `count` was not being set if the input type was invalid, possibly
leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.

(cherry picked from commit a6eac9e)
Michael137 added a commit to swiftlang/llvm-project that referenced this pull request Nov 5, 2025
llvm#165702)

There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
count `1` but complex types would be `2`. Hence, it wasn't clear what
count was referring to.
2. `count` was not being set if the input type was invalid, possibly
leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.

(cherry picked from commit a6eac9e)
Michael137 added a commit to swiftlang/llvm-project that referenced this pull request Nov 5, 2025
Michael137 added a commit to swiftlang/llvm-project that referenced this pull request Nov 5, 2025
…PointType (llvm#165707)

Similar motivation to llvm#165702.
It was unused in all callsites and inconsistent with other APIs like
`IsIntegerType` (which doesn't take a `count` parameter).

If we ever need a "how many elements does this type represent", we can
implement one with a new TypeSystem API that does exactly that.

Some callsites checked for `count == 1` previously, but I suspect what
they intended to do is check for whether it's a vector type or complex
type, before reading the FP register. I'm somewhat confident that's the
case because the `TypeSystemClang::GetTypeInfo` currently incorrectly
sets the integer and floating point bits for complex and vector types
(will fix separately). But some architectures might choose to pass
single-element vectors in scalar registers. I should probably changes
these to check the vector element size.

All the `count == 2 && is_complex` were redundant because `count == 2`
iff `is_complex == true`. So I just removed the count check there.

(cherry picked from commit b81a992)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants