Problem with 64-bit pointers (?)

[Rasmus Knutsson]

Hi all,

I have the problem that I cannot run the arrays2 extension on my Mac
OSX 10.6.7, while it runs just spiffing on my 32-bit Ubuntu 11.4. My
guess is that the 64-bit pointers on my Mac screw things up.
Specifically, this happens when I use literals to index my arrays
instead of variables, whereupon I get the rather discomposing error
message included below.

My question is really whether you think this is related to the pointer
size, as I assumed, or whether I should keep looking for other
reasons. I assume it is not required for this course to generate 64-
bit code, though I am of course interested to know how it is done if
it is not too much of a hassle.

0 lli 0x00000001006fe522
llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 10962
1 lli 0x00000001006fef13
llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 13507
2 libSystem.B.dylib 0x00007fff8281c66a _sigtramp + 26
3 libSystem.B.dylib 0x0000000100a0bf50 _sigtramp + 2115959040
4 libSystem.B.dylib 0x000000010095b01d _sigtramp + 2115234253
5 lli 0x0000000100575c2f
std::_Rb_tree<std::pair<llvm::SCEV const*, llvm::Instruction*>,
std::pair<std::pair<llvm::SCEV const*, llvm::Instruction*> const,
llvm::AssertingVH<llvm::Value> >,
std::_Select1st<std::pair<std::pair<llvm::SCEV const*,
llvm::Instruction*> const, llvm::AssertingVH<llvm::Value> > >,
std::less<std::pair<llvm::SCEV const*, llvm::Instruction*> >,
std::allocator<std::pair<std::pair<llvm::SCEV const*,
llvm::Instruction*> const, llvm::AssertingVH<llvm::Value> > >
>::_M_insert_unique(std::_Rb_tree_iterator<std::pair<std::pair<llvm::SCEV
const*, llvm::Instruction*> const, llvm::AssertingVH<llvm::Value> > >,
std::pair<std::pair<llvm::SCEV const*, llvm::Instruction*> const,
llvm::AssertingVH<llvm::Value> > const&) + 69535
6 lli 0x0000000100013f81
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 8385
7 lli 0x00000001000134c4
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 5636
Stack dump:
0. Program arguments: lli ./a.out.bc

[Björn von Sydow]

Dear all,

I am a bit worried by Rasmus' mail.

There are some subtle issues relating to LLVM and 32/64 bit architectures. This turned up last year (when we were running LLVM 2.6) and for this I hoped to have tamed the problem by making you insert the "target datalayout" line in the beginning of each file. But now it seems that the problem may still be there in some form. As you see from Rasmus' mail, the error messages from lli are not very helpful. I would be very interested in knowing whether Rasmus can run his solution on the machines in the lab rooms. Since these are 64 bit machines, I am worried that this might not be the case.

I will look more into this later today, but for the moment I can only warn those of you who are working on extensions involving pointers that there might be some LLVM-related problem. (Of course, it is still quite possible that the problem is in your code.)

As for Rasmus' question about generating 64 bit code on the Mac, I believe there is a very simple solution: Just remove the "target datalayout" everywhere (including in lib/runtime.ll) and everything should work. Of course, I would also appreciate to get to know if this is so. If you want to see the assembly code generated at runtime by lli's JIT compiler (or just want to create an executable that does not depend on lli), you might do

llc a.out.bc

which generates x86_64 assembly in a.out.s. To get an executable from this, use gcc:

gcc a.out.s

Björn

[Rasmus Knutsson]

Hi,

I have not yet tried my solution in the lab rooms, but on one of the
remote machines, and yes I got the same problem there, and yes,
removing the data-layout lines fixed the issue, there as well as on my
mac.

Thanks!

/Rasmus

[Björn von Sydow]

There is a subtle problem in our use of LLVM that may affect your project. I don't
understand the problem fully, but my present incomplete understanding is that

- the problem only appears when you use pointers, so for basic
Javalette there are no problems.

- the problem only appears when you run your code on 64 bit machines (such as
our lab machines).

- the problem can be avoided by removing the target datalayout line in runtime.ll and also
not generating any such lines in your compiler (recommended solution).

- the problem can also be avoided by leaving these lines as they are and calling
llvm-ld with the command line option disable-opt, which avoids all optimization.

I have some more information and some examples that show how
optimization introduces a problem in the code having to do with alignments, but
for the moment I leave the explanation at this point. I am willing to
offer a credit for an analysis of the problem. Contact me if you are interested.