From: "Christopher Li" <sparse@chrisli.org>
To: David Given <dg@cowlark.com>
Cc: linux-sparse@vger.kernel.org
Subject: Re: Writing compilers, and example.c vs compile-i386.c
Date: Mon, 16 Jun 2008 17:49:24 -0700 [thread overview]
Message-ID: <70318cbf0806161749u543fa338sf43a2ab787297eaa@mail.gmail.com> (raw)
In-Reply-To: <4856F196.8020403@cowlark.com>
On Mon, Jun 16, 2008 at 4:04 PM, David Given <dg@cowlark.com> wrote:
> Some basic testing with show_statement() and show_insn() reveals that
> both approaches seem to yield similar but *different* pseudocode... with
> different SSA phi functions. What's the difference between the two, and
> do you have any suggestions as to which approach I should look at?
I would strongly recommend using the example.c rather than compile-i386.c.
If you want to do any thing interesting with the back end at all, using
the linearize byte code is the way to go.
> In addition, I'm afraid I'm going to have to use the D word... has
> anyone written down anything about how all this stuff works? I'm afraid
> it's rather a large mass of code to try and absorb in one go, and any
> overview information would help me considerably. For example: if I put
> together a noddy program that enumerates basic blocks (the example.c
> approach) I see phi functions. Calling unssa() doesn't seem to help.
> However, inserting instrumentation into example.c indicates that it
> *doesn't* see phi functions (as far as I can tell). There's something
> I'm simply not getting here --- does the removal of phis actually happen
> inside the register allocator (which seems like the intuitive place for
> it), and if so, what does unssa() actually do?
I haven't use the unssa() myself. It seems unssa() just replace the
phisrc instruction to a copy instruction. Let the source copy to a
temp register. Then on phi instruction it just copy that temp register
back to the phi node register.
The phi node is replaces with copy instruction inside unssa().
In the real machine code, the copy instruction can emit as "mov"
instruction.
As for linearize instructions. They are the internal representation
of the compiled program. In this representation, there is unlimited
pseudo register. Each pseudo is define in only one instruction. except
"OP_COPY" in the unssa().
Each function entry point has a list of basic blocks and each basic block
has a list of instructions. Most instruction is pretty straight for what
it does.
BTW, if you don't mind coding in C++, you can take a look at LLVM.
Chris
next prev parent reply other threads:[~2008-06-17 0:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-16 23:04 Writing compilers, and example.c vs compile-i386.c David Given
2008-06-16 23:50 ` Mike Frysinger
2008-06-17 0:49 ` Christopher Li [this message]
2008-06-17 23:35 ` David Given
2008-06-18 0:41 ` Christopher Li
2008-06-20 23:46 ` David Given
2008-06-21 1:40 ` Christopher Li
2008-06-24 13:29 ` David Given
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=70318cbf0806161749u543fa338sf43a2ab787297eaa@mail.gmail.com \
--to=sparse@chrisli.org \
--cc=dg@cowlark.com \
--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).