http://snakeratpig.blogspot.com/2008/02/alternative-compiler-suites.html
Executive summary: LLVM-GCC was consistently faster and its output consistently faster than plain old GCC when compiling and using Ruby 1.9. Both compilers failed spectacularly on the full regression suite, but GCC lasted longer and did more tests before exploding.
If I could find a comprehensive Erlang testing suite, I’d blog those results as well. I have been using LLVMed Erlang for two months now, however, with no ill effects noted and a “feel” that it is snappier.
Good work. LLVM rocks.
Hi Michael, thanks for trying out LLVM!
"The bad news comes with the make test-all results. Less than two minutes
into the comprehensive test suite the LLVM-GCC version of Ruby 1.9 dies with
the following message: "Illegal instruction (core dumped)". Later it tells me
the test failed with "error 132". This is, as you can see, not a very useful
message since it's not really helping me locate where the error is."
The illegal instruction message is not coming from ruby or LLVM, it is
coming from the OS: the program fed the processor some garbage to execute
rather than proper instruction codes, and was promptly killed with this
message. As for "error 132", it is also not coming from LLVM which does
not produce messages of this kind.
Does ruby compile ruby code to native instructions and execute them? If
so and it made a mistake that would explain the illegal instruction error.
Otherwise it probably means that llvm-gcc miscompiled something. If you
can extract a testcase please don't hesitate to post it to LLVM bugzilla
(http://llvm.org/bugs). Bugs generally get fixed fast, but someone needs
to report them!
Best wishes,
Duncan.
Hi Duncan,
"The bad news comes with the make test-all results. Less than two
minutes into the comprehensive test suite the LLVM-GCC version of Ruby
1.9 dies with the following message: "Illegal instruction (core
dumped)". Later it tells me the test failed with "error 132". This is,
as you can see, not a very useful message since it's not really
helping me locate where the error is."
The illegal instruction message is not coming from ruby or LLVM, it is
coming from the OS: the program fed the processor some garbage to
execute rather than proper instruction codes, and was promptly killed
with this message. As for "error 132", it is also not coming from
LLVM which does not produce messages of this kind.
132 is 0x84 and looks like an exit value for the process, i.e. it was
killed by signal 4 which is normally SIGILL, i.e. illegal instruction.
The test harness is probably printing the `error 132'.
Cheers,
Ralph.
Does ruby compile ruby code to native instructions and execute them?
No. Ruby is an interpreted language. The latest version has a VM that it targets – YARV – but it still does not compile to native like, say, a JIT would.
Otherwise it probably means that llvm-gcc miscompiled something.
This is what I’m guessing at this stage. It is, however, only a guess. And given that GCC raw – the “native” compilation platform for Ruby – also fails (albeit in a different, highly-entertaining way – I’m also guessing that part of this is because Ruby is doing some weird stuff behind the scenes.
If you can extract a testcase please don't hesitate to post it to LLVM bugzilla
([http://llvm.org/bugs](http://llvm.org/bugs)). Bugs generally get fixed fast, but someone needs
to report them!
I have already reported the bug with a “test case” that consists of “here is how to build Ruby with llvm-gcc”. 
I have also slotted some hacking time to figure out where in the test harness the thing is exploding. Unfortunately, unlike the explosion that GCC’s failure gives, the LLVM-GCC version explodes so thoroughly that it doesn’t print out any kind of error message. All I get is a bunch of pacifier dots on the screen as one test after another is run (there are thousands) and then that message. It will take me a while to figure out where the error is happening. (Binary search for the win!) Once I have it narrowed down to one specific test, I will update the bug report with the steps required to replicate the error.
Hi Michael,
All I get is a bunch of pacifier dots on the screen as one test after
another is run (there are thousands) and then that message. It will
take me a while to figure out where the error is happening. (Binary
search for the win!) Once I have it narrowed down to one specific
test, I will update the bug report with the steps required to
replicate the error.
Take a look at the test harness source. Most likely, where it's
printing those dots, there's a conditional "if verbose, print the test
name". You can then look to see how to turn on verbose, etc.
Cheers,
Ralph.
Hi Michael,
... Unfortunately, unlike the explosion that GCC's failure
gives, the LLVM-GCC version explodes so thoroughly that it doesn't print
out any kind of error message. All I get is a bunch of pacifier dots on
the screen as one test after another is run (there are thousands) and
then that message.
I tried it here and it's not clear to me whether it failed the same way
as for you. I noted what I saw in the bugzilla entry
http://llvm.org/bugs/show_bug.cgi?id=2038
Let's continue the discussion there.
Best wishes,
Duncan.