This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dangerous cleverness? ppc int<->float conversions, subreg
- To: Zack Weinberg <zack at codesourcery dot com>
- Subject: Re: dangerous cleverness? ppc int<->float conversions, subreg
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Sat, 27 Oct 2001 16:36:43 -0400
- cc: Dale Johannesen <dalej at apple dot com>, gcc at gcc dot gnu dot org
>>>>> Zack Weinberg writes:
Zack> It turns out that one of my important test cases never hits
Zack> move_by_pieces, or even expand_block_move; it goes straight from
Zack> store_expr to emit_move_insn, and we *have* a general movdi insn
Zack> on PPC, so that's what gets emitted:
Zack> (insn 12 10 13 (set (reg:DI 119)
Zack> (mem/s:DI (reg:SI 117) 0)) 445 {*movdi_32} (nil)
Zack> (nil))
Zack> I am pretty much convinced at this point that register allocation is the
Zack> right place to fix this, not tree->RTL conversion. There's nothing wrong
Zack> with that insn; but regs 119 and 117 need to be assigned to GPR pairs.
Does the testcase use an aggregate or "long long"?
I still have a different perspective on the problem. You seem to
be asking: "Why does GCC use FPRs for DImode?" I am asking: "Why does GCC
use DImode for the moves?"
If GCC were performing any DImode computation with the values
moved from memory, another instruction would have imposed GPR preference,
so DImode cannot be necessary for the test case.
David