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. 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
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?> > 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
On 4 October 2011 23:54, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:> 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?Any code with C++ classes, C unions and bit-fields would be much improved. Talin might help you with non-C++ types. Basically anything that has to be kludged to be lowered to IR would benefit from a higher-level IR. ByValue calls, self pointers, RTTI, virtual inheritance, multiple inheritance. Dan's argument that IR is unstable is clear when you get to write a front-end from scratch. The first front-end generated a lot of kludge to lower C++, since it'd take years to implement it properly in IR (and all back-ends). The second, third and so on were forced to follow the same kludge. Non-C++ front-ends suffer even more, since they have to kludge their languages into a C++-semantic kludge, which has no 1-to-1 relationship with the original semantics of their code. Search on the list about the topics above and you'll see that there was a lot of discussion wasted on them for years and years. -- cheers, --renato http://systemcall.org/
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>