This is the mail archive of the
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: Fri, 26 Oct 2001 15:42:22 -0400
- cc: gcc at gcc dot gnu dot org
>>>>> Zack Weinberg writes:
Zack> I'm not sure about this. move_by_pieces on a PPC generates a plain
Zack> (set (reg:DI 123) (mem:DI location1))
Zack> (set (mem:DI location2) (reg:DI 123))
Zack> It's register allocation that decides that (reg:DI 123) will be
Zack> assigned to a floating point register. If I use -msoft-float, we
Zack> *still* get a DImode pseudo from move_by_pieces. Register allocation
Zack> then assigns it to an integer register pair - without breaking up the
Zack> DImode move.
Zack> What are you suggesting move_by_pieces do instead?
Zack> Note also that it is acceptable and perhaps even desirable, in the
Zack> special mode I want, to do block move through FPRs if there's other
Zack> floating-point activity in the same function.
On 32-bit PowerPC, the max GPR size is 32-bits: SImode. What I
think you want is move_by_pieces to generate
(set (reg:SI 123) (mem:SI location1))
(set (mem:SI location2) (reg:SI 123))
unless FPR was ever used in the function. move_by_pieces also seems to be
ignoring MOVE_MAX which is 4 bytes on 32-bit PowerPC.
My point is that your current strategy is fighting with the
register allocator to do the right thing for DImode. However, DImode is
completely wrong on a 32-bit system if you only want to use GPRs and not
FPRs. Your real problem is convincing move_by_pieces to use SImode in the
If you use GPRs for DImode move on a 32-bit system, you have
undermined the whole reason for the DImode choice. You should not be
pairing GPRs for a DImode move on a 32bit system because move_by_pieces
should generate the SImode moves in the first place.
If you want to use FPRs when the function legitimately uses
floating point, that is a further machine-dependent tweak of allowing
DImode when any FPR is live in the function (assumed allocated for a
legitimate floating point operation).