[LLVMdev] LLVM IR is a compiler IR

[Talin]

On Tue, Oct 4, 2011 at 5:07 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Oct 4, 2011, at 4:41 PM, Talin wrote:
>
>  One thing you would need is the ability to assign names to struct
>> members. Currently LLVM refers to struct members by numerical index, and I
>> wouldn't want to change that. However, in order to be visible in the
>> debugger, you also have to assign a name to each member. Note that this
>> information doesn't need to take a lot of space in the module - names are
>> highly compressible, especially fully qualified names (foo.bar.X.Y.Z) where
>> you have a whole bunch of names that start with the same prefix. (In my own
>> frontend, I sort names by frequency, so that the names that are used most
>> often have the lowest assigned IDs. This allows the reference to the name to
>> be stored in fewer bits.)
>>
>>
>> Talin, if you're trying to produce a "C virtual machine" you basically
>> need everything in a C AST.  You're scratching the surface of the issues.
>>
>> I was trying to limit my response to just a few examples - I realize that
> there's a ton of things I've left out. I guess what I am describing is the
> same as Microsoft's "Managed C++" - the ability to compile C++ programs to
> the CLR. Note that Managed C++ doesn't give you every possible feature of
> C++, you can't take an arbitrary C++ program and expect to compile it in
> managed mode.
>
>
> Are you willing to give up the ability to interoperate with existing ABIs
> and code compiled by other compilers?
>
> For my own needs, I'd be willing to live with a system that requires extra
effort on behalf of the programmer (in the form of __attributes or #pragmas
or SWIG) when calling out to code produced by other compilers. In other
words, I'd like for the kind of interoperability you describe to be
*possible*, but I don't necessarily require or expect that it be *easy*.

-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/30914856/attachment.html>