Hi,
I’m planning to apply for SoC and I would like some hints on which projects the community are most interested in.
The two projects that I right now think looks most interesting is:
and
What do you think, would any of these two make a good SoC project?
To me, GVN-PRE and a MIPS backend would be the most useful ones. Do you have MIPS hardware to test on? If not, a GVNPRE pass might be better, though you could do the port with a good simulator. Daniel Berlin knows much about GVNPRE, so he could probably comment more on it.
-Chris
To me, GVN-PRE and a MIPS backend would be the most useful ones. Do you
have MIPS hardware to test on? If not, a GVNPRE pass might be better,
though you could do the port with a good simulator. Daniel Berlin knows
much about GVNPRE, so he could probably comment more on it.
I implemented GVN-PRE for GCC. You could probably do an implementation
for LLVM in three months, assuming you are somewhat familiar with SSA
form 
I'd also be happy to mentor such a project.
If you're thinking of doing a backend, the LLVM project would probably
benefit more from implementing the virtual backend and its
Interpreter/JIT. This is a long standing project that could dramatically
increase the performance of the ExecutionEngine. The idea is to write a
backend for a virtual machine that closely matches the semantics of LLVM
and then implement the virtual machine.
But, MIPS sounds cool too
Reid
Hi Reid,
If you're thinking of doing a backend, the LLVM project would probably
benefit more from implementing the virtual backend and its
Interpreter/JIT. This is a long standing project that could
dramatically increase the performance of the ExecutionEngine. The idea
is to write a backend for a virtual machine that closely matches the
semantics of LLVM and then implement the virtual machine.
I've seen this mentioned before. What's the advantage of this over
JITting to the host CPU ISA? It would seem to be adding another layer
since presumably you'd want to have JIT in the VM for the LLVM.
Cheers,
Ralph.
There is none. This is to improve the interpreter.
The interpreter currently has two problems:
1. It's really slow (which Reid's comment addresses). This is because the
interpreter was hacked together very quickly with little thought or
desire to be efficient. Each register access requires multiple
std::map lookups, for example.
2. The interpreter has no Foreign Function Interface, which means that it
is extremely limited when calling external functions that are not in
LLVM bytecode form. In practice, this prevents the interpreter from
running *many* programs.
Progress on either would be good, but personally I don't consider the interpreter to be very high priority (particularly when a full port of the LLVM code generator is often 4-5000 lines of code).
-Chris
This would work on systems we don't support or the backend doesn't
support JITing. For example, let's say you wanted to run some bytecode
on MIPS.
Andrew
It doesn't make much difference to the JIT. The LLVM bytecode would be
translated (and optimized) to the native ISA as per any other backend.
That doesn't really change. The advantages are these:
1. When the program is run on a machine for which native JIT is not
available, interpretation is the only solution. Right now LLVM
interprets the LLVM IR directly. This makes it really bulky memory wise
and less than efficient. A simpler VM that had its own instruction set
could be more readily executed (basically mmap a file and start
interpreting, no bytecode unpackaging, no C++ IR to create).
2. Such a VM could store its generated VISC on disk in a readily
loadable form so that the bytecode -> executable translation need only
be done once, not on every execution.
3. the virtual ISA could become an alternative "byte code" whereby all
compilation and optimization is done ahead of time with the usual suite
of LLVM tools but the result would be runnable anywhere the VM was
implemented.
REid.
To me, GVN-PRE and a MIPS backend would be the most useful ones. Do you
have MIPS hardware to test on? If not, a GVNPRE pass might be better,
though you could do the port with a good simulator. Daniel Berlin knows
much about GVNPRE, so he could probably comment more on it.I implemented GVN-PRE for GCC. You could probably do an implementation
for LLVM in three months, assuming you are somewhat familiar with SSA
form
SSA should not be a problem. I have skimmed through Thomas VanDrunens PhD dissertation and it seems doable to implement it in three month…
I’d also be happy to mentor such a project.
Cool, I guess I have to start writing my proposal then