search for: doesnotthrow

.....)* @__gxx_personality_v0 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 -...

On 10 February 2014 03:44, Renato Golin <renato.golin at linaro.org> wrote: > On 10 February 2014 02:59, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> It has to be an attribute because of LTO. You can LTO a file compiled >> with -fasynchronous-unwind-tables and one with >> -fno-asynchronous-unwind-tables. That is why we have the uwtable >>

...exact behaviour of the current 'nounwind' attribute found on functions, calls and invokes. I was thinking these would be similar to the AA analysis notes like "doesNotAccessMemory" which is a provable property of the function or call site being analyzed. Duncan mentioned that doesNotThrow is actually an important language semantic meaning that an unwind calls a language-defined behaviour such as calling terminate(). What happens in other languages? Chris and I also couldn't agree on what the semantics ought to be going forward. He suggested having two bits, one to memoize a...

...lacks information to allow an exception to be handled. >> I am not too sure about nounwind. I think it is more about using >> unwind for control flow in the language. Having it allows us >> to prune information used for exception handling. > > nounwind translates into "doesNotThrow()", which is *also* used on > "needsUnwindTables()" which is used in "needsCFIMoves()". > > It's not simple. ;) > > cheers, > --renato Cheers, Rafael

...the current 'nounwind' attribute found on functions, calls and invokes. > > I was thinking these would be similar to the AA analysis notes like > "doesNotAccessMemory" which is a provable property of the function or > call site being analyzed. Duncan mentioned that doesNotThrow is actually > an important language semantic meaning that an unwind calls a > language-defined behaviour such as calling terminate(). What happens in > other languages? > > Chris and I also couldn't agree on what the semantics ought to be going > forward. He suggested hav...

...} >>> } >>> >>> -/// 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; >>&...

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

...nor capture the pointer (or + // return it) to do unsafe writes to it elsewhere. The function also + // shouldn't unwind (a readonly function can leak bits by throwing an + // exception or not depending on the input value). + if (CS.onlyReadsMemory() /* && CS.doesNotThrow()*/ && + I->getType()->isVoidTy()) + continue; + + // LLVM 'nocapture' attribute is only set for arguments whose address + // is not stored, passed around, or used in any other non-trivial way. + // We assume that passing a pointer to a...