[LLVMdev] Two suggestions for improving LLVM error reporting

[Kenneth Uildriks]

On Sat, Jan 9, 2010 at 9:27 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> On Sat, Jan 9, 2010 at 1:09 AM, Chris Lattner <clattner at apple.com> wrote:
>>
>> 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 ;-)

 Sweet!  Could named types also be concrete in this scheme?