[llvm] r175553 - Fix a bug in mayHaveSideEffects. Functions that do not return are now considered as instructions with side effects.

[Hal Finkel]

----- Original Message -----
> From: "Duncan Sands" <baldrick at free.fr>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu, "Nadav Rotem" <nrotem at apple.com>
> Sent: Thursday, February 21, 2013 2:29:23 AM
> Subject: Re: [llvm] r175553 - Fix a bug in mayHaveSideEffects. Functions that do not return are now considered as
> instructions with side effects.
> 
> Hi Hal,
> 
> > I think that we may want to adopt an N1528-like viewpoint on this
> > and say that functions that don't return have undefined
> > behavior/semantics unless explicitly marked.
> >
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm
> 
> this is an interesting approach, but I'm not sure it is feasible for
> other
> languages like Ada which doesn't allow the compiler to assume that
> all loops
> are finite.  How is Ada to be turned into LLVM IR with this rule?  It
> can't
> just output functions maybe containing infinite loops without special
> care
> (eg without a noreturn marker), like it does now, because the
> optimizers might
> mis-optimize (according to Ada semantics).  On the other hand, it
> can't just
> add noreturn everywhere that it thinks maybe there might be an
> infinite loop,
> because what if there isn't?

True, we don't want to assume all code after every call is unreachable ;) -- maybe we should mark these functions as 'may_not_return' (or something like that) which would also imply mayHasSideEffects (like noreturn) but would not imply that code following the call is unreachable.

On the other hand, if this is really a question about side effects (and I suppose that it is), as opposed to unreachability, then I agree with your initial point. Any unknown function may have side effects (unless it is specifically marked otherwise (e.g. readnone)).

 -Hal

> 
> Ciao, Duncan.
>