[llvm] [DataLayout] Use member initialization (NFC) (PR #103712)

[Sergei Barannikov via llvm-commits]

================
@@ -198,37 +198,38 @@ const char *DataLayout::getManglingComponent(const Triple &T) {
   return "-m:e";
 }
 
-static const std::pair<AlignTypeEnum, LayoutAlignElem> DefaultAlignments[] = {
-    {INTEGER_ALIGN, {1, Align(1), Align(1)}},    // i1
-    {INTEGER_ALIGN, {8, Align(1), Align(1)}},    // i8
-    {INTEGER_ALIGN, {16, Align(2), Align(2)}},   // i16
-    {INTEGER_ALIGN, {32, Align(4), Align(4)}},   // i32
-    {INTEGER_ALIGN, {64, Align(4), Align(8)}},   // i64
-    {FLOAT_ALIGN, {16, Align(2), Align(2)}},     // half, bfloat
-    {FLOAT_ALIGN, {32, Align(4), Align(4)}},     // float
-    {FLOAT_ALIGN, {64, Align(8), Align(8)}},     // double
-    {FLOAT_ALIGN, {128, Align(16), Align(16)}},  // ppcf128, quad, ...
-    {VECTOR_ALIGN, {64, Align(8), Align(8)}},    // v2i32, v1i64, ...
-    {VECTOR_ALIGN, {128, Align(16), Align(16)}}, // v16i8, v8i16, v4i32, ...
+// Default primitive type specifications.
+// NOTE: These arrays must be sorted by type bit width.
+constexpr LayoutAlignElem DataLayout::DefaultIntSpecs[] = {
+    {1, Align::Constant<1>(), Align::Constant<1>()},  // i1:8:8
+    {8, Align::Constant<1>(), Align::Constant<1>()},  // i8:8:8
+    {16, Align::Constant<2>(), Align::Constant<2>()}, // i16:16:16
+    {32, Align::Constant<4>(), Align::Constant<4>()}, // i32:32:32
+    {64, Align::Constant<4>(), Align::Constant<8>()}, // i64:32:64
+};
+constexpr LayoutAlignElem DataLayout::DefaultFloatSpecs[] = {
+    {16, Align::Constant<2>(), Align::Constant<2>()},    // f16:16:16
----------------
s-barannikov wrote:

The end goal is indeed to simplify life for non-8-bit targets.
I'd like to do some NFC refactoring and improve test coverage before posting an RFC patch that adds the support.
I'm very sorry for the conflicts.

> the alignments weren't specified in bits before this patch either.

Yep, this patch didn't change that.

> Should there perhaps be a comment somewhere saying that the alignments are specified in "number of octests"? And why is that better than specifying them in bits?

Storing alignments in bits in one possible solution (and in fact I'm doing this downstream, too). It might look attractive, but it has some downsides. Let's discuss this in the discourse thread.


https://github.com/llvm/llvm-project/pull/103712