GSoC project questions.

Hello everyone, I have a couple of questions about good project ideas for GSoC because I’m kind of stuck thinking what I should do.

First of all, allow me to introduce myself - I’m Alex Lorenz, a Comp Sci student from Ireland. I would like to participate in GSoC this year, and I would love to do something for LLVM, because it’s a great project. I am familiar with LLVM api, as last year I wrote a compiler(for fun/education) for my own language which used LLVM as a backend. I have a good experience with C++(started self taught, more than 5 years ago), and I have used it in several freelance projects and many of my own.

However, I am not sure what my project should be. It would be interesting to work on optimizations and/or code generation for LLVM, but I have no idea what a good project for that would be. The Open Projects page mentioned LLVM Superoptimizer, so would this be a viable project that would benefit LLVM? It also mentions writing a frontend for another language, and I think this would be a really good project, but there are so many languages that I’m not sure which one to choose - perhaps Go or maybe even http://magpie-lang.org/?

Another idea that I had for the project would be live editing/compilation - probably for C/C++. The application is compiled using clang and ran with an injected initialization code. Then, when a source file is modified, a filesystem watcher or an IDE plugin notices this change. After that a diff is performed on the file and clang is used(somehow) to see if this edit can be injectected into the running application - basically it checks if the edit is inside a non-inlined non-lamba function(s). The code that was injected at the initialization of the application started an IPC thread to communicate with the hypervisor which does the modification watch and file diff. After the diff the hypervisor uses clang and LLVM to compile the modified function(s) with relative addressing and sends it to the application IPC thread which copies the instructions into memory which is then marked as executable. The application also receives addresses of the modified functions which are somehow obtained from the initial compilation. Then the IPC thread pauses all other threads in this process and writes a jump to new address at the start of each modified function. It sounds quite complicated and ambitious, and I’m not sure if it really can be done, so maybe someone can correct me?

I’m open to any other suggestions as well, so if you have any please post them.
Thanks in advance.

Hi,

2013/4/12 Matthieu Brucher <matthieu.brucher@gmail.com>

Hi,

I had a quick read through the Fortran 90 specification, and I must say I would be able to write a frontend for it, although arrays and io would make it harder. But isn’t Fortran already supported with dragonegg?

I had a quick read through the Fortran 90 specification, and I must say I
would be able to write a frontend for it, although arrays and io would make
it harder. But isn't Fortran already supported with dragonegg?

Indeed, dragonegg supports Fortran, but through a gfortran bridge. The
really interesting part in Fortran is in fact arrays!

Anyway, it's just my opinion, I'm a simple user :wink:

Indeed, dragonegg supports Fortran, but through a gfortran bridge. The
really interesting part in Fortran is in fact arrays!

Anyway, it's just my opinion, I'm a simple user :wink:

Fortran has its own standard library and it's damn big. Also, the
Fortran grammar is not the simplest (or, rather - straightforward
one). So this certainly looks too big for GSoC.

Though, it might be a good start for someone.

I believe Bill (CCed) started something few years ago. So, maybe he
can share his thoughts on this project.

I always liked the sound of ‘flang’ :slight_smile:

I’m curious, what benefits would we see from a “native” Fortran compiler for LLVM versus DragonEgg, assuming we’d still need the gfortran standard library anyway (in the short-medium term)? Or put another way, is there Fortran code out there we optimize poorly because of using DragonEgg? I haven’t used DragonEgg much, so if this is obvious I apologize.

Just a stab here and not basing it upon any recent exposure as a Mechanical Engineer and CS graduate with FORTRAN 90/03 but I have always perceived DragonEgg as transitional bridge solution and not an end solution for languages LLVM/Clang presently or in the future have yet to support directly within their infrastructure.

Personally, the sooner I don't have to have the GCC infrastructure to run FreeBSD, Debian Linux or any other platform the better. It's not a dig at GCC, it's a dig at bloat. Having a robust FORTRAN library that is always a must in Numerical Analysis preludes often an equivalent robustness in equivalent C/C++ libraries, though never at an exact level of precision.

Not to mention I would suspect the likes of ANSYS, MatLab, Mathematica, etc., would be rather pleased to port their applications across OS X, Windows, UNIX [Linux/FreeBSD] knowing LLVM/Clang/Flang isn't entangled with GPL licensing issues.

- Sincerely,

Marc J. Driftmeyer

From: "Anton Korobeynikov" <anton@korobeynikov.info>
To: "Matthieu Brucher" <matthieu.brucher@gmail.com>
Cc: "Bill Wendling" <isanbard@gmail.com>, "LLVM Developers Mailing List" <llvmdev@cs.uiuc.edu>
Sent: Friday, April 12, 2013 9:04:22 AM
Subject: Re: [LLVMdev] GSoC project questions.

