public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Noah Goldstein <goldstein.w.n@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Noah Goldstein via Libc-alpha <libc-alpha@sourceware.org>,
	hjl.tools@gmail.com, carlos@systemhalted.org
Subject: Re: [PATCH v1] x86-64: Replace `%ah` write with `%eax` read
Date: Mon, 13 Mar 2023 15:49:01 -0500	[thread overview]
Message-ID: <CAFUsyf+7cz3HNxoP_Vc46+-65OCh+8RvNW-u_xT4CrhHn4RLEQ@mail.gmail.com> (raw)
In-Reply-To: <87h6uor23c.fsf@oldenburg.str.redhat.com>

On Mon, Mar 13, 2023 at 12:30 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Noah Goldstein:
>
> > On Mon, Mar 13, 2023 at 3:03 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * Noah Goldstein via Libc-alpha:
> >>
> >> > High8 partial registers can incur a stall when being modified (if not
> >> > renamed seperately), or at the very least incur extra backend uops (if
> >> > renamed seperately). Either way `testl $0x0400, %eax` is preferable to
> >> > `andb $0x04, %ah`.
> >> >
> >> > Function size is unchanged when accounting for 16-byte padding.
> >> > ---
> >> >  sysdeps/x86_64/fpu/e_fmodl.S | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/sysdeps/x86_64/fpu/e_fmodl.S b/sysdeps/x86_64/fpu/e_fmodl.S
> >> > index d754668bce..d45f984e1a 100644
> >> > --- a/sysdeps/x86_64/fpu/e_fmodl.S
> >> > +++ b/sysdeps/x86_64/fpu/e_fmodl.S
> >> > @@ -13,7 +13,7 @@ ENTRY(__ieee754_fmodl)
> >> >       fldt    8(%rsp)
> >> >  1:   fprem
> >> >       fstsw   %ax
> >> > -     and     $04,%ah
> >> > +     testl   $0x400,%eax
> >>
> >> Why not test $0x400,%ax or test $04,%ah?
> > `test $0x400,%ax` uses imm16 which can cause length-changing-prefix
> > (`0x66` in the opcode) stalls.
> > `test $0x4,%ah` is more okay, but partial register usage has several
> > delays associated with it (even pure
> > reads), depends on arch but for example hwl/skl have 2c latency added
> > (in this case where %ah is not
> > being renamed seperately).
> > In general, if you don't need the code size, best to stick with
> > 32/64-bit instructions.
>
> Do we need to clear %eax first to avoid a false dependency?

oh  yeah, guess you're right, probably `test %ah` is best.
>
> Thanks,
> Florian
>

  reply	other threads:[~2023-03-13 20:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10  2:44 Noah Goldstein
2023-03-10 16:38 ` H.J. Lu
2023-03-13  8:03 ` Florian Weimer
2023-03-13 16:59   ` Noah Goldstein
2023-03-13 17:30     ` Florian Weimer
2023-03-13 20:49       ` Noah Goldstein [this message]
2023-03-13 20:50 ` [PATCH v2] x86-64: Replace `and %ah` write with `test %ah` read Noah Goldstein
2023-03-14  2:00   ` 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=CAFUsyf+7cz3HNxoP_Vc46+-65OCh+8RvNW-u_xT4CrhHn4RLEQ@mail.gmail.com \
    --to=goldstein.w.n@gmail.com \
    --cc=carlos@systemhalted.org \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.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).