linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 21:38:05 -0800	[thread overview]
Message-ID: <70318cbf0812222138v3c62cd97u11690694655bec72@mail.gmail.com> (raw)
In-Reply-To: <f19298770812222046l305f1a30ne8fa554d8cb8772e@mail.gmail.com>

On Mon, Dec 22, 2008 at 8:46 PM, Alexey Zaytsev
<alexey.zaytsev@gmail.com> wrote:
> Are you sre this is worth the effort (and code complication)? Struct
> instruction is not exactly a tiny one, and a pointer would bloat it
> by about 10%. On the other hand, I don't really unerstand why

That complexity is needed for the back end to generated C
code any way. Currently, if you save the full C type into instruction.
The back end needs to look into the C type and determinate which
native machine type it should use.

While if you do that up front, the back end side will have a simple
1 to 1 mapping. It will make David's back end code simpler.

On my machine(64 bit). It jump from 56 to 64.  That is 14%.

> the type information is associated with the instructions, and not
> with the pseudos. Am I missing something?

If you have it in the pseudos, the instruction size will depend on
the type of the instruction. There is no universal pseudo member
can be access for all the instruction types. One instruction
can have more than one pseudo, so you are likely to increase the
over all size.

>> That have the extra benefit of, different architecture can share
>> the same byte code.
> Didn't understand this comment.

I am thinking that, if you dump the byte code into file. Then
different back end will need to have different byte code binary,
because difference in the basic type size.

I just realized that because we store the sizeof operation into
binary values, so they are going to have different binary any way.
So this does not matter.

Chris

  reply	other threads:[~2008-12-23  5:38 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
2008-12-23  4:46     ` Alexey Zaytsev
2008-12-23  5:38       ` Christopher Li [this message]
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=70318cbf0812222138v3c62cd97u11690694655bec72@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).