search for: resumeinst

...cleanup ret i32 1 } declare i32 @__gxx_personality_v0(...) Instruction:: mayThrow returns false for the invoke. This is because ... bool Instruction::mayThrow() const { if (const CallInst *CI = dyn_cast<CallInst>(this)) return !CI->doesNotThrow(); return isa<ResumeInst>(this); } CallInst != InvokeInst, and invokeinst is not derived from callinst. Am I missing something, or should this function also have: if (const InvokeInst *II = dyn_cast<InvokeInst>(this)) return !II->doesNotThrow(); ? -------------- next part -------------- An HTML attachmen...

Hi, On Fri, Sep 20, 2019 at 6:48 AM Matthew Malcomson <Matthew.Malcomson at arm.com> wrote: > > Hello again, > > I have been thinking more about the GCC implementation of hwasan and > found a few more questions that I would really appreciate help with. > > --- > I've noticed a match-all condition in the compiler inline > instrumentation, but can't see

...e sure it handles the new resume forms correctly, > I wonder if it might be helpful to give resume (or the new forms of it) a > different name, since then it would be immediately clear which code > has/hasn't been updated to the new model. > There aren't that many references to ResumeInst across LLVM, so I'm not too scared. I'm not married to reusing 'resume', other candidate names include 'unwind' and 'continue', and I'd like more ideas. > - Is the idea that a resume (of the sort that resumes normal execution) > ends only one catch/cleanu...

...t; -/// mayThrow - Return true if this instruction may throw an exception. >>> -/// >>> bool Instruction::mayThrow() const { >>> if (const CallInst *CI = dyn_cast<CallInst>(this)) >>> return !CI->doesNotThrow(); >>> return isa<ResumeInst>(this); >>> } >>> >>> +bool Instruction::mayReturn() const { >>> + if (const CallInst *CI = dyn_cast<CallInst>(this)) >>> + return !CI->doesNotReturn(); >>> + return true; >>> +} >>> + >>> /// isAs...

...thing about this design is that there are no scopes in normal control flow. The scoping is all built into the EH blocks, which most optimization passes don't care about. If you do a quick search through lib/Transforms, you'll see there are very few passes that operate on LandingPadInst and ResumeInst. Changing these instructions is actually relatively cheap, if we can agree on the new semantics. > Also, I think, if we want to eventually support trapped operations (some > kind of invoke div_with_trap mentioned in another thread), wouldn't it be > way easier to implement and optimi...

On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-15 18:37:58 -0400, Reid Kleckner said: > > After a long tale of sorrow and woe, my colleagues and I stand here >> before you defeated. The Itanium EH representation is not amenable to >> implementing MSVC-compatible exceptions. We need a new representation that >> preserves

After a long tale of sorrow and woe, my colleagues and I stand here before you defeated. The Itanium EH representation is not amenable to implementing MSVC-compatible exceptions. We need a new representation that preserves information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,