> Indeed, dragonegg supports Fortran, but through a gfortran bridge.
> The
> really interesting part in Fortran is in fact arrays!
>
> Anyway, it's just my opinion, I'm a simple user :wink:
Fortran has its own standard library and it's damn big. Also, the
Fortran grammar is not the simplest (or, rather - straightforward
one). So this certainly looks too big for GSoC.

Though, it might be a good start for someone.

I believe Bill (CCed) started something few years ago. So, maybe he
can share his thoughts on this project.

FWIW, I also started working on a Fortran frontend (derived from Clang, but mostly just to piggyback on the Driver and CPP infrastructure).
https://github.com/hfinkel/lfort

If you're interested in contributing, that would be great. Nevertheless, I think that Anton is right. Creating a quality Fortran compiler is a community effort, and seems too big for a GSoC project. Perhaps we could identify some separately-useful component.

-Hal

Hi,

I agree that creating a complete Fortran compiler is a huge effort.

But what about approaching it from a test driven development perspective?

We start with a few small Fortran programs as “test cases”.

The GSoC task then gives the task as getting test case 1 to work.

We could also apply this of “lfort”. Determine a test case that currently fails on lfort, and ask the GSoC task to pass the test.

Kind Regards

James

I agree that creating a complete Fortran compiler is a huge effort.
But what about approaching it from a test driven development perspective?
We start with a few small Fortran programs as "test cases".
The GSoC task then gives the task as getting test case 1 to work.
We could also apply this of "lfort". Determine a test case that currently
fails on lfort, and ask the GSoC task to pass the test.

All this make sense only if there is interested party in long-term
development and maintenance. Otherwise the code will bitrot really
quickly and thus will be waste of time and money. Is there such a
party?

From: "Anton Korobeynikov" <anton@korobeynikov.info>
To: "James Courtier-Dutton" <james.dutton@gmail.com>
Cc: "Hal Finkel" <hfinkel@anl.gov>, "Bill Wendling" <isanbard@gmail.com>, "LLVM Developers Mailing List"
<llvmdev@cs.uiuc.edu>
Sent: Saturday, April 13, 2013 9:12:39 AM
Subject: Re: [LLVMdev] GSoC project questions.

> I agree that creating a complete Fortran compiler is a huge effort.
> But what about approaching it from a test driven development
> perspective?
> We start with a few small Fortran programs as "test cases".
> The GSoC task then gives the task as getting test case 1 to work.
> We could also apply this of "lfort". Determine a test case that
> currently
> fails on lfort, and ask the GSoC task to pass the test.
All this make sense only if there is interested party in long-term
development and maintenance. Otherwise the code will bitrot really
quickly and thus will be waste of time and money. Is there such a
party?

I am certainly interested in long-term development and maintenance. I think that the first step toward making a useful Fortran compiler is this:

1. It should be able to compile BLAS: http://www.netlib.org/blas/ (these are Fortran 77, and have no I/O, so should be relatively simple)

2. If that is complete, then move on to LAPACK: http://www.netlib.org/lapack/index.html (these use some subset of Fortran 90)

As you can see from the test cases currently in lfort, most of the driver functionality and lexical analysis (for both Fortran 77 and 90) is done, and I've started on parsing (and semantic analysis and codegen for) variable declarations and some simple statements. I think that a motivated student could make a lot of headway, and should be able to at least finish step 1. Thoughts?

-Hal

Thanks for your replies.
Working on the lfort compiler would certainly be an interesting project for me for this GSoC. I have studied lfort repository and commits, and I see that it has a lot of stuff for C/C++, am I correct that this is a fork of Clang? If this is correct, I wonder why this approach was chosen instead of starting out from scratch - is it because Clang already has a lot of code which can be reused for the Fortran compiler? I’m also unfamiliar with Clang and I was a bit overwhelmed when I saw the lfort repository at first because of this. If I were to work on this project, would I be required to use the Clang code?

From: "Alex L" <arphaman@gmail.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Anton Korobeynikov" <anton@korobeynikov.info>, "Bill Wendling" <isanbard@gmail.com>, "LLVM Developers Mailing
List" <llvmdev@cs.uiuc.edu>
Sent: Saturday, April 13, 2013 11:34:43 AM
Subject: Re: [LLVMdev] GSoC project questions.

Thanks for your replies.
Working on the lfort compiler would certainly be an interesting
project for me for this GSoC.

Great!

