, April 20, 2007 8:05 AM
> To: Stephens, Nigel
> Cc: Fu, Chao-Ying; gcc@gcc.gnu.org; Thekkath, Radhika
> Subject: Re: [MIPS] MADD issue
>
>
> Nigel Stephens <[EMAIL PROTECTED]> writes:
> > OK, so maybe as the person who removed adddi3 from the MIPS
> backend, and
>
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 he
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-SS
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
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 keepin
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 def
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
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:
>>> 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 sp
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 4-in
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_
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:
> 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 t
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 floati
"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 in
(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 &
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 ph
18 matches
Mail list logo
