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

[Dale Johannesen <dalej at apple dot com>]

On Friday, October 26, 2001, at 12:46 PM, David Edelsohn wrote:
>>>>>> Dale Johannesen writes:
>
> Dale> We've noticed this on Darwin too.  I'm not sure anybody's mentioned
> Dale> this point:  the alignment requirements for "double" memrefs can be
> Dale> more restrictive than those for (non-double-containing) structs.  A
> Dale> misaligned FP load/store may be much slower than two int 
> load/stores,
> Dale> or may fail completely.  I don't think there's anyplace in the code
> Dale> that's checking this.
>
> 	See SLOW_UNALIGNED_ACCESS macro in rs6000.h.  It is checking.
> There may be something wrong with the alignment it calculates.

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

> 	FPR use for moves decreased after this change.  This is why I know
> that FPR use can be prevented completely with the right cost model in the
> move_by_pieces tuning.  The important point is don't assume that one
> *always* wants to avoid FPRs for DImode moves, in other words don't
> hard-code a high cost.

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