On Tue, Sep 27, 2022 at 3:59 PM Robin Dapp wrote:
>
> > Yes, because the native_interpret always starts at offset zero
> > (we can't easily feed in a "shifted" RHS). So what I assumed is
> > that IFN_LEN_STORE always stores elements [0, len + adj].
>
> Hmm, but this assumption is not violated her
> Yes, because the native_interpret always starts at offset zero
> (we can't easily feed in a "shifted" RHS). So what I assumed is
> that IFN_LEN_STORE always stores elements [0, len + adj].
Hmm, but this assumption is not violated here or am I missing something?
It's not like we're storing [vec
On Tue, Sep 27, 2022 at 3:19 PM Robin Dapp wrote:
>
> > The error is probably in vn_reference_lookup_3 which assumes that
> > 'len' applies to the vector elements in element order. See the part
> > of the code where it checks for internal_store_fn_p. If 'len' is with
> > respect to the memory an
> The error is probably in vn_reference_lookup_3 which assumes that
> 'len' applies to the vector elements in element order. See the part
> of the code where it checks for internal_store_fn_p. If 'len' is with
> respect to the memory and thus endianess has to be taken into
> account then for the
On Mon, Sep 26, 2022 at 4:21 PM Robin Dapp wrote:
>
> Hi,
>
> I'm locally testing a branch that enables vll/vstl for partial vector
> usage i.e. len_load and len_store on s390. I see a FAIL in
> testsuite/gfortran.dg/power_3.f90.
> Since r13-1777-gbd9837bc3ca134 we also performe VN for masked/len
Hi,
I'm locally testing a branch that enables vll/vstl for partial vector
usage i.e. len_load and len_store on s390. I see a FAIL in
testsuite/gfortran.dg/power_3.f90.
Since r13-1777-gbd9837bc3ca134 we also performe VN for masked/len stores
and things go wrong there. The problem seems to be that
