[Libre-soc-org] [Bug 1005] write and submit grant request to nlnet for beginning adding compiler support for libre-soc

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1005

--- Comment #5 from Jacob Lifshay <programmerjake at gmail.com> ---
I think we should choose the following sizes and alignments for our vector
types:

this assumes all non-mask element types have a size that is a power of two

all non-mask types:
sizeof(Elt _SVP64_vec(MAXVL, SUBVL)) = sizeof(Elt) * MAXVL * SUBVL
-- so the same size as the corresponding array with no padding
alignof(Elt _SVP64_vec(MAXVL, SUBVL)) = gcd(
    sizeof(Elt) * MAXVL * SUBVL,
    next_power_of_two(sizeof(Elt) * MAXVL * SUBVL),
    ALIGN_LIMIT)

where ALIGN_LIMIT is some global constant >= alignof(Elt) for all non-mask
element types we'll ever support (so imho 16 is probably good because then you
can use malloc for vectors instead of some alloc_aligned function, though we
could go bigger to match expected average cache line size -- it can't depend on
the target cpu though since that makes libraries a pain. this should be <=
largest alignment supported by linker/loader)

this choice of size/align for non-mask types gives two nice properties:
* vector types never have padding, so we can type-pun an appropriately aligned
section of any arbitrary array into a vector type and it will work properly.

(if vector types were more aligned than this, writing a vector type to that
array could fill array trailing elements with the vector's padding which
compilers treat as `undef` -- prohibited in Rust unless the original array uses
MaybeUninit)

* vector types are always sufficiently aligned that type-punning vector types
works correctly with some reasonable assumptions. (described at end)

mask types:
llvm likes i1 x N vectors to be as small as possible, which can cause problems,
so imho:
just make it easy and define all mask vector types with MAXVL <= 64 to be
uint64_t underneath, so:
sizeof(maskx(MAXVL)) = 8
alignof(maskx(MAXVL)) = 8
this means when generating llvm ir we will need to convert to i64 before
storing/loading to/from memory (this doesn't include spills/fills since llvm
handles that invisibly to the programmer)

vector type to vector type punning details:
well, conveniently every type combination that is valid to type pun (so doesn't
try to e.g. type pun `i32x3` to `i64x2` where the last `i64` is half `undef`)
already satisfies the alignment requirements if we decide the alignment is
`gcd(sizeof(element) * length, next_power_of_2(sizeof(element) * length),
some_global_constant_limit)` (compatible with what i proposed for
portable-simd) because:
* assuming `some_global_constant_limit >= sizeof(element)` for all possible
element types (handles wanting vector alignment to not increase without bound)
* assuming element types are power-of-2 sized which afaict is true for SVP64
* assuming `sizeof(target_element) * target_length <= sizeof(source_element) *
source_length` aka. that the type pun is valid because the target vector's
elements are completely within the source elements and not taking bytes from
after the end of the source elements
* every type pun where `sizeof(target_element) <= sizeof(source_element)` the
alignment works out so the target vector type needs the same or less alignment
than the source (always the same alignment if `sizeof(target_element) *
target_length == sizeof(source_element) * source_length`)
* every type pun where `sizeof(target_element) > sizeof(source_element)` the
assumption that the type pun is valid means that the source vector's length is
a multiple of `sizeof(target_element) / sizeof(source_element)` which is a
power of two therefore the alignment again works out so the target vector type
needs the same or less alignment than the source (always the same alignment if
`sizeof(target_element) * target_length == sizeof(source_element) *
source_length`)

As part of Rust's project portable-simd I recommended basically the same
size/align scheme for non-mask vectors to both portable-simd and RISC-V:
https://github.com/rust-lang/portable-simd/issues/319#issuecomment-1334515524
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/347#issuecomment-1442584902

-- 
You are receiving this mail because:
You are on the CC list for the bug.