This is the mail archive of the mailing list for the binutils 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] Optionally disable odd-numbered single-precision registers

Richard Sandiford <> writes:
> Matthew Fortune <> writes:
> > Richard Sandiford <> writes:
> >> Is that right?  If so, I agree that would work as far as the diagnostics
> go.
> >> But would it be useful to keep track of which objects are -moddspreg and
> >> which aren't, especially if we're using -mfpxx with both?  E.g. maybe we
> >> could use one of the flags1 bits in the abiflags structure.  If we did
> that
> >> then I imagine we'd want to know which -moddspreg setting was "really"
> >> in use.
> >
> > I did think about this and I suspect the only reason I did not do it in
> the
> > end was actually laziness so I think I should add a flag. The overall
> > effect of the flag should record if all modules only use 16 registers so
> the
> > flag would have to be 'nooddspreg' and be AND (rather than OR as flags1 is
> > defined) so would need to go in flags2.
> I was thinking of it the other way around: set the flag if the odd registers
> might be used and OR the input flags.  I think that fits the scheme better,
> with the bit saying whether a particular architecture feature
> (independent odd-numbered registers) is used.

OK. It was the assumption we make about existing objects that concerned me
however if this is introduced with the initial .MIPS.abiflags then we have
the opportunity to infer the flag as being true.

> Whether we assume 0 or 1 for old objects is kind-of a separate question.
> I suppose there are arguments both ways...

I'd try to make the most pessimistic assumption. For 32-bit FP ABIs then the
oddspreg would be true for isa_rev>=1 (as determined by the EF_MIPS_MACH/ARCH).


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