Nigel Stephens [EMAIL PROTECTED] writes:
OK, so maybe as the person who removed adddi3 from the MIPS backend, and
the main proponent of the new fused opcodes, you get to volunteer to
implement this? :)
Hey, I was pretty happy with the status quo ;)
Richard
Richard Sandiford wrote:
Nigel Stephens [EMAIL PROTECTED] writes:
I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris,
mcore, score, arm pa backends still implement adddi3 as either a
define_insn which outputs two instructions or an explicit define_expand
followed
Richard Sandiford wrote:
Nigel Stephens [EMAIL PROTECTED] writes:
While I agree with you philosophically, it feels like (b) might be quite
a major task. A number of optimisation passes which currently recognise
and MUL and PLUS separately (e.g. loop strength reduction) would now
need to
Nigel Stephens [EMAIL PROTECTED] writes:
I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris,
mcore, score, arm pa backends still implement adddi3 as either a
define_insn which outputs two instructions or an explicit define_expand
followed define_split and associated sub
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem to me that in the
Tree-SSA world, it makes less sense to duplicate standard optabs
in the backend purely for the reason of keeping
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem to me that in the
Tree-SSA world, it makes less sense to duplicate standard optabs
in the
Richard Sandiford [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem to me that in the
Tree-SSA world, it makes
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
I realise no-one else has spoken out in support of me, so perhaps
I'm in a minority of one here. But it does seem
(define_insn adddi3_internal_1
[(set (match_operand:DI 0 register_operand =d,d)
(plus:DI (match_operand:DI 1 register_operand 0,d)
(match_operand:DI 2 register_operand d,d)))
(clobber (match_operand:SI 3 register_operand =d,d))]
!TARGET_64BIT
Fu, Chao-Ying [EMAIL PROTECTED] writes:
After tracing GCC 4.x to see why MADD is not generated for MIPS32,
I found out the main issue is that the pattern adddi3
is not available for MIPS32. Because the missing
of adddi3, GCC 4.x needs to split 64-bit addition to 4 separate
RTL insns. This
Richard Sandiford wrote:
As far as madd goes, I think it would be better to either
(a) get combine to handle this situation or (b) get expand
to generate a fused multiply-add from the outset.
(b) sounds like it might be useful in its own right. At the moment we
treat the generation of
Nigel Stephens [EMAIL PROTECTED] writes:
While I agree with you philosophically, it feels like (b) might be quite
a major task. A number of optimisation passes which currently recognise
and MUL and PLUS separately (e.g. loop strength reduction) would now
need to be extended to handle the
Richard Sandiford wrote:
Nigel Stephens [EMAIL PROTECTED] writes:
While I agree with you philosophically, it feels like (b) might be quite
a major task. A number of optimisation passes which currently recognise
and MUL and PLUS separately (e.g. loop strength reduction) would now
need to
Paolo Bonzini [EMAIL PROTECTED] writes:
(define_insn adddi3_internal_1
[(set (match_operand:DI 0 register_operand =d,d)
(plus:DI (match_operand:DI 1 register_operand 0,d)
(match_operand:DI 2 register_operand d,d)))
(clobber (match_operand:SI 3
This should be a post-reload (i.e. predicated on reload_completed)
split, I think.
Actually, with the relatively recent lower-subreg work, it is
desirable to split this sort of instruction before reload. That is,
do an unconditional split.
Right. Combine cannot cope with the resulting
Paolo Bonzini [EMAIL PROTECTED] writes:
This should be a post-reload (i.e. predicated on reload_completed)
split, I think.
Actually, with the relatively recent lower-subreg work, it is
desirable to split this sort of instruction before reload. That is,
do an unconditional split.
Right.
Hi Richard,
After tracing GCC 4.x to see why MADD is not generated for MIPS32,
I found out the main issue is that the pattern adddi3
is not available for MIPS32. Because the missing
of adddi3, GCC 4.x needs to split 64-bit addition to 4 separate
RTL insns. This leads to that the combining
17 matches
Mail list logo
