[LLVMdev] LLVM asserts

Török Edwin edwintorok at gmail.com
Thu Aug 20 07:21:46 PDT 2009


On 2009-08-20 16:50, Kenneth Uildriks wrote:
>> To be fully clear, I'm not a big fan of the current llvm_report_error
>> approach (though it is definitely better than what we had before!).
>> In my ideal little world, when the backend invokes llvm_report_error,
>> it should *guarantee* that it can continue on and return back.  For
>> example, in an inline asm error, I think the code generator should
>> report the error with llvm_report_error and then discard the invalid
>> inline asm and continue code generation.
>>     
>
> On one hand, the same thing could occur with any malformed
> construct...  a type mismatch in the values fed to CreateCall, for
> instance, wouldn't corrupt memory; the error could be reported and the
> CallInst discarded.  On the other hand, of course, if the client is
> expected to check for that stuff, it would slow things down to check
> for it again on each CreateXXX call, so I certainly see the logic in
> keeping that the way it is.
>
> I think it would be a big improvement for the asserts in those cases
> to print out what values it expected and what values it got, say by
> dumping the offending Value or Type objects to the console along with
> the line in Instructions.cpp where the assert happens.  Would y'all
> look kindly on a patch for that after the release?  I think it would
> speed up every client development project.  I know as I develop my
> compiler, I would love to have a way to print out that information if,
> and only if, something is wrong with the values I'm trying to feed
> CreateXXX.
>   

Maybe those asserts could be replaced with an optional failure reporting
code?
By default it would assert, as currently, and if enabled it can report
the exact error to you.

Regarding the corrupted memory issue: we have LLVMContext now, just
because LLVM/an LLVM module is corrupted
in one Context it shouldn't prevent the use of LLVM in other contexts.
I think the cases where memory corruption outside LLVMContext triggers
an assert is rare.
Perhaps asserts could be turned into something else if the user desires
via a compile-time switch?

Thoughts?

P.S.: after 2.6 is released of course

Best regards,
--Edwin



More information about the llvm-dev mailing list