From: "Alejandro Vallejo" <alejandro.garciavallejo@amd.com>
To: "Jan Beulich" <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger@xenproject.org>,
"Teddy Astie" <teddy.astie@vates.tech>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86emul: Cache the amd_like() output on x86_emulate() entry
Date: Tue, 22 Sep 2026 20:04:31 +0200 [thread overview]
Message-ID: <DLM1L3P13SUV.ZV59HL491777@amd.com> (raw)
In-Reply-To: <baabb75a-dc95-4fad-a682-e4eb40071a73@suse.com>
On Tue Sep 22, 2026 at 3:34 PM CEST, Jan Beulich wrote:
> On 21.09.2026 11:25, Alejandro Vallejo wrote:
> > The current code instantiates amd_like() way too many times, leading to
> > codegen explosion. Unconditionally call it early on, and use that
> > variable everywhere. This shrinks the emulator by ~3KiB.
> >
> > No a functional change.
> >
> > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> > ---
> > pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2860748404
> > (it's red because of an caching issue and personal branch name
> > conventions it's just arm. x86 passes in full)
> >
> > bloat-o-meter before-after patch.
> >
> > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3366 (-3366)
> > Function old new delta
> > x86_emulate 209351 205985 -3366
> > Total: Before=3617694, After=3614328, chg -0.09%
>
> That's surprisingly big a difference, considering how simple amd_like() is.
> I'm counting 24 instances, so the savings would be well over 100 bytes per
> instance.
I have some more interesting results. I can very much repro at that
commit with GCC 13 with debug=y, but ALSO the variable must be set at
the tail of all other locals. I never noticed the gain was gone after
moving where it is in this patch.
Clearly I misattributed the origin of the shrinkage. In retrospect, it
turns out to be an unrelated matter. I _THINK_ register pressure is
somehow precluding the inlining of a helper. The problem is gone in
debug=n where CSE ensures all is good.
If I find a way of shrinking debug builds in a way that's more resilient
to compiler specifics I'll push that as a separate patch, but for now
I'll just drop this. Clearly it doesn't matter here for a realistic
build.
Apologies for the noise. Codegen is hard :)
Alejandro
prev parent reply other threads:[~2026-09-22 18:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 9:25 [PATCH] x86emul: Cache the amd_like() output on x86_emulate() entry Alejandro Vallejo
2026-09-22 13:34 ` Jan Beulich
2026-09-22 18:04 ` Alejandro Vallejo [this message]
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=DLM1L3P13SUV.ZV59HL491777@amd.com \
--to=alejandro.garciavallejo@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger@xenproject.org \
--cc=teddy.astie@vates.tech \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.