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

[David Edelsohn <dje at watson dot ibm dot com>]

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

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

David