Status of Elsa->LLVM

[Richard_Pennington1]

I'm a little further along now. I've started to put together a simple driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think it works).

The file being compiled is a "printf" function. Here are timing results for optimized and unoptimized runs:

[~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions
Adding test/ofmt.i as a preprocessed C file
Phase: Preprocessing
   test/ofmt.i is ignored during this phase
Phase: Translation
   compile test/ofmt.i to become an unoptimized LLVM bitcode file
typechecking results:
   errors: 0
   warnings: 0
Phase: Optimization
   optimize ofmt.bc to become an LLVM bitcode file
Phase: Bitcode linking
   bclink ofmt.bc to become a file that has been linked
Phase: Bitcode assembly
   ofmt.bc is ignored during this phase
Phase: Assembly
   ofmt.bc is ignored during this phase
Phase: Linking
   ofmt.bc is ignored during this phase

[Daniel_Wilkerson]

I'm a little further along now. I've started to put together a simple
driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think
it works).

Er. Hm. Can you explain the name? The problem with names like
"ellsif" is that it sounds like "else if". I like the fact that it
reminds one of Elsa.

[~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions -std-compile-opts

Ok, this indicates that you are developing your compiler in the elsa
directory. As I have said before, this is not going to work as Scott
wants elsa to be "done". Oink was invented as a bucket to put elsa
tools into and that is the best place for it. I suppose you might
convince Scott otherwise but I doubt it and for now I am the
maintainer.

Adding test/ofmt.i as a preprocessed C file
Phase: Preprocessing
   test/ofmt.i is ignored during this phase

What preprocessor are you using? Taras has already found one that is
working for him and that is licensed under BSD and that has some
features in it that he needs for source to source transformation. I
would like us to all use the same one.

Sorry to add noise to the list with this. I'm just very excited.
Again, my compliments to both the Elsa and LLVM teams. It says a lot
that I got this far in 19 days of part-time work.

Excitement is good and I don't mind the email at all.

Please however do respond to some of my concerns.

Daniel

[Taras_Glek1]

Adding test/ofmt.i as a preprocessed C file
Phase: Preprocessing
   test/ofmt.i is ignored during this phase
    
What preprocessor are you using? Taras has already found one that is
working for him and that is licensed under BSD and that has some
features in it that he needs for source to source transformation. I
would like us to all use the same one.
  

I'd like to clarify my intentions here.
I designed the preprocessor integration in such a way that it doesn't depend on the specific preprocessor too much. MCPP is nice in that it's BSD, but it's rather slow, so no need to require people to use it.
Users can implement the undo-log preprocessor using libcpp or maybe yank it out of clang which is also BSD.

Taras

[Daniel_Wilkerson]

I would really like to avoid shipping multiple preprocessors as part
of the standard elsa/oink project.

[Richard_Pennington1]

Daniel Wilkerson wrote:

I'm a little further along now. I've started to put together a simple
driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think
it works).

Er. Hm. Can you explain the name? The problem with names like
"ellsif" is that it sounds like "else if". I like the fact that it
reminds one of Elsa.

It does sound like "elsif". By design. I wanted to remind people of Elsa and also of LLVM, hence the "ll". Maybe you could read it as something like "if gcc else if ellsif".

[~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions -std-compile-opts

Ok, this indicates that you are developing your compiler in the elsa
directory. As I have said before, this is not going to work as Scott
wants elsa to be "done". Oink was invented as a bucket to put elsa
tools into and that is the best place for it. I suppose you might
convince Scott otherwise but I doubt it and for now I am the
maintainer.

I'm in elsa/ellsif. elsa is in elsa/elsa. I build elsa into a library and link it into ellsif. (Just like else does smbase, etc.)

I'm not sure what "done" means. I've had to touch a lot of areas in Elsa to make this work. I've had to modify the type checker a bit to get standard conversions in places that didn't have them. I added a loc field to expression nodes for debug information and error reporting. etc. etc. It isn't quite done for my purposes.

Sorry if I've broken any rules, but I just found Elsa a month ago and wasn't following its development or the mailing list before that.

Adding test/ofmt.i as a preprocessed C file
Phase: Preprocessing
   test/ofmt.i is ignored during this phase

What preprocessor are you using? Taras has already found one that is
working for him and that is licensed under BSD and that has some
features in it that he needs for source to source transformation. I
would like us to all use the same one.

I'm using the gcc as a preprocessor for now. I plan to drop a preprocessor that I wrote a while ago in sometime next week, if the holidays don't get in the way.

Sorry to add noise to the list with this. I'm just very excited.
Again, my compliments to both the Elsa and LLVM teams. It says a lot
that I got this far in 19 days of part-time work.

Excitement is good and I don't mind the email at all.

Please however do respond to some of my concerns.

I hope I've given some clarification.

By the way, this code is owned by me. I'm not doing on my employer's time or using their resources.

-Rich

[clattner]

I'm a little further along now. I've started to put together a simple
driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think
it works).

The file being compiled is a "printf" function. Here are timing results
for optimized and unoptimized runs:

Cool, this is very nice!

Sorry to add noise to the list with this. I'm just very excited.
Again, my compliments to both the Elsa and LLVM teams. It says a lot
that I got this far in 19 days of part-time work.

This is a very cool hack, but I'm curious: what is your goal with this work? Are you just trying to see if it can be done, or does elsa provide an advantage over using the g++ parser with llvm?

-Chris

[Richard_Pennington1]

Chris Lattner wrote:

I'm a little further along now. I've started to put together a simple
driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think
it works).

The file being compiled is a "printf" function. Here are timing results
for optimized and unoptimized runs:

Cool, this is very nice!

Sorry to add noise to the list with this. I'm just very excited.
Again, my compliments to both the Elsa and LLVM teams. It says a lot
that I got this far in 19 days of part-time work.

This is a very cool hack, but I'm curious: what is your goal with this work? Are you just trying to see if it can be done, or does elsa provide an advantage over using the g++ parser with llvm?

-Chris
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Well, primarily I'm doing it for fun.

My background is in compiler design and embedded systems programming, so I'm interested in both the front end and back end aspects.

I've build gcc many times over the years for different target processors and was never able to get my head around it internally. It is incredibly complex. I also didn't like the fact that I had to have N copies of gcc to support N processors.

I became interested in Elsa (via google) because I liked its extensible nature. I can drop in new syntax rules easily. It was also fairly easy to understand.

At first I looked into SUIF and started down that path. I wasn't entirely pleased with the results. Then I realized SUIF had been dead for about 5 years so I started looking around for alternatives and stumbled on LLVM.

It was easy to lower the Elsa AST to LLVM by using Elsa's extension capability.

I'm now at the point where I can see that compiling C with Elsa is a done deal. I have about 90% (or more) of basic C covered.

I decided that I wanted a cleaner way to move forward so I started writing the ellsif driver to automate the steps and make Elsa->LLVM look like a real tool.

Does Elsa provide an advantage over g++? For me, understanding it is a big plus. In addition, Elsa has a Berkeley-like license which I prefer.

I'll let you know if Elsa is a good choice after I get a little further along adding the C++ support.

Since I only have a few weeks invested in this project, I won't feel too bad if Elsa turns out to be a dead end. Along the way I found LLVM, which is definitely the way to go.

I'd like to get the Elsa stuff behind me because I'm itching to do an LLVM code generator for the Altera Nios2. I started by copying the MIPS sources and am studying them to get a feel for what's required.

-Rich

[clattner]

Does Elsa provide an advantage over g++? For me, understanding it is a
big plus. In addition, Elsa has a Berkeley-like license which I prefer.

Ok. If you're not planning on extending the front-end, understandability doesn't really matter ;-). I get where you're coming from though!

Since I only have a few weeks invested in this project, I won't feel too
bad if Elsa turns out to be a dead end. Along the way I found LLVM,
which is definitely the way to go.

Ok. For most users to be interested in it, it would have to be faster or produce better code, and be as correct as G++. I'll be interested to see how it comes out.

I'd like to get the Elsa stuff behind me because I'm itching to do an
LLVM code generator for the Altera Nios2. I started by copying the
MIPS sources and am studying them to get a feel for what's required.

Ah, nifty. I no nothing of that processor, but you can build a backend independent of the front-end

-Chris

[Daniel_Wilkerson]

I've build gcc many times over the years for different target processors
and was never able to get my head around it internally. It is incredibly
complex. I also didn't like the fact that I had to have N copies of gcc
to support N processors.

Scott McPeak is rather familiar with the internals of gcc and edg and
says elsa is far simpler.

I became interested in Elsa (via google) because I liked its extensible
nature. I can drop in new syntax rules easily. It was also fairly easy
to understand.

