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

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

>>>>> Dale Johannesen writes:

>> See SLOW_UNALIGNED_ACCESS macro in rs6000.h.  It is checking.
>> There may be something wrong with the alignment it calculates.

Dale> Yes, I've seen this.  It doesn't work perfectly, although as you say that
Dale> may have something to do with the alignment (Apple's alignment rules are
Dale> arcane).  More to the point, a boolean is not enough to do the right
Dale> thing.  PPC misalignment penalties come in 3 flavors, not 2 ("optimal",
Dale> "fast", "poor" in the 750 book), they're dependent on the register type,
Dale> and I think they're also dependent on the target cpu.  Thus, moving
Dale> a "struct {short x; short y;};" with int load and store is a good idea
Dale> even if it is not 4-byte aligned, but moving it with float load and
Dale> store may get a slow alignment exception.

	SLOW_UNALIGNED_ACCESS only triggers for SFmode, DFmode, and
DImode, which matches your example rule above.  I only tried to avoid the
"poor" case.

	Any problems are not with alignment rules.  GCC may be too
optimistic in the alignment value it calculates to pass to the macro in
some instances.  It may only use the inner, relative alignment of the
member and not the absolute alignment of the outer, encompassing
structure, for instance.

Dale> I think I agree with that, but I'm not sure of ZW's original motivation in
Dale> trying not to use FP registers unless they were already used in the 
Dale> function;
Dale> I don't see the point of this.  Is the idea to reduce save/restore's?

	Zack's problem is the the embedded OS wants to use lazy FPR save
and restore and does something wrong.  I get the impression that the
function itself tells the OS if it uses floating point, not using the
PowerPC FPU trap.

	The intent is to avoid using FPRs if the function does not have
floating point computations.  The issue is not slow/fast or alignment.  If
the function performs floating point computations, then Zack wants GCC to
use FPRs for everything, including block moves.  If the function does not
use the FPU, it should not use the FPRs for anything.

David