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]
Other format: [Raw text]

Re: [patch] MIPS: 64bit floating point support for MIPS32R2

Richard Sandiford wrote:
David Ung <> writes:

Richard Sandiford wrote:

David Ung <> writes:

Richard Sandiford wrote:

I'm still a little worried about that cannot_change_mode_class hunk;
do you know off-hand why it's needed?

hmm. If I still recall this correctly. The check (FP_INC > 1) is no longer valid for gp32+fp64, but there still needs a reg_classes_intersect_p (FP_REGS, class) check to ensure we ain't simply converting between 32bit integer and 64bit floats. The check at the end of the function will catch 32bit -> 64bit float, but not 64bit -> 32bit. It should allow pattens such as subreg:SI (reg:DF) or even the paradoxical subreg:DI (reg:SF) provided they fit. But subreg:SF (reg:DI) is a no no.

I'm probably being dense here, but why is it a no-no?  How is it
different from the -mgp64 -mfp64 case?

I am guessing here since I don't have a real example, so correct me if I am wrong,

In -mgp32 -mfp32, if you have

set (subreg:SF (reg:DI X) 0) (reg:SF Y)
set (subreg:SF (reg:DI X) 4) (reg:SF Z)

will mean allocation X to a float register eg $f0, and you get

set (reg:SF $f0) (reg:SF Y)
set (reg:SF $f1) (reg:SF Z)

in -mgp32 -mfp64:

set (reg:SF $f0) (reg:SF Y)
set (reg:SF ???) (reg:SF Z)

there just no patterns to match that, nor are
set (subreg:SF (reg:DI $f0) 4) ...

in -mgp64 -mfp64, would you even generate the above patterns?

Ah, thanks, I think I see now.  It's the non-lowpart subregs you're
worried about.  That's what I'd failed to grasp from the earlier
conversation.  (The existing function is dealing with cases where
even lowpart subregs are invalid.)

So the issue you're dealing with is that gcc assumes that each word
of a multiword value can be accessed using SUBREGs.  I suppose this
situation is the same as MMX registers on the x86, which are also

In that case, I agree you're taking the right kind of approach,
but I don't think the patch is quite right.  It's disallowing all
conversions in which one mode is bigger than a word and the other
mode isn't.  It also triggers for TARGET_64BIT, where this
particular restriction doesn't apply.  Does something like:

  /* gcc assumes that each word of a multiword register can be accessed
     individually using SUBREGs.  This is not true for floating-point
     registers if they are bigger than a word.  */
      && GET_MODE_SIZE (from) > UNITS_PER_WORD
      && reg_classes_intersect_p (FP_REGS, class))
    return true;

in the outer scope of the function work? (Yeah, it's a bit of a mouthful.)

If you are ok with all that, then I have no problems with it. :) I'll redo the patch and run regressions to make sure it hasn't broken anything.


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