Hi,
I was thinking about the potential for link-time optimizations. And the
fact that you already now output LLVM bitcode to object files, archives,
and perhaps even executables (that would give a .NET flavor to LLVM, I
wonder if this can be made to work seamlessly on Windows [1]). Then I
thought about the fact that you seem intent on supporting all native
formats that you run into.
I was then thinking something along this path: "What if we were to create a
new set of binary formats just for LLVM, that people can use if they prefer
clang(++)?"
It is probably me that is something wrong with, but I have a strong dislike
for the existing object, archive, and executable formats. For one, most of
them are designed in such a way that you'd think there was something
mentally wrong with the guys who designed them. Look at COFF strings, for
instance, and notice how complicated it is to decode a COFF string when all
you ought to do was to look up an offset into a string table. And so on
with the various formats.
What do you nowadays with LLVM extensions? Do you encode them in the
bitcode that you output to object files or what. I'm thinking of all the
information that usually gets lots when you output an ordinary object file:
pretty much all but the binary image and a set public symbols and
relocations.
My angle to LLVM is this: LLVM is the future, GCC is the past. Not all may
agree with me, but I think we'll see GCC fade away as clang/clang++ become
more widely used. So why accept the limitations of GCC object file formats?
I am not trying to start a flame war or anything. I can be told to shut up
if I produce too many stupid questions in too short a time :-)
[1] It can. Simply reserve a specific extension, such as "lbc" (LLVM
BitCode), to the file type and then define a system-wide association to the
bitcode interpreter, and you're all set.
Cheers,
Mikael
-- The Day You Stop Wondering Is the Day You Died.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120528/3b835b9a/attachment.html>