Error handling in sparse-llvm

Error handling in sparse-llvm

[Dibyendu Majumdar]

Hi,

At present there are a bunch of asserts for scenarios not handled by
Sparse LLVM backend. A more robust error handling method is needed
that works even in release builds, and doesn't abort the process.
Given the way the code is structured currently, I was thinking maybe
it will be easiest to use setjmp/longjmp mechanism to terminate the
LLVM backend on error. I am not sure that this entirely safe with LLVM
as the LLVM code is C++ - I think it might be okay as long as the LLVM
module / context is properly disposed at the end.

Regards
Dibyendu

Re: Error handling in sparse-llvm

[Luc Van Oostenryck]

On Sun, Mar 12, 2017 at 07:40:18PM +0000, Dibyendu Majumdar wrote:
> Hi,
> 
> At present there are a bunch of asserts for scenarios not handled by
> Sparse LLVM backend. A more robust error handling method is needed
> that works even in release builds, and doesn't abort the process.
> Given the way the code is structured currently, I was thinking maybe
> it will be easiest to use setjmp/longjmp mechanism to terminate the
> LLVM backend on error. I am not sure that this entirely safe with LLVM
> as the LLVM code is C++ - I think it might be okay as long as the LLVM
> module / context is properly disposed at the end.

By far, the best thing that can be done is to add support for the missing
features/scenarios so that those asserts can be removed. 

-- Luc Van Oostenryck

Re: Error handling in sparse-llvm

[Dibyendu Majumdar]

On 12 March 2017 at 19:53, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Sun, Mar 12, 2017 at 07:40:18PM +0000, Dibyendu Majumdar wrote:
>> At present there are a bunch of asserts for scenarios not handled by
>> Sparse LLVM backend. A more robust error handling method is needed
>> that works even in release builds, and doesn't abort the process.
>> Given the way the code is structured currently, I was thinking maybe
>> it will be easiest to use setjmp/longjmp mechanism to terminate the
>> LLVM backend on error. I am not sure that this entirely safe with LLVM
>> as the LLVM code is C++ - I think it might be okay as long as the LLVM
>> module / context is properly disposed at the end.
>
> By far, the best thing that can be done is to add support for the missing
> features/scenarios so that those asserts can be removed.
>

Agreed, but that will probably take some time. In the meantime even
with the subset supported by Sparse-LLVM it can be used in
applications - provided it deals with supported features gracefully
and generates correct code for supported features.

Regards
Dibyendu

Re: Error handling in sparse-llvm

[Dibyendu Majumdar]

On 13 March 2017 at 10:43, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> On 12 March 2017 at 19:53, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>> On Sun, Mar 12, 2017 at 07:40:18PM +0000, Dibyendu Majumdar wrote:
>>> At present there are a bunch of asserts for scenarios not handled by
>>> Sparse LLVM backend. A more robust error handling method is needed
>>> that works even in release builds, and doesn't abort the process.
>>> Given the way the code is structured currently, I was thinking maybe
>>> it will be easiest to use setjmp/longjmp mechanism to terminate the
>>> LLVM backend on error. I am not sure that this entirely safe with LLVM
>>> as the LLVM code is C++ - I think it might be okay as long as the LLVM
>>> module / context is properly disposed at the end.
>>
>> By far, the best thing that can be done is to add support for the missing
>> features/scenarios so that those asserts can be removed.
>>
>
> Agreed, but that will probably take some time. In the meantime even
> with the subset supported by Sparse-LLVM it can be used in
> applications - provided it deals with supported features gracefully
> and generates correct code for supported features.
>

Apologies for the typo - I meant to say 'it deals with unsupported
features gracefully'.

Regards