[LLVMdev] LLVM IR is a compiler IR

[Renato Golin]

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