> The examples seem to suggest that the first regno in a group is always > divisible by the size. Is that a requirement? Or would: > > vzext.vf4 v0,v7 > > and: > > vzext.vf4 v8,v1 > > be valid as well? > > If the regnos are always aligned then... > >> The source = destination part we currently handle by an earlyclobber, and >> for >> just halves a "half/lowpart early-clobber" might indeed work. For the more >> advanced cases, we'd additionally need something like "7/8, 6/8 = 3/4, 4/8 = >> 1/2" early-clobbers. For narrowing, 1/8, 1/4, 1/2, unless I'm forgetting >> something. Here it's always about source and destination. > > ...I suppose the widening case could be classified as "earlyclobber > except for matching end regnos". Having direct support for that and > "earlyclobber except for matching start regnos" sounds useful. It would > make my example from yesterday easier to write as well, and would express > the intent directly to the RA.
> Could you describe the narrowing restrictions in more detail? Yes, the modes are always aligned (regno % size == 0) and I agree with your earlyclobber characterization. Narrowing is: "The destination element size is smaller than the source element size and the overlap is in the lowest-numbered part of the source register group" = "earlyclobber except for matching start regnos" Widening is: "The destination element size is greater than the source element size, the source group size is at least 1, and the overlap is in the highest-numbered part of the destination register group " = "earlyclobber except for matching end regnos" The size of the match would be determined by the smaller group size. > Hmm, ok. In a way that does feel very like an earlyclobber as well. > Perhaps we could say that an earlyclobber on an input is allowed and > introduces a conflict with other input operands, but not with the output > operands. (A conflict with an output operand should involve an > earlyclobber there, in the usual way.) Of course, the C++ condition > should still prevent matching (inner) registers, since it seems too much > to expect the RA to introduce temporaries. > > Isn't there a risk that these two requirements (widening/narrowing and > non-overlapping inputs) will end up being combined in a single instruction > in future, either for RVV or for some other architecture? Defining the > restriction in terms of a single other operand wouldn't scale to a > three-way restriction, but using earlyclobbers would. I was thinking of "scaling" dependent filters right away, i.e. allowing a list of dependent opnos and passing the current operands[] to the backend. I wouldn't dare though :) Initially, before starting the implementation, my assumption was that adjusting or adding early-clobber semantics would likely not be well received and that's why I went the fully-generic route. If new earlyclobbers kinds are acceptable, maybe that would be a less invasive way? -- Regards Robin
