[LLVMdev] Two suggestions for improving LLVM error reporting
kennethuil at gmail.com
Sat Jan 9 07:28:18 PST 2010
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?
More information about the llvm-dev