[LLVMdev] Proposal for better assertions in LLVM

[Talin]

On Tue, Aug 9, 2011 at 4:40 PM, Renato Golin <rengolin at systemcall.org>wrote:

> On 29 July 2011 12:48, Dan Bailey <dan at dneg.com> wrote:
> > I'm not going to comment on the syntax of any of the proposals made, just
> > dispute that they don't provide sufficient value to make them worth
> > introducing.
>
> Hi Dan,
>
> I've read the arguments on both sides and I have to say I'm with Chris
> on this one.
>
> I normally keep GDB running with my debug image. After re-compiling,
> re-running in GDB is just a matter of typing "r".
>
> All breakpoints are still there, when it hits an assertion, the
> back-trace is clear enough to give me the track back, print the values
> that you'd get from Talin's proposal and set breakpoints just before
> to see what happens. It's simple and painless.
>
> I can see a slight benefit on printing the values in the assert if
> you're asking a user to report the error and you want to immediately
> get what's on. A more valuable case is when the user cannot send you
> their code, but that's also less common. If you fall into those cases,
> you can use the debug mechanism.
>
> Talin's compiler has a lot of boilerplate, making it difficult to
> reduce the case or maybe (I'm guessing), to reproduce the error. In
> your case, Dan, I believe it's hard for you to use GDB (I'm assuming
> graphics programming here). Again, a better tool would be to use the
> debug/log mechanism with different levels of trace.
>
> One way in which my compiler is atypical is that it generates a large and
diverse set of constant structs used for reflection, type attributes,
garbage collection, and other runtime metadata. There's something on the
order of 40 different types that the compiler spits out as static instances
- AttributeList, EnumType, StaticRoot, PropertyList, and so on. A lot of the
problems I run into are cases where I have initialized a field of a static
struct, but forgot to insert the proper pointer cast or GEP - so for example
I have a struct which is supposed to point to a Foo*, but it's actually
pointing to an [N x Foo], and so I get an assertion that I have to track
down.

This is also why it's difficult for me to get small reproducible test cases:
Even tiny source code files tend to produce a complex web of static objects
- so for example, if I declare a class, that brings in type Object, which in
turn brings in TypeInfoBlock and Type, and those in turn pull in NameTable
and Module, which bring in ImmutableList[String], and so on. The good news
is that you only have to pay this cost once, since every module pulls in
basically the same stuff. The bad news is that it's very difficult to reduce
a compiled module below a certain minimum size. I know from personal
experience that LLVM developers aren't likely to spend any time looking at a
200k bitcode file that I've attached to a bug report.

(I've actually considered making an automated tool that severs these
connections - replacing the pointers to these static objects with NULL
pointers and then running the dead globals pass. It's something I just
haven't gotten around to.)


> Asserts are the last stand before silent codegen errors, and as such,
> they have to be extremely light-weight so you can include them in
> production binaries. Even though it's now disabled by default (Chris
> got a good performance boost doing so, I believe), it could easily be
> turned on in production for prototype/beta release.
>
> I'd change the debug mechanism to fit to your purpose, rather than
> enhance the assertions.
>
> My tuppence.
>
> cheers,
> --renato
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110809/df1a65b1/attachment.html>