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

On Fri, Oct 26, 2001 at 11:47:42AM -0200, Alexandre Oliva wrote:
> On Oct 25, 2001, Zack Weinberg <> 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

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.


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