[PATCH] D112463: [LangRef][NFC] Remove incorrect vector alignment rules

Fraser Cormack via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 25 09:09:48 PDT 2021


frasercrmck created this revision.
frasercrmck added reviewers: efriedma, nikic, woodruffw, craig.topper, aeubanks, fhahn, dblaikie.
Herald added a subscriber: jdoerfert.
frasercrmck requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

The LangRef incorrectly says that if no exact match is found when
seeking alignment for a vector type, the largest vector type smaller
than the sought-after vector type. This is incorrect as vector types
require an exact match, else they fall back to reporting the natural
alignment.

The corrected rule was not added in its place, as rules for other types
(e.g., floating-point types) aren't documented.

A unit test was added to demonstrate this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112463

Files:
  llvm/docs/LangRef.rst
  llvm/unittests/IR/DataLayoutTest.cpp


Index: llvm/unittests/IR/DataLayoutTest.cpp
===================================================================
--- llvm/unittests/IR/DataLayoutTest.cpp
+++ llvm/unittests/IR/DataLayoutTest.cpp
@@ -11,6 +11,7 @@
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IR/Type.h"
+#include "llvm/Testing/Support/Error.h"
 #include "gtest/gtest.h"
 
 using namespace llvm;
@@ -89,4 +90,20 @@
   EXPECT_EQ(ExplicitGlobal2->getAddressSpace(), 123u);
 }
 
+TEST(DataLayoutTest, VectorAlign) {
+  auto DL = DataLayout::parse("v128:128");
+  EXPECT_THAT_ERROR(DL.takeError(), Succeeded());
+
+  LLVMContext Context;
+  Type *const DoubleTy = Type::getDoubleTy(Context);
+  Type *const V128F64Ty = FixedVectorType::get(DoubleTy, 128);
+
+  // The alignment for a vector type larger than any specified vector type uses
+  // the natual alignment as a fallback. This is contrary to old LangRef
+  // documentation which claimed it would use the largest vector type smaller
+  // than the one sought after. In this case, it would have been Align(16).
+  EXPECT_EQ(Align(128 * 8), DL->getABITypeAlign(V128F64Ty));
+  EXPECT_EQ(Align(128 * 8), DL->getPrefTypeAlign(V128F64Ty));
+}
+
 } // anonymous namespace
Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2679,10 +2679,6 @@
    given the default specifications above, the i7 type will use the
    alignment of i8 (next largest) while both i65 and i256 will use the
    alignment of i64 (largest specified).
-#. If no match is found, and the type sought is a vector type, then the
-   largest vector type that is smaller than the sought vector type will
-   be used as a fall back. This happens because <128 x double> can be
-   implemented in terms of 64 <2 x double>, for example.
 
 The function of the data layout string may not be what you expect.
 Notably, this is not a specification from the frontend of what alignment


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D112463.382020.patch
Type: text/x-patch
Size: 1993 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211025/cd2a9934/attachment.bin>


More information about the llvm-commits mailing list