Question about UnreachableInst and exit() system call

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about UnreachableInst and exit() system call

Prakash Prabhu
Hi,

I have a question about how clang handles exit() calls.  It seems that two instructions (when -emit-llvm is used) are generated : CallInst followed by UnreachableInst.  While this makes perfect sense from semantics/optimization/correctness perspective, I am curious to know whether it is possible to treat exit() like any other library call (ie, generate a BranchInst  instead of UnreachableInst)  via a compile time switch/option ? Any pointers to the relevant code (for handling exit()) within clang will also be very helpful.

I am asking because some of the analysis I am writing in the backend would be easier if I did not have to deal with exit() as a special case (mainly to do with structured control flow).

thanks,
Prakash

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about UnreachableInst and exit() system call

Chris Lattner

On May 13, 2010, at 11:48 PM, Prakash Prabhu wrote:

> Hi,
>
> I have a question about how clang handles exit() calls.  It seems that two instructions (when -emit-llvm is used) are generated : CallInst followed by UnreachableInst.  While this makes perfect sense from semantics/optimization/correctness perspective, I am curious to know whether it is possible to treat exit() like any other library call (ie, generate a BranchInst  instead of UnreachableInst)  via a compile time switch/option ? Any pointers to the relevant code (for handling exit()) within clang will also be very helpful.
>
> I am asking because some of the analysis I am writing in the backend would be easier if I did not have to deal with exit() as a special case (mainly to do with structured control flow).

Hi Prakash,

It's generally better to send questions about LLVM IR to the llvmdev list.  In this case, I'm not really sure.  It sounds like you should handle general LLVM IR.  Trying to special case things is a recipe for fragile code.

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev