[LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build

Chuck Rose III cfr at adobe.com
Mon Feb 18 17:14:45 PST 2008


Hola Anton,

I live in a pretty closed world, so all of the functions I might want to
call back to are pretty simple and are either compiled by me or can be
wrapped by a function I can compile.  

Would my life be made fantastically simpler if I were using a different
calling convention for my callback functions on x64 running on Windows?

I'll have a look at the areas you pointed me to.

Thanks,
Chuck.

-----Original Message-----
From: Anton Korobeynikov [mailto:asl at math.spbu.ru] 
Sent: Monday, February 18, 2008 4:20 PM
To: Chuck Rose III
Cc: llvmdev at cs.uiuc.edu; evan.cheng at apple.com
Subject: RE: [LLVMdev]LLVM2.2 x64 JIT trouble on VStudio build


Hello, Chuck

> I've had a look at the stubs before and I think I'm circumventing them
> in the example program since I populate the table and compile the
> functions in the order so that things never need to be done lazily,
but
> I'll look further.
Well, anyway stubs are definitely wrong from windows64 and this should
be fixed, otherwise funny stuff can happen from time to time.

> If the answer is to add support for x64 windows calling conventions,
> which parts of LLVM should I be looking at to understand what needs to
> be done?
The CC is described in the X86CallingConv.td file and also some other
bits are expanded in the X86ISelLowering.cpp

The changes needed for windows64 CC are pretty straightforward
modification of the current x86-64 CC (I even can try to find my
preliminary patch made this summer). 

However, there is one pretty ugly thing currently totally unimplemented:
register shadowing: consider, e.g. void foo(int, double). First argument
is passed into RCX, and second in both XMM1 and RDX. Also not, that it
gos to XMM1, because it's second argument and XMM0 is shadowed by
already-used RCX.

I think I can try to heal my early patch and then stuff should be
extended to handle these specific construction.

--
WBR, Anton Korobeynikov 




More information about the llvm-dev mailing list