All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Given <dg@cowlark.com>
To: linux-sparse@vger.kernel.org
Subject: Re: Writing compilers, and example.c vs compile-i386.c
Date: Wed, 18 Jun 2008 00:35:15 +0100	[thread overview]
Message-ID: <48584A33.7080602@cowlark.com> (raw)
In-Reply-To: <70318cbf0806161749u543fa338sf43a2ab787297eaa@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

Mike Frysinger wrote:
> this may be worth investigating as well:
> http://pcc.ludd.ltu.se/

That was actually where I started; it works pretty well, though after a
couple of hours of examining the code I realised that there was a good
reason why it looked like code that had been written 25 years ago and
then randomly hacked ever since. It's a little opaque, which is why I
ended up here.

Christopher Li wrote:
[...]
> 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.

Yes, that's what I suspected --- being the more complicated file! Oh,
well, I've been examining it, and it's slow beginning to make sense.

However: I notice that the code seems to make use of OP_DEATHNOTE
instructions to mark hardregs as being dead. However, these are only
generated if track_pseudo_death(ep) is called --- and example.c never
calls this. It *is*, however, called if -vdead is specified on the
command line. Is this a bug in example.c or am I just misunderstanding
things?

(Also, the OP_DEATHNOTE instructions appear to occur *before* the
instruction that uses them last --- is this so that the instruction can
reuse the register is the code generator sees fit to do so?)

(In addition, I notice that once liveness tracking has been done phisrc
nodes get annotated with the desired shared register that the phi should
occupy; suddenly, the phi stuff all makes sense.)



(PS. Please don't cc me if you're also mailing the list --- I only need
one copy!)

-- 
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

  reply	other threads:[~2008-06-17 23:35 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
2008-06-17 23:35   ` David Given [this message]
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=48584A33.7080602@cowlark.com \
    --to=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 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.