From: "H. Peter Anvin" <hpa@zytor.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Ingo Molnar <mingo@elte.hu>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
"Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: [patch 0/2] Immediate Values - jump patching update
Date: Mon, 28 Apr 2008 19:07:18 -0700 [thread overview]
Message-ID: <481682D6.5010207@zytor.com> (raw)
In-Reply-To: <20080429014623.GA6284@Krystal>
Mathieu Desnoyers wrote:
>
> Peter, do you have something like the following code in mind ?
>
Basically, although I was suggesting using a per-site dynamic piece of
code. Data items may not necessarily be in registers.
> I think the main differences between the code snippet down here and the
> markers is that markers rely on the compiler to generate the stack
> setup, and have this code a little bit closer to the function than what
> I propose here, where I put the stack setup code in a "farfaraway"
> section. Moreover, markers are much simpler than what I show here.
> And actually, markers can be deployed portably, with
> architecture-specific optimizations refined later. This has to be
> implemented all up front for any traced architecture. In addition,
> dealing with weird types like unsigned long long can become a pain.
> Also, due to fact that we are asking the compiler to put keep some
> variables live in registers, I would be tempted to embed this in a block
> controlled by an if() statement (conditional branch, like I use for the
> markers) so we don't have to pay the penality of populating the
> registers when not required if there are not live at the marker site.
We're requesting to keep them *alive*, but not necessarily in registers
(that would be an "r" constraint.)
-hpa
next prev parent reply other threads:[~2008-04-29 2:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 3:34 [patch 0/2] Immediate Values - jump patching update Mathieu Desnoyers
2008-04-28 3:34 ` [patch 1/2] Immediate Values - jump liveliness Mathieu Desnoyers
2008-04-28 3:34 ` [patch 2/2] Markers - use imv_cond " Mathieu Desnoyers
2008-04-28 12:48 ` [patch 0/2] Immediate Values - jump patching update Ingo Molnar
2008-04-28 14:35 ` Mathieu Desnoyers
2008-04-28 17:21 ` H. Peter Anvin
2008-04-28 20:25 ` Ingo Molnar
2008-04-28 21:03 ` H. Peter Anvin
2008-04-28 22:11 ` Ingo Molnar
2008-04-28 22:25 ` H. Peter Anvin
2008-04-28 22:44 ` Ingo Molnar
2008-04-28 23:06 ` H. Peter Anvin
2008-04-29 0:47 ` Frank Ch. Eigler
2008-04-29 1:08 ` H. Peter Anvin
2008-04-29 12:08 ` Ingo Molnar
2008-05-14 14:53 ` Pavel Machek
2008-04-29 1:46 ` Mathieu Desnoyers
2008-04-29 2:07 ` H. Peter Anvin [this message]
2008-04-29 12:18 ` Mathieu Desnoyers
2008-04-29 15:35 ` H. Peter Anvin
2008-05-04 14:54 ` Mathieu Desnoyers
2008-05-04 21:05 ` H. Peter Anvin
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=481682D6.5010207@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=fche@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
/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.