"Amker.Cheng" <amker.ch...@gmail.com> writes: > In gcc internal, section 16.19.8, there is a rule about > "define_insn_reservation" like: > "`condition` defines what RTL insns are described by this > construction. You should re- > member that you will be in trouble if `condition` for two or more > different `define_insn_ > reservation` constructors if TRUE for an insn". > > While in mips.md, pipeline description for each processor are > included along with > generic.md, which providing a fallback for processor without specific > pipeline description. > > Here is the PUZZLE: Won't `define_insn_reservation` constructors >>From both specific > processor's and the generic md file break the rule mentioned before? > For example, It seems > conditions for the r3k_load(from 3000.md) and generic_load(from > generic.md) are both TRUE > for lw insn.
Looks to me like the MIPS backend is relying on undocumented behaviour: when multiple define_insn_reservation statements match, the automata will match them in order. It would be better if the define_insn_reservation in generic.md checked "cpu". Ian
