[llvm-commits] [llvm] r70790 - /llvm/trunk/docs/LangRef.html

[Chris Lattner]

On May 4, 2009, at 12:42 AM, Duncan Sands wrote:
>> I can definitely be convinced :), but my understanding is that the
>> compiler currently deletes readonly/readnone calls if they are dead.
>
> yes, this is a known bug :)

Ok, well I still think it is good to have the docs and code line  
up.  :)  That said, I do agree fully now that decoupling readnone/only  
and nothrow is the right thing to do.

If you want to make this change, please make sure that all of the  
compiler agrees, update llvm-gcc, and fix the docs to be very clear  
about this.  It is probably worth mentioning explicitly that while non- 
nothrow readonly functions are allowed to unwind, they cannot use C++  
EH to do it because it changes global state.

>> We could change this to also require them to be nounwind, and change
>> the C front-ends to have pure/const also add nounwind.  What do you
>> think?
>
> That's my preferred solution.

Ok, I agree that it makes sense.  It would also be good to change llvm- 
gcc to set nounwind on all pure/const functions.

Duncan wrote:
> I had a look at isInstructionTriviallyDead
> and was struck by the fact that it doesn't check isTrapping.  Is it  
> valid
> to delete a divide by zero if the result has no uses?  Currently  
> this is
> done.  If so, is it valid to delete a readonly call even if it may  
> throw
> an exception?


Eli responded:
> Yes, it is valid; division by zero is undefined behavior, so it can do
> anything; we make no attempt to preserve any traps from that.

These are the C semantics, and the semantics that LLVM IR currently  
has.  However, in the future, we will probably end up extending LLVM  
IR to better serve other languages.  In a language that requires a  
trap to be generated for things like this (and/or null pointer  
dereferences etc), then an exception could be generated.  The  
optimizer will have to be careful not to do unsafe transformations.   
For example, a function that loads a potentially null pointer and is  
supposed to trap on it cannot be deleted if dead, but it can be CSE'd.

-Chris