All,
Chris Lattner and I had a recent discussion about merging the HLVM
(http://hlvm.org/) and LLVM (http://llvm.org/) projects. We agreed in
principle and the merging of the two projects will now commence.
This merger makes sense for both projects. LLVM needs to expand into
the realm of front end tool kits. HLVM provides LLVM with some initial
front-end capabilities. Since HLVM uses LLVM and LLVM's design
philosophy, there is little disparity between the two projects. The
merger makes sense for HLVM because it joins the two development
communities and provides resources to HLVM that are not otherwise
available. Both projects have common goals, design philosophies,
implementation languages, and etc. In other words, its a natural fit.
After the merging of the two projects, HLVM will be a sub-project of
LLVM (like llvm-gcc, llvm-java, llvm-tv, etc.) with its own SVN
repository module. Its purpose is to provide the necessary tool kits
(mainly a pluggable Abstract Syntax Tree) to make it easy to create
front end languages that target LLVM. It also aims to abstract out
common things that all front end language compilers (e.g. a compiler
driver, common AST nodes, translation of AST to LLVM IR, etc.). It is
our anticipation that HLVM will become the predominant tool kit for
building compilers that target the LLVM IR and its optimization and code
generation facilities.
For GSoC applicants, the merger of HLVM and LLVM means that your
proposal may also include work done on HLVM instead of just LLVM. So, if
you want to implement a language or assist in the construction of the
AST, those kinds of projects will be accepted now under LLVM's
"mentoring organization".
The work to merge the projects will start shortly. Over the coming weeks
and months you can expect to see the following changes:
1. HLVM's license is changed from LGPL to UI Open Source License.
2. HLVM web site integrates with LLVM's (and vice versa).
3. HLVM code repository migrates to the LLVM Subversion repository
(when it becomes available).
4. HLVM's build system (scons based) gets improved enough to handle
LLVM's build needs. Depending on how well that works, an scons
based build system may be in LLVM's future.
5. HLVM's modularity is improved so that it is not so focused on an
all-encompassing virtual machine and clearly separates the front
end tool kit from the virtual machine (runtime). In fact, the
runtime/VM portion of HLVM may become a separate LLVM
sub-project at some point.
Both Chris and I believe that this integration is in the best interest
of both projects and we hope that you also agree. If you have any
questions or concerns, please direct them to me or this list.
Best Regards,
Reid Spencer