We worked very hard to make it that way just so people like you can do
what you are doing :-).

It was easy to lower the Elsa AST to LLVM by using Elsa's extension
capability.

I'll be pretty interested to see how you did that.

Does Elsa provide an advantage over g++? For me, understanding it is a
big plus. In addition, Elsa has a Berkeley-like license which I prefer.

Read it more carefully: the license is not just BSD-like, it *is* BSD!

I'll let you know if Elsa is a good choice after I get a little further
along adding the C++ support.

Since I only have a few weeks invested in this project, I won't feel too
bad if Elsa turns out to be a dead end.

Would you mind explaining what a dead-end would look like?

I'd like to get the Elsa stuff behind me because I'm itching to do an
LLVM code generator for the Altera Nios2. I started by copying the
MIPS sources and am studying them to get a feel for what's required.

In other words you want a C++ compiler for the Nois2?

Daniel

[Richard_Pennington1]

Daniel Wilkerson wrote:

I've build gcc many times over the years for different target processors
and was never able to get my head around it internally. It is incredibly
complex. I also didn't like the fact that I had to have N copies of gcc
to support N processors.

Scott McPeak is rather familiar with the internals of gcc and edg and
says elsa is far simpler.

I agree, very much.

I became interested in Elsa (via google) because I liked its extensible
nature. I can drop in new syntax rules easily. It was also fairly easy
to understand.

We worked very hard to make it that way just so people like you can do
what you are doing :-).

You guys did a great job!

It was easy to lower the Elsa AST to LLVM by using Elsa's extension
capability.

I'll be pretty interested to see how you did that.

You'll see it soon. But basically think about cc2c. There is now a cc2llvm.

Does Elsa provide an advantage over g++? For me, understanding it is a
big plus. In addition, Elsa has a Berkeley-like license which I prefer.

Read it more carefully: the license is not just BSD-like, it *is* BSD!

Yes.

I'll let you know if Elsa is a good choice after I get a little further
along adding the C++ support.

Since I only have a few weeks invested in this project, I won't feel too
bad if Elsa turns out to be a dead end.

Would you mind explaining what a dead-end would look like?

A dead end would be something in the C++ part of Elsa that didn't allow me to generate a correct LLVM file to execute it and that I couldn't fix. If I knew what it looked like, I'd look for it first and decide now.

I'd like to get the Elsa stuff behind me because I'm itching to do an
LLVM code generator for the Altera Nios2. I started by copying the
MIPS sources and am studying them to get a feel for what's required.

In other words you want a C++ compiler for the Nois2?

No, g++ exists for the Nios2. Altera has a port. I am interested working with some language stuff that might be cool in an embedded environment.
The Nios is a softcore processor that runs on Altera FPGAs. A programmable processor. Think of what kind of optimizations that might allow.

Daniel

-Rich

[Richard_Pennington1]

Chris Lattner wrote:

Does Elsa provide an advantage over g++? For me, understanding it is a
big plus. In addition, Elsa has a Berkeley-like license which I prefer.

Ok. If you're not planning on extending the front-end, understandability doesn't really matter ;-). I get where you're coming from though!

Since I only have a few weeks invested in this project, I won't feel too
bad if Elsa turns out to be a dead end. Along the way I found LLVM,
which is definitely the way to go.

Ok. For most users to be interested in it, it would have to be faster or produce better code, and be as correct as G++. I'll be interested to see how it comes out.

Me, too.

I'd like to get the Elsa stuff behind me because I'm itching to do an
LLVM code generator for the Altera Nios2. I started by copying the
MIPS sources and am studying them to get a feel for what's required.

Ah, nifty. I no nothing of that processor, but you can build a backend independent of the front-end

The Nios2 is a softcore processor running in Altera FPGAs. Very MIPS like. Being soft, the instruction set can be extended as can the hardware. In software. Very cool.

-Rich

[Daniel_Wilkerson]

Daniel Wilkerson wrote:
>> I've build gcc many times over the years for different target processors
>> and was never able to get my head around it internally. It is incredibly
>> complex. I also didn't like the fact that I had to have N copies of gcc
>> to support N processors.
>
> Scott McPeak is rather familiar with the internals of gcc and edg and
> says elsa is far simpler.

I agree, very much.

Having the entire Abstract Syntax Tree represented in our own language
(astgen) really helps.

