[LLVMdev] LLVM IR is a compiler IR

[Jianzhou Zhao]

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