Hi, Richard. Here is an example for vsext.vf2.
The general pattern for this instruction as follows: (set (operand 0) (unspec:...(operand 1))) We have a TARGET_MIN_VLEN macro which specify minimum VLEN according to -march Consider this case V16QI -> V16HI of vsext.vf2 When TARGET_MIN_VLEN == 128 The constraint for vsext.vf should be: (set (operand 0: V16HI "=vr,&vr") (unspec:...(operand 1: V16QI "register filter1, vr"))) Wheras when TARGET_MIN_VLEN > 128, We are expecting the constraint: (set (operand 0: V16HI "=&vr") (unspec:...(operand 1: V16QI "vr"))) That is, same mode, same instruction pattern. We want the constraint to be different according to TARGET_MIN_VLEN. Currently, I don't know whether we can have an approach to support this feature. Thanks. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-11-24 02:18 To: 钟居哲 CC: gcc-patches; vmakarov; kito.cheng Subject: Re: [PATCH 0/5] Add support for operand-specific alignment requirements 钟居哲 <juzhe.zh...@rivai.ai> writes: > Hi, Richard. > > Current define_mode_attr can only map an attribute for a mode. > I wonder whether we can map a mode to multiple attributes ? > > E.g. (define_mode_attr dest_constraint [(V16QI "&vr")]) > > But I want it to be: > > (define_mode_attr dest_constraint [(V16QI (TARGET_MIN_VLEN <= 128 "vr") > (TARGET_MIN_VLEN > 128 "&vr")) ]) > > It seems that we can't achieve this for now. Would it be possible we exend it > in GCC-15 ? That construct doesn't seem particularly natural to me. Could you explain (conceptually) what kind of insn patterns you need? Thanks, Richard > > > juzhe.zh...@rivai.ai > > From: Richard Sandiford > Date: 2023-11-22 18:08 > To: juzhe.zhong\@rivai.ai > CC: gcc-patches; vmakarov\@redhat.com; kito.cheng > Subject: Re: [PATCH 0/5] Add support for operand-specific alignment > requirements > "juzhe.zh...@rivai.ai" <juzhe.zh...@rivai.ai> writes: >> Hi, Richard. >> >> Thanks for supporting register filter in IRA/LRA. >> I found it is useful for RVV since we have a set of widen operations that >> allow source register overlap highpart of dest register group >> >> For example, if vsext.vf2 v0(dest consume reg v0 and reg v1), v1 (source >> consume v1 only) >> I want to support the highpart overlap above. (Currently, we don't any >> overlap between source and dest in such instructions). >> >> So, I wonder whether we can pass "machine_mode" into register filter. Ok, I >> think it's too late since stage 1 closes. I wonder we can add it in GCC-15? > > I think adding a mode would add too much overhead. The mode would be > the mode of the operand, but with subregs, the mode of the operand can > be different from the mode of the RA allocno. So it would no longer > be enough for the RA to calculate a bitmask of filters. It would need > ro remember which modes are used with those filters. > > We'd also need to turn the current HARD_REG_SETs into [MAX_MACHINE_MODE] > arrays of HARD_REG_SETs. (And there are now more than 256 machine modes > for riscv.) > > The pattern that uses the constraints should already "know" the mode. > So if possible, I think it would be better to use different constraints > for different modes, using define_mode_attrs. > > Thanks, > Richard >
