This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 14/15] MIPS/GAS/test: Run the LD test with forward references
On Sun, 10 Oct 2010, Richard Sandiford wrote:
> > Any particular reason we take this approach these days? I understand
> > with the old relaxation code resolving such things was somewhat tricky if
> > possible at all, but I see no reason for the extra NOP to be emitted to
> > the variant frags as a need arises these days. In no case it would seem
> > the dependency would cross beyond a variant frag to any code that follows
> > so no need to fear choosing the second variant would cause any NOPs to be
> > missing to satisfy code after the frag it would seem (to me anyway).
>
> No particular reason, no. It just wasn't part of the motivation for
> the original relaxation changes. Improving the quality of MIPS I code
> is always very low down the priority list.
It depends for whom. ;) I do accept the reality though. Thanks for the
explanation. It looks a little bit involving to me, so I'll defer it for
the time being and see if I can squeeze it in the 2.22's timeframe. :)
> > gas/testsuite/
> > * gas/mips/ld.s: Adjust to let data objects be only
> > defined/declared (as appropriate) at the end of assembly, based
> > on the presence or not of the "forward" symbol.
> > * gas/mips/ld-f.d: New test.
> > * gas/mips/mips1@ld-f.d: Likewise. MIPS I version.
> > * gas/mips/r3000@ld-f.d: Likewise, R3000 version.
> > * gas/mips/ecoff@ld-f.d: Likewise, ECOFF version.
> > * gas/mips/r3900@ecoff@ld-f.d: Likewise, R3900/ECOFF version.
> > * gas/mips/mips2@ecoff@ld-f.d: Likewise, MIPS II/ECOFF version.
> > * gas/mips/mips32@ecoff@ld-f.d: Likewise, MIPS32/ECOFF version.
> > * gas/mips/mips32r2@ecoff@ld-f.d: Likewise, MIPS32r2/ECOFF
> > version.
> > * gas/mips/ld-n32-f.d: New test.
> > * gas/mips/ld-n64-f.d: Likewise.
> > * gas/mips/mips.exp: Run the new tests.
>
> Let's use "-forward" rather than "-f", for consistency with the
> symbol name and to avoid any possible confusion with "floating point".
>
> OK otherwise, thanks.
Committed with your suggestion applied now, thanks.
Maciej