[cfe-dev] Stupid 64-bit divide question

per at lumai.se per at lumai.se
Fri Oct 1 00:32:52 PDT 2010


Michael Spencer skrev 2010-09-30 19:41:
> On Thu, Sep 30, 2010 at 6:16 AM, per at lumai.se<per at lumai.se>  wrote:
>> Hi all,
>>
>> I am experimenting with compiling C code under Windows (MSVC env., _not_
>> mingw) via COFF ->  exe file using clang x.c -emit-llvm and llc
>> -filetype=obj followed by linking using the MSVC linker. This works well
>
> Good to see someone else using this. Let me know if you find any
> problems (I know of quite a few, and am currently working on them).

Ok, here's one: ;-) Compile

#include <stdio.h>
int main(int argc, char **argv) {
	printf("First string\n");
	printf("Second string\n");
}

in the MSVC command prompt, using

clang argtest.c -emit-llvm -c -o argtest.bc
llc -filetype=obj argtest.bc -o argtest.obj
link libcmt.lib argtest.obj

Now run argtest.exe. I get

First string
First string

Hmm... COFF trouble?

>> except that some 64 bit arithmetic operations generate libcalls to
>> functions like __divdi3 which have different names/uses in the MSVC
>> runtime (i.e. __divdi3 ~= __alldiv in libcmt.lib). I assume that
>> __divdi3 is something GNU specific. Is there a simple way to influence
>> which libcalls are emitted? Any attempts to define my own __divdi3 seem
>> to be ignored.
>
> These calls are generated in the LLVM x86 backend, which needs to be
> taught about the MSVC runtime, as currently it only knows about GNU.
> Interestingly code using these constructs executes correctly if run
> with the JIT, but I don't know how (there's no __divdi3 in the JIT
> either).

That's about what i understood. I was looking for pointers on how to 
start creating a MSVC-runtime-aware stub. I didn't quite get the 
relationship between libcalls and the TargetInfo classes. Alternatively, 
as stated in this thread, compiler-rt would do the trick  if it built on 
Win32. Going down that path sounds a lot easier as I see it right now.

> In short, Windows support is still way behind GNU and Darwin support,
> but there are quite a few of us working on it, and any help (including
> reduced test cases) is appreciated.

Yeah, I have been testing this to and from and submitted a few trivial 
patches. Let me know if there's anything I could do. This is purely out 
of personal interest though.

/Per




More information about the cfe-dev mailing list