[PATCH] D112531: [RFC][DataLayout] Allow vector specifications by element size

Fraser Cormack via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 26 06:13:19 PDT 2021


frasercrmck created this revision.
frasercrmck added reviewers: nikic, woodruffw, efriedma, craig.topper, aeubanks, fhahn, dblaikie, jdoerfert.
Herald added subscribers: dexonsmith, luismarques, pengfei, s.egerton, PkmX, simoncook, hiraditya.
frasercrmck requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This patch adds the ability to configure the DataLayout specifications
on vector types by their element size, rather than their total size.

Specifying alignments by total vector size is not a good fit for some
architectures -- such as RISC-V's V extension (RVV) -- for a couple of
reasons.

The first is that for many architectures, such as those with
"Cray-style" vectors, there are a very wide set of supported vector
types, and specifying each by their total size is infeasible. RVV, for
example, could theoretically support any `i8` vector type between 1 and
8192 bytes in size. Specifying optimal alignments for all such vector
types is cumbersome.

The second is that several architectures (again, like RVV) specify
vector alignment according to their element size. Thus under the current
system it is necessary either to pessimize vector alignments by rounding
them up to that of the maximum alignment across all legal vectors of
that size and/or to handle them as "misaligned" accesses.

Instead, this patch aims to both better suit and simplify the
specifications for such architectures. The ability to specify vector
alignments by element size is provided through a new specifier: `ve`. To
avoid any ambiguity about how this interacts with the existing `v`
vector specifier, the two are *mutually exclusive*; it is an error to
manually specify both in a single data layout. Since there are two `v`
specifiers in the set of defaults, an explicitly-set `ve` specifier must
be careful to erase those defaults. This decision also helps to preserve
backwards compatibility with older data layouts.

One outstanding design issue concerns how this should play with the
`x86_mmx` type, as that (AFAIK) doesn't have an element type.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112531

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/DataLayout.h
  llvm/lib/IR/DataLayout.cpp
  llvm/unittests/IR/DataLayoutTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D112531.382282.patch
Type: text/x-patch
Size: 9468 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211026/1504ccd2/attachment.bin>


More information about the llvm-commits mailing list