public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rdsandiford@googlemail.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: binutils@sourceware.org
Subject: Re: [PATCH 14/15] MIPS/GAS/test: Run the LD test with forward references
Date: Sun, 10 Oct 2010 10:19:00 -0000	[thread overview]
Message-ID: <87bp72l59c.fsf@firetop.home> (raw)
In-Reply-To: <alpine.LFD.2.00.1010022116070.15889@eddie.linux-mips.org>	(Maciej W. Rozycki's message of "Sun, 3 Oct 2010 20:41:14 +0100	(BST)")

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
>  Note this has revealed a deficiency in our relaxation code.  In theory 
> the machine code generated from a single piece of assembly source should 
> be the same regardless of whether any data objects referenced have been 
> provided before the respective references or after.  This is not the case.  
> A couple of unnecesary load-delay NOPs are output for platforms that have
> load-delay slots.
>
>  The reason for this is the load-delay slot dependency is only checked 
> against the first relaxation variant and any requirements are fulfilled by 
> appending these NOPs (or one only, as other cases such as HI/LO 
> dependencies do not apply here) to the code before the variant frag, 
> rather then the relaxed sequence itself.  If in the end the second variant 
> is chosen then the stray NOP remains.
>
>  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.

> 2010-10-03  Maciej W. Rozycki  <macro@linux-mips.org>
>
> 	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.

Richard

  reply	other threads:[~2010-10-10 10:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-03 19:41 Maciej W. Rozycki
2010-10-10 10:19 ` Richard Sandiford [this message]
2010-10-24 10:25   ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bp72l59c.fsf@firetop.home \
    --to=rdsandiford@googlemail.com \
    --cc=binutils@sourceware.org \
    --cc=macro@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).