public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [PATCH] IA64 trap code 16 bytes atomic copy on montecito
Date: Tue, 31 Oct 2006 08:40:46 +0000	[thread overview]
Message-ID: <000301c6fcc8$4899de20$5181030a@amr.corp.intel.com> (raw)
In-Reply-To: <4546E55E.3050207@intel.com>

Mao, Bibo wrote on Tuesday, October 31, 2006 12:19 AM
> > Also there is no need to resize the register stack frame here, since
> > this is already a leaf function and there are plenty scratch register
> > you can use before tap into register stack.  I personally prefer not
> > to do alloc instruction here.
> > 
> > And I think it would be a lot easier if you implement an intrinsic
> > function, like ia64_ld16/ia64_st16 and stick them in include/asm-ia64/
> > gcc_intrin.h and intel_intrin.h.
> > 
> 
> but there will be inline asm in c language, it is not benefit for gcc to
> optimization, I hear that IA64 hates inline asm.

We hate style like:

void foo()
{
	int a;

	blah()

	asm("ld16 ..." :: "" ..."");

	bar();
}

Because this breaks all icc builds.  It's perfectly fine to add an
abstraction function that turns the above asm("") into ia64_ld16(). For
gcc, it expands into an inline asm. For icc, it turns into an intrinsic.

In fact, for a simple case like ld16 instruction, it is better to use
intrinsic (or gcc asm with appropriate clobber list) because using a
function call will pretty much destroy all high level optimization
around that call. Just imagine all of intermediate value stored in
scratch registers before the call all become void after the call. With
asm/intrinsic, the compiler has more knowledge to what's going on and
can do a better job at it.



  parent reply	other threads:[~2006-10-31  8:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31  5:55 [PATCH] IA64 trap code 16 bytes atomic copy on montecito bibo,mao
2006-10-31  6:18 ` Keith Owens
2006-10-31  7:53 ` Chen, Kenneth W
2006-10-31  8:09 ` Chen, Kenneth W
2006-10-31  8:19 ` bibo,mao
2006-10-31  8:40 ` Chen, Kenneth W [this message]
2006-10-31 12:48 ` bibo,mao

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='000301c6fcc8$4899de20$5181030a@amr.corp.intel.com' \
    --to=kenneth.w.chen@intel.com \
    --cc=linux-ia64@vger.kernel.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