[llvm-commits] [PATCH] treat calls to noreturn functions as side effecting

[Chandler Carruth]

On Sat, Jul 21, 2012 at 1:09 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Chandler, I think this is all about read-only functions that may do
> infinite
> loops.
>

I'm firmly in the camp that infinite loops without side-effects should be
deleted. It is easy to introduce a side-effect if that is so-desired.

That said, if you want infinite loops to be "observable", and not be
deleted from the program, you should similarly not mark a function
containing such a loop (or noreturn for any other reason) as 'readonly'.
This shouldn't have anything to do with making the *call* have
side-effects, it should be about making the *function* have side-effects,
whether through calling an infinite loop a side-effect, or through a proper
side-effect such as a volatile memory access or I/O operation.


>
> Ciao, Duncan.
>
> On 21/07/12 09:32, Chandler Carruth wrote:
> > On Fri, Jul 20, 2012 at 10:05 AM, Richard Osborne <richard at xmos.com
> > <mailto:richard at xmos.com>> wrote:
> >
> >     Currently at -O2 a call to a readonly noreturn function (e.g. a
> function
> >     consisting of while(1)) is replaced by unreachable, which seems
> somewhat nasty.
> >
> >
> > If it's readonly, it shouldn't be observable, and so it seems reasonable
> to
> > remove it.
> >
> > If it has some special observable significance, it should read from a
> volatile
> > variable or otherwise cause itself to have a side-effect. This will in
> turn
> > cause the call to have the side-effect.
> >
> >     The following sequence of transforms are responsible:
> >
> >     1) prune-eh adds unreachable after the call (since it has the
> noreturn
> >     attribute)
> >     2) early-cse removes the call to the function (since it has the
> readonly
> >     attribute).
> >
> >     This patch makes Instruction::hasSideEffect() return true for
> functions
> >     marked with the no return attribute avoid this.
> >     To be completely correct early-cse (and others) should be updated so
> that
> >     they only delete calls to functions that provably always return (or
> are
> >     marked as such) - see PR965. While this would be nice to fix it is
> also a
> >     much bigger slice of work.
> >
> >     Does this patch seem reasonable?
> >
> >     --
> >     Richard Osborne | XMOS
> >     http://www.xmos.com
> >
> >
> >     _______________________________________________
> >     llvm-commits mailing list
> >     llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> >     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120721/ebedec08/attachment.html>