On 07/09/2020 07:08, Qian, Jianhua wrote: > Hi > > I'm adding a new machine model. I have a problem when writing the > "define_insn_reservation" for instruction scheduling. > How to write the "define_insn_reservation" for one instruction that there are > different latencies and pipelines according to parameter. > > For example, the ADD (shifted register) instruction in a64fx > > Instruction Option Latency Pipeline > ADD (shifted register) <amount> = 0 1 EX* | EAG* > <amount> = [1-4] && <shift>=LSL 1+1 (EXA + EXA) > | (EXB + EXB) > 2+1 (EXA + > EXA) | (EXB + EXB) >
A shift by immediate zero isn't a shift, so should never use this RTL pattern. We can ignore that case. > In aarch64.md ADD (shifted register) instruction is defined as following． > (define_insn "*add_<shift>_<mode>" > [(set (match_operand:GPI 0 "register_operand" "=r") > (plus:GPI (ASHIFT:GPI (match_operand:GPI 1 "register_operand" "r") > (match_operand:QI 2 "aarch64_shift_imm_<mode>" > "n")) > (match_operand:GPI 3 "register_operand" "r")))] > "" > "add\\t%<w>0, %<w>3, %<w>1, <shift> %2" > [(set_attr "type" "alu_shift_imm")] > ) You might consider using a define_bypass to adjust the cost - the matcher rule takes a producer and consumer RTL - you don't care about the consumer, but you can use the bypass to reduce the cost if the producer uses an immediate in the 'low latency' range. This would avoid having to make a load of whole-sale changes to the main parts of the machine description. > > It could not be distinguished by the type "alu_shift_imm" when writing > "define_insn_reservation" for ADD (shifted register). > What should I do? > > Regards > Qian > > > R.
