On Sat, October 11, 2008 3:13 pm, Chris Lattner wrote:> [...] Sending invalid > code into the backend is violating a very important invariant in the > API. I don't see how it would be any different then passing in a null > pointer or garbage pointer into an API that would then bus error.Besides invalid IR, codegen also uses abort and assert when it encounters valid and Verifier-clean IR that uses features that codegen does not suport, due to missing functionality (e.g. i1024) or due to target-specific limitations (e.g. x86_f80 on non-x86 targets). Currently there no way to recover if the IR contains some construct that codegen can't handle. This is unfortunate for some applications. Dan
On Oct 13, 2008, at 10:05 AM, Dan Gohman wrote:> On Sat, October 11, 2008 3:13 pm, Chris Lattner wrote: >> [...] Sending invalid >> code into the backend is violating a very important invariant in the >> API. I don't see how it would be any different then passing in a >> null >> pointer or garbage pointer into an API that would then bus error. > > Besides invalid IR, codegen also uses abort and assert when it > encounters valid and Verifier-clean IR that uses features that > codegen does not suport, due to missing functionality (e.g. i1024) > or due to target-specific limitations (e.g. x86_f80 on non-x86 > targets).There are also some cases with inline asm that do the same thing.> Currently there no way to recover if the IR contains some > construct that codegen can't handle. This is unfortunate for some > applications.I completely agree, but these should not be fixed with exceptions: this should be fixed by adding a direct failure reporting mechanism. -Chris
On Oct 13, 2008, at 12:42 PM, Chris Lattner wrote:>> >> Currently there no way to recover if the IR contains some >> construct that codegen can't handle. This is unfortunate for some >> applications. > > I completely agree, but these should not be fixed with exceptions: > this should be fixed by adding a direct failure reporting mechanism. > > -ChrisAndrew and I (and another faculty member here) are working on software recovery techniques for run-time errors that would otherwise be fatal, so I am curious about this answer. Why do you think these cases should not be fixed with exceptions? What if a client wants to *recover* in some manner, e.g., by emulating missing instructions or transforming the code (or any of a variety of other recovery strategies), but not just report a failure to the external world? --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve
On 2008-10-13 20:42, Chris Lattner wrote:> On Oct 13, 2008, at 10:05 AM, Dan Gohman wrote: > > >> On Sat, October 11, 2008 3:13 pm, Chris Lattner wrote: >> >>> [...] Sending invalid >>> code into the backend is violating a very important invariant in the >>> API. I don't see how it would be any different then passing in a >>> null >>> pointer or garbage pointer into an API that would then bus error. >>> >> Besides invalid IR, codegen also uses abort and assert when it >> encounters valid and Verifier-clean IR that uses features that >> codegen does not suport, due to missing functionality (e.g. i1024) >> or due to target-specific limitations (e.g. x86_f80 on non-x86 >> targets). >> > > There are also some cases with inline asm that do the same thing. > > >> Currently there no way to recover if the IR contains some >> construct that codegen can't handle. This is unfortunate for some >> applications. >> > > I completely agree, but these should not be fixed with exceptions: > this should be fixed by adding a direct failure reporting mechanism.And when that mechanism will exist, it'll be also completely safe to delete the Module, and call llvm::shutdown to prevent memory leaks as well, right? ;) And if somebody really wants exceptions, he could use them without adding exceptions to LLVM itself. He could wrap the call to LLVM that can fail in a try{} catch{}, and set the failure hook to throw an exception. That would get properly propagated back up to the catch, even if LLVM itself is compiled without exceptions, and then in the catch the Module can be deleted, and llvm::shutdown called. Would that work? Best regards, --Edwin