This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dangerous cleverness? ppc int<->float conversions, subreg
On Fri, Oct 26, 2001 at 11:47:42AM -0200, Alexandre Oliva wrote:
> On Oct 25, 2001, Zack Weinberg <zack@codesourcery.com> wrote:
>
> > I'm currently thinking of setting a flag somewhere that says "this
> > function uses floating point", and having HARD_REGNO_MODE_OK look at
> > that as well as the global flag_implicit_fp.
>
> I don't think setting HARD_REGNO_MODE_OK is going to be enough. I
> think this won't affect the choice of register class, and will end up
> resulting in GCC committing to the FP class before realizing no
> hardware register in that class is going to be usable.
Well, unlike everything else I've tried, it works on my test case :-)
> As for setting a flag, it may be easy enough to add a hook before
> register allocation, such that you can scan the insn stream looking
> for insns with a certain attribute, that marks insns requiring FP.
Yah. I'm thinking of doing this in regclass, right now.
> The code would be something like this:
>
> (define_insn "requires_fp"
> (match_operand:SF 0 "floating_point_operand" "=f")
> "! disable_floating_point /* Just for safety. */"
> ""
> [(set_attr "fp_needed" "yes")])
>
> (define_insn "may_use_fp"
> (match_operand:SI 0 "" "=rf")
> "! disable_floating_point"
> ""
> [(set_attr "fp_usable" "yes")])
>
> (define_insn "dont_use_fp"
> (match_operand:SI 0 "" "=r")
> "disable_floating_point")
I'm confused - do you mean that I should add such set_attr annotations
and disable switches to every floating point insn pattern?
If so, it seems to me that I ought to be able to achieve the same
effect by just scanning all the RTL for ?Fmode operations, and then
adjusting register preferences somehow. (Hmm, -msoft-float sets all
the floating-point registers fixed and call-used. Is there a way to
do that per-function?) This would avoid having to make pervasive
changes to the machine description, although it might be slower.
> I don't see how to do this in a platform-independent way. For one,
> there's no platform-independent concept of FP regs, and some
> architectures have register classes with both GP and FP regs (besides
> ALL_REGS).
There's definitely going to have to be _some_ platform dependent code
changes for each target that implements this, but I'm still hoping to
confine it to one or two tweaks to tm.h macros.
zw