[PATCH] D94964: Describe vector layout in LangRef

[Markus Lavin via Phabricator via llvm-commits]

markus created this revision.
markus added reviewers: uweigand, efriedma, dmgreen, bjope.
Herald added a subscriber: jdoerfert.
markus requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

As far as I can tell layout of IR vectors (especially those with sub-byte sized elements) have not been described in the documentation. This patch tries to address that using material from the comments in https://reviews.llvm.org/D42100#992315 where the decision appears to have been taken.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94964

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -3151,6 +3151,31 @@
 vector length is unknown at compile time. Vector types are considered
 :ref:`first class <t_firstclass>`.
 
+:Memory Layout:
+
+In general vector elements are laid out in memory in the same way as
+:ref:`array types <t_array>`. That is vector element ``N`` resides at an
+address that is lower than or equal to (in case of sub-byte sized elements)
+that of vector element ``N+1``.
+
+For vectors with sub-byte sized elements these rules are extended in the spirit
+of the rules governing bit field layout in the C language. Consider
+
+::
+
+  struct { char b0 : 1; char b1 : 1; ... char b15 : 1 }
+
+In C the platform ABI defines where to find the bits ``b0 .. b15``. On (most)
+little-endian machines, ``b0`` is placed in the least-significant bit of the
+word in memory, while on (most) big-endian machines, ``b0`` is placed in the
+most-significant bit.
+
+Extrapolating this to vector types means that, on a little-endian machine, the
+first element of a ``<16 x i1>`` is found in the least-significant bit of the
+corresponding ``i16`` (i.e. the byte with lowest address) and on a big-endian
+machine the first element of the vector would be found in the most-significant
+bit of the corresponding ``i16`` (again the byte with the lowest address).
+
 :Syntax:
 
 ::


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D94964.317529.patch
Type: text/x-patch
Size: 1445 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210119/52735318/attachment.bin>