[LLVMdev] Two suggestions for improving LLVM error reporting

[Chris Lattner]

On Jan 9, 2010, at 12:07 AM, Jon Harrop wrote:

> On Saturday 09 January 2010 06:11:03 Chris Lattner wrote:
>> My eventual goal (perhaps for LLVM 3.0) is to eliminate our current
>> structural type system altogether.  The benefits are blown away by the
>> costs, eventually we should just fix this design mistake.  In the meantime,
>> I'm not opposed to adding a Module* to VMCore that type dumping defaults to
>> if non-null.
> 
> Can you elaborate on this? I'm loving LLVM's structural types and they're 
> making my work a lot easier.
> 
> Having to come up with names for all of the structural types in my language 
> just to satisfy LLVM's new type system would suck...

There are two things I don't like about our current system:

1. Type resolution is really slow in some cases, because it has to incrementally detect when mutating type graphs become isomorphic and zap them.  This is seen during bc/ll loading and particularly during module linking.  This is one of the biggest sources of LTO slowness that I'm aware of.

2. Our implementation of type resolution uses union find to lazily update Type*'s in values etc.  This means that Value::getType() is not a trivial accessor that returns a pointer - it has to check to see if the pointer is forwarded, and if so, forward the pointer in the type.

I'm not advocating elimination of pointer equality tests, but I am advocating the elimination of pointer equality tests for type *structure*.  I want to introduce a first class "named type" type, and allow only *them* to be abstract, instead of having our current Opaque type.

This means that if you have a "%foo***" and %foo gets resolved to "i32", that "%foo***" would not get implicitly unioned with "i32***".  This would also eliminate the current complexity forming circular types, make many frontends simpler etc.  It would mean that a cyclic type would be *required* to go through a named type though.

It would also allow elimination of upreferences, PATypeHolder, PATypeHandle, etc.  It would also eliminate the frequent confusion around "my function should take a %foo*, it the IR dump shows it as %bar*" (because they have the same type structure).

OTOH, it would mean that we couldn't have the totally awesome and oh-so-useful \1* type ;-)

-Chris