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~