I have studied lfort repository and
commits, and I see that it has a lot of stuff for C/C++, am I
correct that this is a fork of Clang? If this is correct, I wonder
why this approach was chosen instead of starting out from scratch -
is it because Clang already has a lot of code which can be reused
for the Fortran compiler?

Yes, lfort started out as a fork of Clang, but I don't think that is overly relevant at this point. There are a few things from Clang that the Fortran compiler could really reuse:

1. The driver/tools infrastructure (the code that finds the system libraries, knows how to call the assembler, linker, etc.)
2. The C preprocessor (in practice, a lot of Fortran code assumes the existence of an integrated C preprocessor).
   2a. The lexical analysis framework, and to some extent, the classes for printing nice error messages
3. The directory layout and regression-testing setup

At this point, I've pretty much finished taking advantage of all of those pieces in lfort, and the remainder of the core code from Clang needs to be replaced with Fortran-specific bits. Keeping the same general design probably makes sense, but I could certainly be convinced otherwise.

I'm also unfamiliar with Clang and I was a
bit overwhelmed when I saw the lfort repository at first because of
this. If I were to work on this project, would I be required to use
the Clang code?

No. I think that you might want to use Clang for inspiration on design, but you'd certainly not be bound to that. If you'd like to take a much more start-from-scratch approach, you can also look at the code that Bill put together: https://github.com/isanbard/flang - If you use that as a base, we can always merge it with the useful lfort pieces later.

Thanks again,
Hal

No. I think that you might want to use Clang for inspiration on design, but you’d certainly not be bound to that. If you’d like to take a much more start-from-scratch approach, you can also look at the code that Bill put together: https://github.com/isanbard/flang - If you use that as a base, we can always merge it with the useful lfort pieces later.

Ok, that’s good to know. In the next couple of days I will study the lfort repository more, and see if I can perhaps contribute a commit or two. Thankfully I know git and github and so that would make lfort really accessible for me.

For what it's worth, I concur. It is a massive undertaking to support a full language. The flang code is here:

  https://github.com/isanbard/flang

I haven't had time to work on it recently. And there are many things that I'd like to fix in there. It might be good to look at lfort and flang and see what can be shared between the two. :slight_smile:

-bw

Justin Holewinski <justin.holewinski@gmail.com> writes:

I always liked the sound of 'flang' :slight_smile:

I had planned to name it "flange" (Fortran LANGuage Environment) since
for Fortran you need way more than just a compiler. :slight_smile: You need an
entire set of complicated libraries and runtime.

                            -David

Hi again,

I was studying and building the lfort repository as I said I would do, but after a while I decided that I would like to work on flang instead.

So, I forked flang and so far I’ve had pretty good success with it, here’s what I’ve done:

  • Merged a pull request from a github user Michael Gottesman(He added support for latest llvm and cmake)

  • Fixed character literal continuation bug.

  • Implemented INCLUDE statement (Only searches for files in -I dirs now)

  • Implemented if-stmt(not the full if-construct yet).

You can see my repository here: https://github.com/hyp/flang

So far I’ve enjoyed working on flang, and I would like to apply to GSoC with it. I will start writing a proposal in the next couple of days. Should I send it to the mailing list first, or should I send it directly to GSoC?

Thanks.

Alex,

Please follow the guidelines listed at
https://google-melange.appspot.com/gsoc/org/google/gsoc2013/llvm

:slight_smile:

From: "Alex L" <arphaman@gmail.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Anton Korobeynikov" <anton@korobeynikov.info>, "Bill Wendling" <isanbard@gmail.com>, "LLVM Developers Mailing
List" <llvmdev@cs.uiuc.edu>
Sent: Friday, April 19, 2013 12:17:16 PM
Subject: Re: [LLVMdev] GSoC project questions.
Hi again,

I was studying and building the lfort repository as I said I would
do, but after a while I decided that I would like to work on flang
instead.
So, I forked flang and so far I've had pretty good success with it,
here's what I've done:
- Merged a pull request from a github user Michael Gottesman(He added
support for latest llvm and cmake)
- Fixed character literal continuation bug.
- Implemented INCLUDE statement (Only searches for files in -I dirs
now)
- Implemented if-stmt(not the full if-construct yet).
You can see my repository here: https://github.com/hyp/flang

So far I've enjoyed working on flang, and I would like to apply to
GSoC with it.

Okay, great! As Anton said, see the web site. Also, I'll be happy to help with defining specific project goals, etc. and I'll be happy to mentor (and make sure that this turns into something long-term).

-Hal

And I'll be happy to answer any questions you may have about the flang code base. :slight_smile:

-bw