================
@@ -3173,41 +3174,46 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
     return T->getTypeClass() == ConstantArray ||
            T->getTypeClass() == VariableArray ||
            T->getTypeClass() == IncompleteArray ||
-           T->getTypeClass() == DependentSizedArray;
+           T->getTypeClass() == DependentSizedArray ||
+           T->getTypeClass() == ArrayParameter;
   }
 };
 
 /// Represents the canonical version of C arrays with a specified constant 
size.
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
-class ConstantArrayType final
-    : public ArrayType,
-      private llvm::TrailingObjects<ConstantArrayType, const Expr *> {
----------------
zygoloid wrote:

The size expression is usually not part of a constant array type. Normally, all 
we want as part of the type node is the bound, and the size expression if 
needed can be found on the `ArrayTypeLoc`. The rare special case being handled 
here is that if the array bound is instantiation-dependent but not dependent, 
then we need to preserve the expression in the type (not just in the `TypeLoc`) 
because it affects (for example) whether two template declarations involving 
such a type are considered to declare the same template. Because this is a very 
rare case, and `ConstantArrayType`s can be relatively common (eg, as the types 
of string literals), it seemed preferable to not store the `Expr*` if it's not 
needed, but in absolute terms it's probably a minor difference in memory usage, 
so it's probably fine to remove this optimization.

If we want to keep the optimization, perhaps we could replace the `Size` and 
`SizeExpr` fields with a pointer union that can hold either a <= 63-bit array 
bound (the common case) or a pointer to a slab-allocated pair of `APInt` and 
`const Expr*` (in the case where the bound doesn't fit in 63 bits or the size 
expression is instantiation-dependent).

https://github.com/llvm/llvm-project/pull/79382
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to