On Tue, Oct 4, 2011 at 3:54 PM, Jianzhou Zhao <jianzhou at
seas.upenn.edu>wrote:
> On Tue, Oct 4, 2011 at 6:36 PM, Renato Golin <rengolin at
systemcall.org>
> wrote:
> > Hi Talin,
> >
> > I too agree 100% with Dan's words, and this could be a good
pointer
> > for Jin-Gu Kang to continue on his pursuit for a better
> > target-independent bitcode.
> >
> > Also, add your backwards compatibility issue to debug metadata in IR,
> > in which fields appear or disappear without notice.
> >
> > But I think you hit a sweet spot here...
> >
> >
> > On 4 October 2011 21:23, Talin <viridia at gmail.com> wrote:
> >> This hypothetical IR language would include a type system that was
rich
> >> enough to express all of the DWARF semantics - so that instead of
having
> two
> >> parallel representations of every type (one for LLVM's code
generators
> and
> >> one for DWARF), you could instead generate both the LLVM types and
the
> DWARF
> >> DI's from a common representation. This would have a huge
savings in
> both
> >> complexity and the size of bitcode files.
> >
> > This is a really interesting idea. If you could describe your type
> > system in terms of Dwarf, you would have both: a rich type system AND
> > free Dwarf.
>
> This sounds interesting. I did not get what is a ``rich type system to
> express all of the DWARF semantics''. Could you show an example
> program that the rich type system can define, but the current IR fails
> to present? And how does it improve the IR?
>
> 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.)
Similarly, in order to handle inheritance, you would need a way to indicate
which fields of the struct were "inherited". Currently, inheritance is
handled by embedding the parent class as the first member of the child class
- but the IR level can't tell whether that first member is inherited or is
just a regular member.
Both of these are features that LLVM IR doesn't need, but which would be
nice to have in a higher-level IR based on top of LLVM.
Note that you could also use the "rich type system" for generating
reflection data as well. So that's a third use case.
I better stop right now before I convince myself to do something crazy, like
write my own VM.
>> > However, writing a back-end that would understand such a rich type
> > system AND language ABIs is out of the question.
> >
> > We were discussing JIT and trying to come to a solution where JIT
> > wouldn't be as heavy as it has to be now, to no avail. Unless
there is
> > a language that is of a higher level (like Java bytecode) or JIT will
> > always suffer.
> >
> > If you join Dan's well said points, plus yours, Jin-Gu's and
the
> > necessity of a decent JIT, it's almost reason enough to split the
IR
> > into higher and lower versions (as proposed last year to deal with
> > complex type systems and ABIs).
> >
> > Even some optimisations (maybe even Polly) could benefit from this
> > higher level representation, and all current optimisations can still
> > pass on the current, low-level, IR.
> >
> > My tuppence.
> >
> > cheers,
> > --renato
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
>
>
> --
> Jianzhou
>
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/17830727/attachment.html>