search for: codegenverifi

...t; in this library, especially > since bad code will probably happen very often Patches to do the kind of checking you're asking about would be welcome :-). I don't think it makes sense to extend the Verifier itself here; it's supposed to accept any valid LLVM IR. I think a separate CodeGenVerifier might be a good approach though, or possibly extending codegen itself with the ability to interrupt itself and yield some kind of error status. Dan

> Patches to do the kind of checking you're asking about would be > welcome :-). I don't think it makes sense to extend the > Verifier itself here; it's supposed to accept any valid LLVM IR. > I think a separate CodeGenVerifier might be a good approach > though, or possibly extending codegen itself with the ability to > interrupt itself and yield some kind of error status. And I presume you all are allergic to exceptions, since I have seen none so far (probably due to help the C bindings and such), return error c...

...mindDL1 <overminddl1 at gmail.com> wrote: >> Patches to do the kind of checking you're asking about would be >> welcome :-). I don't think it makes sense to extend the >> Verifier itself here; it's supposed to accept any valid LLVM IR. >> I think a separate CodeGenVerifier might be a good approach >> though, or possibly extending codegen itself with the ability to >> interrupt itself and yield some kind of error status. > > And I presume you all are allergic to exceptions, since I have seen > none so far (probably due to help the C bindings and...

> The Verifier pass is recommended; it catches a lot of > invalid stuff and be configured to abort, print an error to > stderr, or return an error status and message string. > > It doesn't catch everything though; codegen's error > handling today is usually an assertion failure, assuming > assertions are enabled. Was looking through some other code in LLVM, I noticed

...e it with the same disgust as I see inline assembly in C code. > To all, I'm moving on and accepting what appears to be the consensus of the list, for now. That said, I believe it would be easy to have levels and prohibit mixing. Just have the Verifier pass reject the new intrinsics. A new CodeGenVerifier pass could be added which accepts them, and tools would run the verifier for the kind of input they expect. There'd be no need to change any existing optimizers. No need to even add any new text to LangRef. The new intrinsics would be documented elsewhere. Also, there's no proposal here...

...at gmail.com> > wrote: >>> Patches to do the kind of checking you're asking about would be >>> welcome :-). I don't think it makes sense to extend the >>> Verifier itself here; it's supposed to accept any valid LLVM IR. >>> I think a separate CodeGenVerifier might be a good approach >>> though, or possibly extending codegen itself with the ability to >>> interrupt itself and yield some kind of error status. >> >> And I presume you all are allergic to exceptions, since I have seen >> none so far (probably due to hel...

On Sep 8, 2008, at 1:39 PM, OvermindDL1 wrote: > On Mon, Sep 8, 2008 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: >> FYI, there is one other issue here, PR2660. While codegen in >> general can handle types like i256, individual targets don't always >> have calling convention rules to cover them. For example, returning >> an i128 on x86-32 or an i256 on

On 26 April 2013 19:49, Tim Northover <t.p.northover at gmail.com> wrote: > > To me, the expanding of regular IR will achieve nearly the same result as > > building a lower level IR. > > Remember that we basically already have a lower level IR consisting of > basic blocks of MachineInstrs at the moment.To an extent this has > already proven itself capable of