> 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
