Stupid 64-bit divide question

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 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.

cheers,
Per Lindén

These functions should be found in compiler-rt:

http://compiler-rt.llvm.org/

David

Thanks, that might get me a part of the way, though compiler-rt in turn uses GCCisms such as __builtin_ctz and includes <complex.h> which is not present in the WinSDK.

Besides, the resulting binary I produced so far acts completely erratic, probably due to some calling convention problems... Back to the laboratory again, I guess.

//Per

David Chisnall skrev 2010-09-30 13:05:

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).

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).

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.

Michael Spencer skrev 2010-09-30 19:41:

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: :wink: 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

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

Michael Spencer skrev 2010-09-30 19:41:

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: :wink: 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?

Wow, there's a test in the regression suite that tests this on every
commit... And it currently passes. Thanks, I thought I had already
solved this :P.