> If you don't know anything about register class preferencing or reload as
> yet, then this is probably not going to make much sense to you, but it isn't
> anything important you need to worry about at this point. It is a very
> minor performance optimization.
>
It makes sense to me now, though I haven't read codes for IRA and reloads yet.
Thanks for the detailed explanation.
>
> A define_split can only match something generated by a define_insn, and the
> mul_acc_si define_insn is testing "GENERATE_MADD_MSUB && !TARGET_MIPS16"
> so there is no serious problem. We are just running a define_split that can
> never match anything. This could be cleaned up a little by adding an
> appropriate condition to the define_split, or by combining the define_insn
> and define_split patterns into a define_insn_and_split pattern.
In upper words, you mean that define_split would only get chance to
split insn generated
by the corresponding pattern "define_insn \"*mul_acc_si\"", though the
split condition is
some kind of weak(with only "reload_completed"). Because that kind of
insn would only
be generated by the "define_insn \"*mul_acc_si\"" pattern.
Did I get it right? if so, i'm afraid this is actually not my question.
What wanna know is:
mips processors normally implement following kinds of mult/mult-acc insns:
mult : HILO <-- s * t
mul : HILO <-- s * t ; d <-- LO
madd : HILO <-- HILO + s * t
madd2 : HILO <-- HILO + s * t ; d <-- HILO
------------------------------------cut here---------------------
In my understanding, the macro GENERATE_MADD_MSUB is true when the processor has
madd insn, rather than madd2. And the macro "ISA_HAS_<D>MUL3" is false if it has
no mul insn.
for this kind processor, gcc will
step 1 : generate insn using gen_mul<mode>3_internal, according to
pattern "mul<mode>3";
step 2 : the combiner try to combine by matching against pattern "*mul_acc_si";
step 3 : it's possible that gcc fail to get LO register allocated for
the combined "*mul_acc_si" insn;
step 4 : after reload, the combined insn will be split according to
the split pattern listed in previous mail.
step 5 : the split insn is actually a "mul<mode>3_internal" , but get
no LO allocated, which break the
constraints in "mul<mode>3_internal" pattern;
So, what should I do to handle this case? I see no methods except
adding new split pattern like:
(define_split
[(set (match_operand:SI 0 "d_operand")
(plus:SI (mult:SI (match_operand:SI 1 "d_operand")
(match_operand:SI 2 "d_operand"))
(match_operand:SI 3 "d_operand")))
(clobber (match_operand:SI 4 "lo_operand"))
(clobber (match_operand:SI 5 "d_operand"))]
"SPECIAL_PROCESSOR && reload_completed"
[(parallel [(set (match_dup 4)
(mult:SI (match_dup 1) (match_dup 2)))
(clobber (match_dup 4))])
(set (match_dup 5) (match_dup 4))
(set (match_dup 0) (plus:SI (match_dup 5) (match_dup 3)))]
"")
Thanks again, looking forward your new explanations.
--
Best Regards.
