> > Like aarch64 we set REGMODE_NATURAL_SIZE for fixed-size modes to > > UNITS_PER_WORD. Isn't that part of the problem? > > > > In extract_bit_field_as_subreg we check lowpart_bit_field_p (= true because > > 128 is a multiple of UNITS_PER_WORD). This leads to the subreg expression. > > > > If I have REGMODE_NATURAL_SIZE return a VLA number this fails and we extract > > via memory - but that of course breaks almost everything else :) > > > > When you say the target-independent code should already have all > > information it > > needs, what are you referring to? Something else than REGMODE_NATURAL_SIZE? > > In the aarch64 example I mentioned, the REGMODE_NATURAL_SIZE of the inner > mode is variable. (The REGMODE_NATURAL_SIZE of the outer mode is constant, > but it's the inner mode that matters here.)
Yes, because in that example the inner mode is a VLA mode. I meant, for the riscv case, wouldn't we need to make the REGMODE_NATURAL_SIZE of the VLS mode variable as well? (As that is what it is actually going to be in the end, some kind of vector move of a variable-sized vector) Right now we onlye enable VLS modes whose size is not larger than the base variable vector size (e.g. [128 128] bits) exactly to avoid the kind of ambiguity between modes that arises here. -- Regards Robin
