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

[Fraser Cormack via Phabricator via llvm-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8002fa67603b: [LangRef] Remove incorrect vector alignment rules (authored by frasercrmck).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112463/new/

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,18 @@
   EXPECT_EQ(ExplicitGlobal2->getAddressSpace(), 123u);
 }
 
+TEST(DataLayoutTest, VectorAlign) {
+  Expected<DataLayout> DL = DataLayout::parse("v64:64");
+  EXPECT_THAT_EXPECTED(DL, Succeeded());
+
+  LLVMContext Context;
+  Type *const FloatTy = Type::getFloatTy(Context);
+  Type *const V8F32Ty = FixedVectorType::get(FloatTy, 8);
+
+  // The alignment for a vector type larger than any specified vector type uses
+  // the natural alignment as a fallback.
+  EXPECT_EQ(Align(4 * 8), DL->getABITypeAlign(V8F32Ty));
+  EXPECT_EQ(Align(4 * 8), DL->getPrefTypeAlign(V8F32Ty));
+}
+
 } // anonymous namespace
Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2680,10 +2680,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.394239.patch
Type: text/x-patch
Size: 1796 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211214/c4ddd596/attachment.bin>