LLVM and HLVM
John Siracusa
It seems to be making a lot of progress lately with the support of Apple
(which is using LLVM for its own purposes in Mac OS X). Is there anything
there Parrot can steal? Would it make sense for Parrot to target LLVM
bytecode and let LLVM do further optimization and native code generation?
There's also the predictably named HLVM:
which looks vaguely Parrot-ish. Check out the comparison chart:
Anyway, I'm just thinking out loud, here. Sorry if it's all old news to the
Parrot dev gurus.
-John
Peter Baylies
Yes, actually, I was looking at it just the other day. I couldn't get it to
build on x86-64, but I talked to some of the developers over in their IRC
channel, and they told me that this would be forthcoming (in two weeks or
so), so I'm going to hold off for a while and then try it then.
On the other hand, Parrot built quite nicely on x86-64, although I think I
like the 32-bit build (which also built just fine, albeit without ICU)
better due to the excellent JIT support.
http://llvm.org/
>
> It seems to be making a lot of progress lately with the support of Apple
> (which is using LLVM for its own purposes in Mac OS X). Is there anything
> there Parrot can steal? Would it make sense for Parrot to target LLVM
> bytecode and let LLVM do further optimization and native code generation?
I don't know that there'd be much benefit in directly targeting LLVM, but I
do know that it'd be a lot easier to just try using one of their gcc
front-ends to compile parrot. Maybe I'll try that out in a few weeks,
provided that the x86-64 support is there.
There's also the predictably named HLVM:
>
> http://hlvm.org/
Now that looks interesting, if totally pre-alpha; thanks for mentioning it!
which looks vaguely Parrot-ish. Check out the comparison chart:
>
> http://hlvm.org/docs/FAQ.html
>
> Anyway, I'm just thinking out loud, here. Sorry if it's all old news to
> the
> Parrot dev gurus.
It probably is, and I'm no guru, but as projects change and develop, I
don't think it hurts to compare and re-evaluate now and then. :)
-John
>
-- Peter
Aaron Sherman
>
> On 8/22/06, John Siracusa <sira...@mindspring.com> wrote:
> >
> > Has anyone looked at LLVM lately?
[...]
On the other hand, Parrot built quite nicely on x86-64, although I think I
> like the 32-bit build (which also built just fine, albeit without ICU)
> better due to the excellent JIT support.
>
>
Not sure if the list will let this through, since I'm subscribed under
another account, but here's the problem with that: llvm is a very light
layer, but it's yet another layer. To put it between parrot and hardware
would mean that parrot is JITing to LLVM byte-code, which is JITing to
machine code. Not really ideal.
--
Aaron Sherman
Senior Systems Engineer and Toolsmith
AaronJ...@gmail.com or a...@ajs.com
Peter Baylies
>
> On 8/23/06, peter baylies <pbay...@gmail.com> wrote:
>
> > On 8/22/06, John Siracusa <sira...@mindspring.com> wrote:
> > >
> > > Has anyone looked at LLVM lately?
>
>
> [...]
>
> On the other hand, Parrot built quite nicely on x86-64, although I think I
> > like the 32-bit build (which also built just fine, albeit without ICU)
> > better due to the excellent JIT support.
> >
> >
> Not sure if the list will let this through, since I'm subscribed under
> another account, but here's the problem with that: llvm is a very light
> layer, but it's yet another layer. To put it between parrot and hardware
> would mean that parrot is JITing to LLVM byte-code, which is JITing to
> machine code. Not really ideal.
>
That's a good point--at least on platforms where JIT is already supported
for Parrot, it'd probably be desirable to bypass or not use LLVM for that.
However, it shouldn't matter to me at all when I do try building Parrot on
top of LLVM on x86-64. :)
John Siracusa
> here's the problem with that: llvm is a very light layer, but it's yet another
> layer. To put it between parrot and hardware would mean that parrot is JITing
> to LLVM byte-code, which is JITing to machine code. Not really ideal.
...unless LLVM does a much better job of native code generation than the
existing Parrot code, that is. Optimization seems to be LLVM's "thing."
-John
Aaron Sherman
Keep in mind that you're not talking about some HLL generating LLVM
bytecode. You're talking about Parrot reading in Parrot byte code,
JITing to LLVM and then going through that dance again. The amount of
lossage in those layers of translation simply cannot be worth whatever
the difference is between LLVM optimization and Parrot's JIT, since
Parrot will already have generated code that makes it MORE difficult to
optimize.
I'll buy it if I see numbers, but I'm highly skeptical.
Joshua Juran
> Has anyone looked at LLVM lately?
>
> http://llvm.org/
I discovered it a few years ago. My personal interest is in the
portable C back end, so I can use the g++ compiler front end and send
the output through CodeWarrior or MPW compilers, whose language
support is frozen due to non-development (and therefore may have
issues with C99 or modern C++ constructs) but handle C89 just fine.
This will require a fairly large Round Tuit, of course.
This pattern may also be applicable to MSVC.
Josh
P.S. Hi, John! I loved your article on the Spatial Finder.