Richard Henderson wrote: > On 07/18/2011 08:41 AM, Georg-Johann Lay wrote: >> +(define_insn_and_split "*muluqihi3.uconst" >> + [(set (match_operand:HI 0 "register_operand" "=r") >> + (mult:HI (zero_extend:HI (match_operand:QI 1 "register_operand" >> "r")) >> + (match_operand:HI 2 "u8_operand" >> "M")))] >> + "AVR_HAVE_MUL >> + && avr_gate_split1()" >> + { gcc_unreachable(); } >> + "&& 1" >> + [(set (match_dup 3) >> + (match_dup 2)) >> + ; umulqihi3 >> + (set (match_dup 0) >> + (mult:HI (zero_extend:HI (match_dup 1)) >> + (zero_extend:HI (match_dup 3))))] >> + { >> + operands[2] = gen_int_mode (INTVAL (operands[2]), QImode); >> + operands[3] = gen_reg_rtx (QImode); >> + }) >> + > > I'm not keen on this at all. I'd much prefer a formulation like > > (define_insn_and_split "*muliqihi3_uconst" > [(set (match_operand:HI 0 "register_operand" "=r") > (mult:HI (zero_extend:HI > (match_operand:QI 1 "register_operand" "r")) > (match_operand:HI 2 "u8_operand" "n"))) > (clobber (match_scratch:QI 3 "=&r"))] > "AVR_HAVE_MUL" > "#" > "&& reload_completed" > [...] > ) > > I see the obvious problem, of course, pass_split_after_reload > runs after pass_postreload_cse.
What's bad with pre-reload splits? The only weak point is in target-independent code because there is nothing like split1_completed and other missing information for better pass-awareness. Split1 is almost like a .expand2 pass. Nice :-) It contains all semantics, but a CLOBBER is always loss of information. It's by no means clear that if a value is used 2 or more times, they will be allocated to the same hard register. Note that for some passes (after reload but before post-reload split) there will be a clobber around OP3 so that it is not reusable. These drawbacks are not there for pre-reload splits; doing these things after register allocation is always harder or no more possible because different registers are wasted for the same thing. > Does anything break if we simply move pass_split_after_reload > earlier? Right to the beginning of pass_postreload for instance. > Seems to me that every port would gain by optimizing the stuff > that comes out of the post-reload splitters. I don't know the reason for that or if other machines rely on it. Johann > r~