This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: dangerous cleverness? ppc int<->float conversions, subreg

>>>>> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]