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

[Zack Weinberg <zack at codesourcery dot com>]

On Fri, Oct 26, 2001 at 06:13:04PM -0400, David Edelsohn wrote:
> 
> 	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.

More or less.  I'm not sure what the exact OS interface is, but the task
scheduler has to be manually informed which tasks need the FPR saved.

There is discussion about changing that, but even if it is, they still want
the compiler to avoid use of FPRs wherever possible, because they don't
want to eat the overhead of saving+restoring state when not absolutely
necessary.  In addition to the block move issue, I've been told there
are known problems with the (vintage 2.96-era) varargs implementation
and with C++ exception handling (which is setjmp/longjmp-based).

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

I would be perfectly happy with a solution that never used the FPRs for
block moves.  I still haven't found one that doesn't break something
else, though.

It turns out that one of my important test cases never hits
move_by_pieces, or even expand_block_move; it goes straight from
store_expr to emit_move_insn, and we *have* a general movdi insn
on PPC, so that's what gets emitted:

(insn 12 10 13 (set (reg:DI 119)
        (mem/s:DI (reg:SI 117) 0)) 445 {*movdi_32} (nil)
    (nil))

I am pretty much convinced at this point that register allocation is the
right place to fix this, not tree->RTL conversion.  There's nothing wrong
with that insn; but regs 119 and 117 need to be assigned to GPR pairs.

zw