https://bugs.llvm.org/show_bug.cgi?id=35120
Andreas Haferburg <andreas.haferb...@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andreas Haferburg <andreas.haferb...@gmx.de> ---
Aha! Alright, now I understand, thank you. If I emit the instructions for the
linker in the IR, I no longer need to specify it when calling link.exe or
clang-cl.exe.
> !llvm.linker.options = !{!1}
> !1 = !{!"/DEFAULTLIB:libcmt.lib"}
>From the perspective of a frontend author, I do find it very surprising to look
at .ll as .obj. clang.exe will produce an .obj file from the .ll file, so they
must be different. But I understand that the clang-cl driver's job is to
produce IR, so everything it does should be contained in the IR. I guess it's a
pitfall for frontend authors that can't be avoided.
I believe the main problem was that I couldn't figure out how to make
`clang-cl.exe` output IR, since `-S -emit-llvm` doesn't work with clang-cl.exe,
and none of the examples are written for clang-cl.exe. What I ended up doing is
call `clang-cl.exe -###` to find out what it actually does, and then replace
the `-emit-obj` with `-emit-llvm`, but that is very much non-obvious. So I
ended up looking at random hello_world.ll files that I found on the web, which
was a bad idea.
There is no `-emit-llvm` flag in gcc either. Why doesn't `/c -emit-llvm` work
with clang-cl.exe? I'll open a feature request.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
