public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: "H. J. Lu" <hjl@lucon.org>
Cc: binutils@sources.redhat.com
Subject: Re: PATCH: Disable hint in B unit for Montecito
Date: Fri, 18 Feb 2005 00:13:00 -0000	[thread overview]
Message-ID: <1108674344.5617.64.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <20050217184731.GA6409@lucon.org>

[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]

On Thu, 2005-02-17 at 10:47, H. J. Lu wrote:
> On Wed, Feb 16, 2005 at 08:43:11PM -0800, H. J. Lu wrote:
> > Unfortunately, it is trickier than I thought. With 2.6 kernel, my
> > old change works OK. My new change doesn't work. Jim, do you have
> > any suggestions?

An option here is to make it a warning by default, which I mentioned in
my earlier message, and which is what we have done with almost all of
the other new diagnostics.

> I think it is OK to change unit when manual bundling is off there is no
> user template. I am testing 2.4 and 2.6 kernel build now.

Yes, this is true.  However, I see other problems here.

Forcing the hint to an I unit doesn't do what it appears to do.  Since B
slots are always at the end or followed by another B slot, the
instruction will not fit into the current bundle.  So we will fill the
current bundle with nops, and then come back to this loop again, at
which point we will have a different template, and the hint could very
well end up in a M or F slot, even though we tried to force it into an I
slot earlier.  This is potentially confusing.  There should at least be
a comment here saying that the purpose of this is to prevent the
instruction from going into the current slot.  It will go into a later
slot, at which point we may choose a different unit for it.

The asm source specifies a MIB template, but there is no MIB template in
the output.  I believe this is an assembler bug.  The problem arises
because the bundle before the MIB template is incomplete.  We should pad
it with nops, but instead we steal instructions from the MIB template,
and that causes us to lose track of the MIB template which is attached
to the nop.m instruction.  The result is a BBB template.  This is a
problem, because BBB templates use different less efficient branch
prediction.  That is presumably why the MIB template was specified in
the first place.  This needs to be fixed.

With that problem fixed, this problem goes away, as we are no longer
trying to force the hint instruction into a B slot.

Anyways, your patch is OK with the comment added that explains that we
are using insn_unit to force the hint insn to the next slot, instead of
forcing it into an I slot.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


[-- Attachment #2: patch.insn.bundling --]
[-- Type: text/plain, Size: 1049 bytes --]

This is an untested patch to fix the problem I pointed out with bundle
handling.  This works for your testcase.  We get the user requested MIB
template, and the hint ends up in an M slot.

2005-02-17  James E Wilson  <wilson@specifixinc.com>

	* config/tc-ia64.c (emit_one_bundle): Stop filling a bundle if we
	see an instruction that specifies a template.

Index: tc-ia64.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-ia64.c,v
retrieving revision 1.144
diff -p -p -r1.144 tc-ia64.c
*** tc-ia64.c	17 Feb 2005 07:43:11 -0000	1.144
--- tc-ia64.c	17 Feb 2005 21:03:40 -0000
*************** emit_one_bundle ()
*** 6564,6569 ****
--- 6564,6574 ----
  	  break; /* Need to start a new bundle.  */
  	}
  
+       /* If this instruction specifies a template, then it must be the first
+ 	 instruction of a bundle.  */
+       if (curr != first && md.slot[curr].user_template >= 0)
+ 	break;
+ 
        if (idesc->flags & IA64_OPCODE_SLOT2)
  	{
  	  if (manual_bundling && !manual_bundling_off)

  parent reply	other threads:[~2005-02-17 21:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-17  0:10 H. J. Lu
2005-02-17  3:37 ` James E Wilson
2005-02-17 12:37   ` H. J. Lu
2005-02-17 13:05     ` H. J. Lu
2005-02-17 21:42       ` H. J. Lu
2005-02-17 21:47         ` H. J. Lu
2005-02-18  0:13         ` James E Wilson [this message]
2005-02-18  2:05           ` H. J. Lu
2005-02-18  4:43             ` James E Wilson

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=1108674344.5617.64.camel@aretha.corp.specifixinc.com \
    --to=wilson@specifixinc.com \
    --cc=binutils@sources.redhat.com \
    --cc=hjl@lucon.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).