Hi Robin,
Thanks for your comment. I think your point is correct, especially the part
about SEWmin.
I will revise this patch again.

On Wed, Feb 5, 2025 at 4:18 PM Robin Dapp <rdapp....@gmail.com> wrote:

> > Hi Robin,
> > Sorry, I should have simplified the problem by presenting it in terms of
> > Zve32x, because Zve32f implies Zve32x.
> > As the specification states, the requirement is to support LMUL ≥
> SEW/ELEN.
> > Regarding the implementation,
>
> But the spec requirement mentions SEW_min not SEW?
>
> "In general, the requirement is to support LMUL ≥ SEWMIN/ELEN, where
> SEWMIN is
> the narrowest supported SEW value and ELEN is the widest supported SEW
> value"
>
> Further it states:
> "For standard vector extensions with ELEN=32, fractional LMULs of 1/2 and
> 1/4
> must be supported."
>
> > I followed this rule to fix the problem.
> > In this link: https://godbolt.org/z/j59oTW371, there is a vsetivli
> > zero,2,e32,mf2,ta,ma.
> > Here, SEW=32, and Zve32x has ELEN=32, which makes LMUL=1/2 illegal.
> >
> > According to the rule LMUL ≥ SEW/ELEN => LMUL ≥ 32 / 32 => LMUL ≥  1.
>
> As you're specifying VLEN=128 (with zvl128b) we enable the respective
> modes,
> i.e. V2SI and V4SI.  With VLEN=32 those wouldn't be available.
> RVVMF2SI already has the requirement TARGET_MIN_VLEN > 32 so wouldn't be
> chosen
> either.
>
> If LMUL <= 1 were illegal for all zve32 we couldn't vectorize anything that
> doesn't fit a full vector?  That can't be correct and would severely limit
> us.
>
> I think the only necessary change is to make sure we're not emitting
> LMUL = 1/8 for ELEN=32/zve32.  That should be a far less invasive change.
>
> >> In particular, how would the same LMUL for AVL=2 and AVL=4 and the same
> data
> >> type be correct?
> >
> > That's right. The case just allocates more space, but storing 2 and 4
> > elements remains the same.
>
> Even if a V2SI with LMUL=1 on VLEN=128 doesn't lead to a SIGILL right away
> it would surely modify the overlap constraints and such.  To me that
> doesn't
> look right.
>
> --
> Regards
>  Robin
>
>

Reply via email to