From: Nikolaos Kavvadias <nkavv@physics.auth.gr>
To: Christopher Li <sparse@chrisli.org>, linux-sparse@vger.kernel.org
Subject: Re: Backend projects for Sparse
Date: Wed, 28 Nov 2007 21:00:03 +0200 [thread overview]
Message-ID: <474DBAB3.60400@physics.auth.gr> (raw)
In-Reply-To: <70318cbf0711281053k6dc561c5ge540ccd99a6a922e@mail.gmail.com>
Christopher Li wrote:
> It does support SSA from for internal variable(pseudo in
> linearization). Not sure
> what kind of "canonical SSA" do you have in mind.
>
Hi Christopher
first of all, thanks for your specific answers. The SSA form that i
think of uses only PHI functions. Guard variables (conditionals for
selecting a specific usage) may or may not be explicit. Usually, most
SSA forms just specify which uses are merged. The conditionals can be
inferred by control-flow analysis.
>> In my mind a single C program file (actually read: translation unit) would be
>> translated to something like the following structure:
>>
>
> The sparse front end generate list of symbols. Functions is symbol as well.
> So it have one single list of symbols that your back end should care about.
> You need to look into the symbol type to find out this symbol is a function.
> But that is just details.
>
> Inside each function, there is list of symbol access by this functions as well.
> I think it is sym->symbol_list.
>
OK.
>> 4) Is there anyone working on a RISC-like processor backend project. I feel that
>> if the entire backend can be contained in something like "compile-i386.c" then
>> it could be even possible to automate the generation of such file from a more
>> compact specification file. (plus some hand-written intrinsics probably).
>>
>
>
OK, thank you for this one. I'll have a good look to "compile.c".
>> 5) Is there any documentation covering the API and linked tools to the sparse
>> library (something more than the man pages)?
>>
>
> Not that I know of. If you need that much detail to perform the back end work,
> you have to read some source code. I think you can ignore a lot of the parser
> details and focus on the linearized byte code.
>
> sparse.c is another example of using those linearized byte code, it
> only look for
> specific subset in the linearized code though.
>
> Chris
>
Kind regards
Nikolaos Kavvadias
next prev parent reply other threads:[~2007-11-28 19:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-28 9:53 Backend projects for Sparse nkavv
2007-11-28 18:53 ` Christopher Li
2007-11-28 19:00 ` Nikolaos Kavvadias [this message]
2007-11-28 19:25 ` Christopher Li
2007-11-29 9:09 ` nkavv
2007-11-28 19:45 ` Jeff Garzik
2007-11-28 20:27 ` Christopher Li
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=474DBAB3.60400@physics.auth.gr \
--to=nkavv@physics.auth.gr \
--cc=linux-sparse@vger.kernel.org \
--cc=sparse@chrisli.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.