Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

PPC doesn't support non-lazy JIT compilation #5326

Open Quuxplusone opened 15 years ago

Quuxplusone commented 15 years ago
Bugzilla Link PR4816
Status NEW
Importance P normal
Reported by Török Edwin (edwin+bugs@etorok.eu)
Reported on 2009-08-28 11:36:48 -0700
Last modified on 2011-03-18 06:37:43 -0700
Version unspecified
Hardware PC Linux
CC annulen@yandex.ru, jyasskin@google.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments x.bc (492 bytes, application/octet-stream)
jitemitter-place-stubs.patch (36065 bytes, text/plain)
Blocks
Blocked by
See also
Created attachment 3386
x.bc

Disabling lazy compilation fails on PPC:

Release/bin/lli -disable-lazy-compilation  ~/x.bc
Assertion failed: (0 && "This target doesn't implement
emitFunctionStubAtAddr!"), function emitFunctionStubAtAddr, file
/Users/acab/clamav-
devel/libclamav/llvm/llvm/include/llvm/Target/TargetJITInfo.h, line 65.
0   lli               0x0065d50c llvm::sys::RWMutexImpl::writer_release() + 476
1   lli               0x0065dddc llvm::sys::RemoveFileOnSignal(llvm::sys::Path
const&, std::string*) + 1244
2   libSystem.B.dylib 0x92f639fc _sigtramp + 68
Stack dump:
0.      Program arguments: Release/bin/lli -disable-lazy-compilation
/Users/acab/x.bc
Abort trap

It seems that X86 is the only target that implements that method.

In this case it is simply a matter of ordering the functions bottom-up
according to the callgraph, and then non-lazy compilation should succeeed on
the Mac too in this case, BUT it would fail for mutually recursive functions.

Is there a workaround that doesn't need emitFunctinStubAtAddr, or should I just
always use lazy compilation on Mac/PPC? (rather anything non-X86?)
Quuxplusone commented 15 years ago

Attached x.bc (492 bytes, application/octet-stream): x.bc

Quuxplusone commented 15 years ago

I'm pretty sure you're correct that the eager JIT only exists on x86. It doesn't look that hard to implement emitFunctionStubAtAddr given emitFunctionStub (with some thought, maybe we can unify them), but I don't have a PPC or ARM to test on, so I'm a bit reluctant to try it myself. Would you be interested in taking a shot at the implementation? If not, I may be able to find a machine to test on or use the buildbots as guinea pigs.

Quuxplusone commented 15 years ago
(In reply to comment #1)
> I'm pretty sure you're correct that the eager JIT only exists on x86. It
> doesn't look that hard to implement emitFunctionStubAtAddr given
> emitFunctionStub (with some thought, maybe we can unify them), but I don't
have
> a PPC or ARM to test on, so I'm a bit reluctant to try it myself. Would you be
> interested in taking a shot at the implementation?

For PPC and ARM there are some Linux machines on the compile farm.
They are about 7-13 times slower than my x86-64 box though, so it may take some
time to compile LLVM initially.

>If not, I may be able to
> find a machine to test on or use the buildbots as guinea pigs.
>

I may have some time for this late next week.
Quuxplusone commented 15 years ago

I may wind up fixing this as part of the redesign for PR5201, so don't waste time working on it yet.

Quuxplusone commented 15 years ago

Attached jitemitter-place-stubs.patch (36065 bytes, text/plain): Possible fix