"Robin Dapp" <[email protected]> writes:
> As Jeff wrote, we have groups of "1", 2, 4, 8, with nregs = 1, 2, 4, 8.
> So the
> widest destination has 8 regs.
>
> For a widening/zext insn from 2 to 8 (extend 4x), the allowed overlap would
> be
> in the last 2 regnos, analogous in the last 4 for "4 to 8" or in the
> last regno
> for "1 to 8".
>
> If the source is a group of 2 and the destination is a group of 8 the
> following
> would be illegal
> vzext.vf4 v0,v0 # destination is v0,v1,v2,v3,v4,v5,v6,v7
> but this would be OK:
> vzext.vf4 v0,v6
>
> The opposite applies to narrowing, "2 to 8" allows overlap only in the first
> 2
> regnos, etc.
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?
If the regnos are not always aligned then I think my question:
> > If nregs can be more than 1 in:
> >
> > [...]
> >
> > then it looks like the regno + nregs - 1 == wide_regno is OK.
> > Is that how it works? Or is nregs always 1 in practice?
still stands.
> However, there's another issue with our scatter instruction. The spec
> prohibits reading the same register with different element size, so we'd
> need a
> constraint on one source dependent on the other, forcing them to be unequal.
> This is PR113695 and not about the destination, i.e. not compatible with an
> earlyclobber. Basically a "never-matching" constraint? :)
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.
> Oh, I forgot to say that it _is_ possible to implement at least the
> destination/source part of the problem with register filters and we
> even tried that before. The patterns get increasingly unwieldy,
> though, with a mix of earlyclobbers, disabled attributes, and
> duplicate constraints. I don't recall all details but it worked
> reasonably well. At least for understanding/comprehension of an insn
> pattern, a dependent filter is much clearer, though.
Yeah, I agree that multiple alternatives doesn't scale beyond the
double-register case.
Again, still playing devil's advocate rather than objecting.
Thanks,
Richard
