[LLVMdev] Proposal for better assertions in LLVM

Renato Golin rengolin at systemcall.org
Tue Aug 9 16:40:49 PDT 2011


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.

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



More information about the llvm-dev mailing list