From: "Christopher Li" <sparse@chrisli.org>
To: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Cc: Josh Triplett <josh@kernel.org>,
Blue Swirl <blauwirbel@gmail.com>,
linux-sparse@vger.kernel.org, David Given <dg@cowlark.com>
Subject: Re: [PATCH 03/15] Add type information to struct instruction.
Date: Mon, 22 Dec 2008 19:21:19 -0800 [thread overview]
Message-ID: <70318cbf0812221921q5e53a8edhad06369537dc3a6c@mail.gmail.com> (raw)
In-Reply-To: <20081215002610.16107.25437.stgit@zaytsev.su>
I think this patch can have more discussion.
If possible, I would rather no increase the instruction struct size.
It is a very common structure, which responsible for a large part
of the byte code memory usage. There is only one person
(David) can benefit from it so far.
I think what David need is just distinction of int vs pointer.
We can do that by save an array of the known basic types.
Including the abstract pointer type. Then we just use an
index to the array rather than use the raw size directly.
That have the extra benefit of, different architecture can share
the same byte code.
Chris
On Sun, Dec 14, 2008 at 4:26 PM, Alexey Zaytsev
<alexey.zaytsev@gmail.com> wrote:
> From: David Given <dg@cowlark.com>
>
> Currently there is no generic way to derive phy
> type information from the instruction flow.
> ---
> linearize.c | 4 +++-
> linearize.h | 1 +
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/linearize.c b/linearize.c
> index fce1ae8..526a710 100644
> --- a/linearize.c
> +++ b/linearize.c
> @@ -55,7 +55,9 @@ static inline int type_size(struct symbol *type)
>
> static struct instruction *alloc_typed_instruction(int opcode, struct symbol *type)
> {
> - return alloc_instruction(opcode, type_size(type));
> + struct instruction *insn = alloc_instruction(opcode, type_size(type));
> + insn->type = type;
> + return insn;
> }
>
> static struct entrypoint *alloc_entrypoint(void)
> diff --git a/linearize.h b/linearize.h
> index 32b1c1a..0c5e4ef 100644
> --- a/linearize.h
> +++ b/linearize.h
> @@ -71,6 +71,7 @@ struct instruction {
> size:24;
> struct basic_block *bb;
> struct position pos;
> + struct symbol *type;
> union {
> pseudo_t target;
> pseudo_t cond; /* for branch and switch */
>
>
next prev parent reply other threads:[~2008-12-23 3:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-15 0:25 [PATCH 00/15] Trivial sparse patches Alexey Zaytsev
2008-12-15 0:25 ` [PATCH 01/15] Evaluate iterator symbols Alexey Zaytsev
2008-12-15 0:26 ` [PATCH 02/15] Unhardcode byte size being 8 bits Alexey Zaytsev
2008-12-15 0:26 ` [PATCH 03/15] Add type information to struct instruction Alexey Zaytsev
2008-12-23 3:21 ` Christopher Li [this message]
2008-12-23 4:46 ` Alexey Zaytsev
2008-12-23 5:38 ` Christopher Li
2008-12-23 11:23 ` David Given
2008-12-24 3:09 ` Christopher Li
2008-12-24 23:01 ` David Given
2008-12-24 23:27 ` Christopher Li
2008-12-24 4:53 ` Alexey Zaytsev
2008-12-15 0:26 ` [PATCH 04/15] Replace the -specs cgcc option with -target Alexey Zaytsev
2008-12-15 0:26 ` [PATCH 05/15] Remove pre_buffer Alexey Zaytsev
2008-12-15 0:26 ` [PATCH 06/15] Sparc64 (Sparc V9, LP64) support Alexey Zaytsev
2008-12-15 0:26 ` [PATCH 07/15] OpenBSD support Alexey Zaytsev
2008-12-15 0:26 ` [PATCH 08/15] Make show_symbol newline-consistent Alexey Zaytsev
2008-12-15 0:27 ` [PATCH 09/15] Handle a terminal -o option properly Alexey Zaytsev
2008-12-15 0:27 ` [PATCH 10/15] Looks more evident this way Alexey Zaytsev
2008-12-15 0:27 ` [PATCH 11/15] Mark handle_switch as static and don't export it from lib.h Alexey Zaytsev
2008-12-15 0:27 ` [PATCH 12/15] Handle missing argument to -D Alexey Zaytsev
2008-12-15 0:27 ` [PATCH 13/15] Gdb macros to get a better look at some sparse data structures Alexey Zaytsev
2008-12-15 0:27 ` [PATCH 14/15] A slightly edited irc discussion with Josh Triplett Alexey Zaytsev
2008-12-15 0:27 ` [PATCH 15/15] Warning should be enough for an unhandled transparent union Alexey Zaytsev
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=70318cbf0812221921q5e53a8edhad06369537dc3a6c@mail.gmail.com \
--to=sparse@chrisli.org \
--cc=alexey.zaytsev@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=dg@cowlark.com \
--cc=josh@kernel.org \
--cc=linux-sparse@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;
as well as URLs for NNTP newsgroup(s).