This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Zack Weinberg wrote:
> That could work for PPC, but I don't think it will work for Sparc.
> Sparc has the exact same situation with the fix/float patterns.
> Unlike PPC, however, moves from fp to integer regs use plain old
> movdi.  (I think.)  Therefore, I don't think either my SUBREG trick or

Ah, right.  And we really don't want to change it, since using a single
pattern is The Right Thing (tm) to do, as it allows reload the most
freedom. (you can't actually move between fp and integer regs on the
sparc without secondary memory, but that's beside the point: both
classes of register can be moved from / to memory, and you want both
to use the same pattern.)

So it sees that we have to toss some switch in the compiler to use floating
point on an 'as needed' basis.  To have expanders set set switch would be
brittle, since the compiler has some code that emits code to see initialize
a table of the costs.  You could use lineno to check that, but that is
more of a debugging trick than a safe test.
You could use a splitter that only becomes active after rtl generation, i.e.
! rtx_equal_function_value_matters.
This flag would have to be function-specific data end be reset at the end
of a function's compilation.

The trouble with such a flag is that it might be to coarse-grained.  I.e.
you might have a floating point use that is guarded by an if clause, and
don't expect that to spread outside of the if.  The use might even be
originally encapsulated by a function, but exposed due to inlining.

OTOH, you also have to expect such problems for the fp operations themselves
from code hoisting, partial redundancy elimination, and cross-block
Unless you want to convince the compiler that every FP operation
and every move involving FP registers (to be defined by a target macro)
may trap.
Then you could postpone generating the int-in-fpreg moves to some
post-reload phase (post-reload splitters, peephole2 (with multi-insn
pattern as fallback), machine_dependent_reorg, or just plain multi-insn
patterns).  Or teach reload not to generate these moves unless reloading
fp insns / inside a basic block that contains an fp insn.
Uh... we might actually get the effect of the latter with an (ab)use
of mode switching and clobber / use all fp-regs patterns.  But better not
go that way.

Joern Rennecke                  |            gcc expert for hire

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]