public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: linux-ia64@vger.kernel.org
Subject: Re: PATCH: Re: Inefficient ia64 system call implementation in glibc
Date: Thu, 25 Sep 2003 04:34:55 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106446452203374@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106438485815490@msgid-missing>

On Wed, Sep 24, 2003 at 02:12:38PM -0700, Jim Wilson wrote:
> On Wed, 2003-09-24 at 11:56, H. J. Lu wrote:
> > I don't think it will be the problem. Compiler will do
> > 	addl outN = constant, r0
> > to pass a constant to the function, regardless what the type is. Am I
> > correct?
> 
> No.
> 
> The compiler will emit RTL like this
> 	(set (reg:SI outN) (const_int constant))
> which will translate to a
> 	addl outN = constant, r0
> instruction.
> 
> However, if you are optimizing, then all we are guaranteed is that a
> value equivalent to an SImode constant will end up in the register.  If
> you have something like
>   if (i = 0)
>      sub (0);
> and i has type int, and i happens to be already in the right register
> for the first argument to sub, then the compiler will optimize away the
> load of zero as redundant.  The if statement uses cmp4 which only looks
> at the low order 4 bytes of i, and hence any value could be in the upper
> 4 bytes.  This is OK per the ABI, which says that only the low 4 bytes
> of an integer argument are valid.
> 

My patch only applies to LOAD_ARGS_##nr in

#define INTERNAL_SYSCALL(name, err, nr, args...)                \
  ({                                                            \
    register long _r8 asm ("r8");                               \
    register long _r10 asm ("r10");                             \
    register long _r15 asm ("r15") = __NR_##name;               \
    long _retval;                                               \
    LOAD_ARGS_##nr (args);                                      \
    __asm __volatile (BREAK_INSN (__BREAK_SYSCALL)              \
                      : "=r" (_r8), "=r" (_r10), "=r" (_r15)    \
                        ASM_OUTARGS_##nr                        \
                      : "2" (_r15) ASM_ARGS_##nr                \
                      : "memory" ASM_CLOBBERS_##nr);            \
    _retval = _r8;                                              \
    err = _r10;                                                 \
    _retval; })

I don't think it is an issue here. The current one is

#define LOAD_ARGS_1(out0)                               \
  register long _out0 asm ("out0") = (long) (out0);     \
  LOAD_ARGS_0 ()

I don't believe it is any better than

#define LOAD_ARGS_1(out0)                                      \
  register __typeof ((out0) + 0) _out0 asm ("out0") = (out0);  \
 
as far as function prototype is concerned. If there is a mismatch,
long can have problems too.


H.J.

  parent reply	other threads:[~2003-09-25  4:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-24  6:27 PATCH: Re: Inefficient ia64 system call implementation in glibc H. J. Lu
2003-09-24  7:43 ` Jakub Jelinek
2003-09-24  8:36 ` Andreas Schwab
2003-09-24 18:56 ` H. J. Lu
2003-09-24 20:36 ` Andreas Schwab
2003-09-24 21:12 ` Jim Wilson
2003-09-25  4:34 ` H. J. Lu [this message]
2003-09-25  4:36 ` H. J. Lu
2003-09-25  4:39 ` H. J. Lu

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=marc-linux-ia64-106446452203374@msgid-missing \
    --to=hjl@lucon.org \
    --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