>> I became interested in Elsa (via google) because I liked its extensible
>> nature. I can drop in new syntax rules easily. It was also fairly easy
>> to understand.
>
> We worked very hard to make it that way just so people like you can do
> what you are doing :-).

You guys did a great job!

You're welcome.

>> It was easy to lower the Elsa AST to LLVM by using Elsa's extension
>> capability.
>
> I'll be pretty interested to see how you did that.

You'll see it soon. But basically think about cc2c. There is now a cc2llvm.

We did a lot of work to implement C++ as just a "lowering": re-writing
into a simpler version of the language. You would have thought that
Stoustrup would have done that, but no, as far as I can tell he did
not. For example, there are things you can imply in C++ that as far
as I can tell you cannot state explicitly, such as a copy constructor
for an array member. In some places I think we added to C++ just so
we could do this. (I say "I think" because sometimes you do something
and then later throw it out.) Stroustrup did a pretty bad job with
the syntax but we did our best. The C++ spec is a piece of shit in my
opinion (Scott seems to like it) so there is a lower limit on how
clean of a C++ implementation you can do just because the problem you
are solving is not clean in the first place.

>> Does Elsa provide an advantage over g++? For me, understanding it is a
>> big plus. In addition, Elsa has a Berkeley-like license which I prefer.
>
> Read it more carefully: the license is not just BSD-like, it *is* BSD!

Yes.

I have always been wondering what would happen if someone stuck a code
generator onto Elsa; I think Stallman will not be happy :-).

>> I'll let you know if Elsa is a good choice after I get a little further
>> along adding the C++ support.
>>
>> Since I only have a few weeks invested in this project, I won't feel too
>> bad if Elsa turns out to be a dead end.
>
> Would you mind explaining what a dead-end would look like?

A dead end would be something in the C++ part of Elsa that didn't allow
me to generate a correct LLVM file to execute it and that I couldn't
fix. If I knew what it looked like, I'd look for it first and decide
now.

The language implementation is incomplete in that there are exotic
uses of templates that we do not support. However the subset of the
language that we do support should admit of a compilation as far as I
can tell as we tried our best to "lower" the C++ everywhere. Hm, we
never implemented operator new(); oops.

Daniel

[Daniel_Wilkerson]

Chris, I wonder if perhaps you might want to give that sentence more
thought. In order to generate code I am sure you want to do static
analysis of your program and that requires looking at the AST. Scott
says that the gcc internals are very dynamic: this basically means
that there are lots of "if" statements you have to write in order to
traverse the code and figure out what kind of thing you are looking
at. Such data-structures are inefficient and error-prone: the C++
(meta-level) type-checker cannot help you as much. Our internal
data-structures have static fields for each semantic component of an
AST node; they are generated from our own custom Domain Specific
Language for Abstract Syntax Trees. This allows you to automate all
kinds of things and then have the C++ compiler (that compiles your
meta language, which is of course also C++) type-check what you did.

Oh Rich, do you know about LoweredASTVisitor? Have you looked at how
the whole-program data-flow analysis is done in Oink? You really
should give me a call.

Daniel

[David_Mandelin]

Richard Pennington wrote:

Chris Lattner wrote:
  

This is a very cool hack, but I'm curious: what is your goal with this work? Are you just trying to see if it can be done, or does elsa provide an advantage over using the g++ parser with llvm?

-Chris
_______________________________________________
    

[snipped]
I became interested in Elsa (via google) because I liked its extensible nature. I can drop in new syntax rules easily. It was also fairly easy to understand.

[...]
It was easy to lower the Elsa AST to LLVM by using Elsa's extension capability.

I'm now at the point where I can see that compiling C with Elsa is a done deal. I have about 90% (or more) of basic C covered.
  

Looks like I'm late to this discussion, but I wanted to chime in and say this is really cool stuff.

I decided that I wanted a cleaner way to move forward so I started writing the ellsif driver to automate the steps and make Elsa->LLVM look like a real tool.

Does Elsa provide an advantage over g++? For me, understanding it is a big plus. In addition, Elsa has a Berkeley-like license which I prefer.

I'll let you know if Elsa is a good choice after I get a little further along adding the C++ support.
  

From what I've learned so far, Elsa and LLVM are both much closer to a textbook design than gcc or anything like it, so I'd expect them to be much easier to work with and maintain. Hopefully easier to attract developers to as well. (I like Dan's comment about the end of gcc, too.)

Dave
MoCo Platform N00b