search for: pr1269

...veloper's Meeting (http://llvm.org/DevMtgMay2007.html :) .. snip .. > So here are a few questions whose answers will help me go through this issue > 1) Is the Chris' exception handling note actually implemented or is it > still in project? I have signed up to implemented this (PR1269) just as Chris' note states. HLVM needs it for much the same reason that VVM does. I hope to address this in late April. I'm not sure if it will make it into the 2.0 release (if it does, it will be close). > And how difficult do you expect it to be? (Even if I have implemented > som...

The Random LLVM Notes lists <http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt> Improvements to EH support ( <http://llvm.org/PR1269> PR1269). See whether the approach of FIRM, an Intermediate Represenation based on SSA, is useful Chapter 2.3 Exceptions of Documentation of the Intermediate Representation. Accessible via http://citeseer.ist.psu.edu/550469.html Greetings, pet-ro -------------- n...

...g a > combined memory dereference and jump on null instruction. LLVM doesn't > seem to have anything similar - I was thinking I might simulate this by > adding a new instrinsic for potentially faulting memory references. Does > anyone have any ideas on this? see http://llvm.org/PR1269 (support for non-call exceptions). If you are only interested in null dereferences, I suggest you insert explicit checks for null pointers for the moment, branching to a "throw" if one is found. Ciao, Duncan.

...gt; > Interesting project. I wish you could talk about it at the Developer's > Meeting (http://llvm.org/DevMtgMay2007.html :) > > I wish I could! Unfortunately there is very little chance I get the fundings to go to the US in May. > > I have signed up to implemented this (PR1269) just as Chris' note > states. HLVM needs it for much the same reason that VVM does. I hope to > address this in late April. I'm not sure if it will make it into the 2.0 > release (if it does, it will be close). > That's great news! I'll look at the PR to see if I c...

Hi, Is it possible to add edges to the CFG from instructions that reference memory to exception landing pads? I want to do this so that I can convert SEGV signals into exceptions that can be safely unwound and caught. My compiler's existing code generator handles this by having a combined memory dereference and jump on null instruction. LLVM doesn't seem to have anything similar - I was

Hi everyone, After some time hacking on llvm, let me introduce myself :) I'm a PhD student at the French university Pierre et Marie Curie in Paris. I work on a project called the "Virtual Virtual Machine" project. You can find some (dated) information on the website http://vvm.lip6.fr. Basically it's a "low level virtual machine" :) with a just in time compiler

...eaked too. Unfortunately this approach immediately hits PR1508 (http://llvm.org/bugs/show_bug.cgi?id=1508), i.e. the problem of actually finding the selector for a landing pad. Personally I would like to see the selector somehow be attached to the unwind edge - perhaps it could be done as part of PR1269. > > ... It is true that you can imagine a solution in which the inliner > > knows about selector calls > > and shuffles them around. I will think about this. That said, > > invoke is defined to have > > certain semantics, and I don't much like the idea of t...

On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote: > Hi Dale, > >> #include <cstdio> >> class A { >> public: >> A() {} >> ~A() {} >> }; >> void f() { >> A a; >> throw 5.0; >> } >> main() { >> try { >> f(); >> } catch(...) { printf("caught\n"); } >> } > > this example

I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe

...roach immediately hits > PR1508 (http://llvm.org/bugs/show_bug.cgi?id=1508), i.e. the problem > of actually finding the selector for a landing pad. Personally I > would > like to see the selector somehow be attached to the unwind edge - > perhaps > it could be done as part of PR1269. > >>> ... It is true that you can imagine a solution in which the inliner >>> knows about selector calls >>> and shuffles them around. I will think about this. That said, >>> invoke is defined to have >>> certain semantics, and I don't much lik...

...ld establish IR rules that such join points need to reset the EH state, but then we have to go and teach optimizers about it. It's basically a no-IR-modifications version of labelling each BB with an unwind label, which is something that's been proposed before more directly: http://llvm.org/PR1269. Personally, I think we could make this change to LLVM IR, but at a great cost. Implicit EH control flow would open up a completely new class of bugs in LLVM optimizers that doesn't exist today. Most LLVM hackers working on optimizations that I talk to *REALLY* don't want to carry the burd...