[LLVMdev] disable insertion of unreachables

Max Stonebraker max.stonebraker at gmail.com
Tue Sep 8 22:16:43 PDT 2009


> if so, the assembly language docs say that
> program behavior is undefined if such a function
> ever returns.

Yes, that's true, but for some static analysis applications such as control
dependence analysis for programs that have arbitrary interprocedural control
flow, one needs these additional non-executable control flow edges from
noreturn functions to their immediate CFG successor.

Is there any way to avoid having the unreachables inserted in the first
place?

Max


On Sun, Sep 6, 2009 at 2:55 PM, Kenneth Uildriks <kennethuil at gmail.com>wrote:

> What do you mean by "terminating function call"?  Is it one with the
> "noreturn" attribute?  if so, the assembly language docs say that
> program behavior is undefined if such a function ever returns.  If
> your function could possibly return, it needs to not have that
> attribute.
>
> On Sun, Sep 6, 2009 at 4:49 PM, Max
> Stonebraker<max.stonebraker at gmail.com> wrote:
> > Hello all,
> >
> > LLVM inserts unreachable instructions after every call to a terminating
> > function. Is there a way to disable this feature so that it treats
> > terminating function calls like any other function call, so the
> unreachable
> > instruction would not be inserted? Unfortunately, simply removing the
> > unreachable instructions after the fact would not suffice for my needs
> > because I need to preserve the original control flow of the program. That
> > is, I need to know the instruction that would have been executed if the
> call
> > to the terminating function didn't actually terminate the program.
> >
> > Thanks!
> >
> > Max
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090908/996f9a0c/attachment.html>


More information about the llvm-dev mailing list