[cfe-dev] Stupid 64-bit divide question

[Michael Spencer]

On Fri, Oct 1, 2010 at 3:32 AM, per at lumai.se <per at lumai.se> wrote:
> 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?

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.

>
>>> 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>