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

[Duncan Sands]

Hi Chris,

> >> throw
> >> is the empty set. :)  Thanks to Fritz for pointing this out.
> >
> > what's wrong with a readonly function using unwind?  I think
> > the use of unwind is orthogonal to readonly: it's what the
> > nounwind attribute is for.  Of course a readonly function can't
> > call the C++ throw routine etc, but that's a different issue.
> > If you want readonly to mean: doesn't do anything annoying
> > (no side-effects), then the name should be changed, and the
> > function attributes taught to do loop analysis and not mark
> > a function readonly unless all loops are finite etc.  I think
> > it is better to keep readonly and nounwind separate.
> 
> 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 :)

> 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.  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?

Ciao,

Duncan.