on 2023/8/17 11:11, Peter Bergner wrote: > On 8/16/23 7:19 PM, Carl Love wrote: >> +(define_insn "dfp_dquan_<mode>" >> + [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d") >> + (unspec:DDTD [(match_operand:DDTD 1 "gpc_reg_operand" "d") >> + (match_operand:DDTD 2 "gpc_reg_operand" "d") >> + (match_operand:QI 3 "immediate_operand" "i")] >> + UNSPEC_DQUAN))] >> + "TARGET_DFP" >> + "dqua<q> %0,%1,%2,%3" >> + [(set_attr "type" "dfp") >> + (set_attr "size" "<bits>")]) > > operand 3 refers to the RMC operand field of the insn we are emitting. > RMC is a two bit unsigned operand, so I think the predicate should be > const_0_to_3_operand rather than immediate_operand. It's always best > to use a tighter predicate if we have one. Ditto for the other patterns > with an RMC operand.
Good point! I agree it's better to use a suitable tighter predicate here, even if for now it's only used for bif expanding and the bif prototype already restricts it. > > I don't think we allow anything other than an integer for that operand > value, so I _think_ that "n" is probably a better constraint than "i"? > Ke Wen/Segher??? Yeah, I agree "n" is better for this context, it better matches your proposed const_0_to_3_operand/s5bit_cint_operand (const_int). BR, Kewen
