On 6/6/25 11:58 AM, Robin Dapp wrote:
Note it’s far from obvious to me whether for stride and gather loads
the alignment of the elements loaded falls under the scalar or vector
load restriction. Is this explicitly spelled out for risc-v or is
that your interpretation?
We have the followin
Note it’s far from obvious to me whether for stride and gather loads the
alignment of the elements loaded falls under the scalar or vector load
restriction. Is this explicitly spelled out for risc-v or is that your
interpretation?
We have the following in the vector spec:
If an element acces
> Am 06.06.2025 um 17:42 schrieb Robin Dapp :
>
>
>>
>> At first I thought if we only cared about element misalignment checking the
>> first element/pointer should be sufficient. But riscv's gathers as well as
>> strided loads allow byte offsets rather than element-sized offsets so there
At first I thought if we only cared about element misalignment checking the
first element/pointer should be sufficient. But riscv's gathers as well as
strided loads allow byte offsets rather than element-sized offsets so there
could be 16-bit loads with a stride of e.g. 1 byte.
Wait, no that
At least on aarch64, the gathers and scatters use (mem:BLK (scratch:P)),
i.e. a wildcard memory access. There's no good way in RTL to represent
multiplie distinct locations in a single reference.
(unspec on its own doesn't imply a memory access)
At first I thought if we only cared about elemen
Richard Biener writes:
> On Fri, Jun 6, 2025 at 1:26 PM Robin Dapp wrote:
>>
>> > In case the riscv strided vector load instruction has additional
>> > requirements
>> > on the loaded (scalar) element alignment then we'd have to implement this.
>> > For the moment the vectorizer will really emit
I think the spotted correctness issues wrt alignment/aliasing should be
addressed up-front. In the end the gather/stride-load is probably an
UNSPEC, so there's no MEM RTX with wrong info? How would we
query the target on whether it can handle the alignment here? Usually
we go through vect_suppo
Yes. Note I don't see we guarantee element alignment for gather/scatter
either, nor do the IFNs seem to have encoding space for alignment. The
effective type for TBAA seems also missing there ...
Regarding vector_vector_composition_type I had a try and attached a preliminary
V3. I'm not reall
On Fri, Jun 6, 2025 at 1:26 PM Robin Dapp wrote:
>
> > In case the riscv strided vector load instruction has additional
> > requirements
> > on the loaded (scalar) element alignment then we'd have to implement this.
> > For the moment the vectorizer will really emit scalar loads here, so that's
>
In case the riscv strided vector load instruction has additional requirements
on the loaded (scalar) element alignment then we'd have to implement this.
For the moment the vectorizer will really emit scalar loads here, so that's
fine (though eventually inefficient). For the strided vector load th
On Thu, Jun 5, 2025 at 4:44 PM Robin Dapp wrote:
>
> >> But that would not pass the alignment check either, no? In fact, I assume
> >> that for strided loads we have a scalar type as component (ptype), so we
> >> always get supported unaligned accesses here?
>
> > Perhaps I'm missing something, t
But that would not pass the alignment check either, no? In fact, I assume
that for strided loads we have a scalar type as component (ptype), so we
always get supported unaligned accesses here?
Perhaps I'm missing something, though.
What I was missing is that we're using the same element size
But that would not pass the alignment check either, no? In fact, I assume
that for strided loads we have a scalar type as component (ptype), so we
always get supported unaligned accesses here?
I was thinking of the case where we have e.g. a group of 4 int8s and use a
strided load with int32 el
So I do wonder how this interacts with vector_vector_composition_type,
in fact the difference is that for strided_load we know the composition
happens as part of a load, so how about instead extending
this function, pass it VLS_LOAD/STORE and also consider
strided_loads as composition kind there?
On Thu, Jun 5, 2025 at 2:34 PM Robin Dapp wrote:
>
> > So I do wonder how this interacts with vector_vector_composition_type,
> > in fact the difference is that for strided_load we know the composition
> > happens as part of a load, so how about instead extending
> > this function, pass it VLS_LOA
On Tue, May 27, 2025 at 6:04 PM Robin Dapp wrote:
>
> From: Robin Dapp
>
> This patch enables strided loads for VMAT_STRIDED_SLP. Instead of
> building vectors from scalars or other vectors we can use strided loads
> directly when applicable.
>
> The current implementation limits strided loads t
From: Robin Dapp
This patch enables strided loads for VMAT_STRIDED_SLP. Instead of
building vectors from scalars or other vectors we can use strided loads
directly when applicable.
The current implementation limits strided loads to cases where we can
load entire groups and not subsets of them.
17 matches
Mail list logo
