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

[Chandler Carruth]

On Sat, Jul 21, 2012 at 2:54 AM, Richard Osborne <richard at xmos.com> wrote:

>  Yes, this is about infinite loops and it isn't me marking the function
> readonly - its the -functionattrs pass.
>

When I said "you" I merely meant whatever passes you're running. It seems
natural that it is the functionattrs pass.


>  Consider the following example:
>
>  void f() {
>   while(1) {}
> }
>
>  int main() {
>   f();
>   return 0;
> }
>
>  I'm seeing the following sequence of transforms:
>
>  1) -prune-eh marks f() as noreturn
> 2) -prune-eh replaces the code after the call to f() in main with
> unreachable.
> 2) -functionattrs marks f() as readnone.
> 3) -early-cse deletes the call to f().
>
>  The net effect is more than just having the loop deleted
>

I actually think the net effect is in essence the same as having the loop
deleted. =/ If all we did was delete the loop, 'f()' would contain just an
unreachable instruction. Everything past the call to f would still be
deleted, and the call would be followed by an unreachable instruction. If
you ran the program it would still crash.

Anyways, LLVM, much to my regret, decided to make infinite loops a magical
observable side-effect, and not delete them. One of the consequences of
this decision is that there is one of two bugs in the current system now:

1) functionattrs shouldn't mark functions with infinite loops as readonly,
or
2) noreturn functions should have the same "observable" property as
infinite loops.

As there are many noreturn functions which do not have infinite loops and
to which this magical property really shouldn't apply, I strongly prefer
#1. It also clarifies the cost of this treatment of infinite loops -- they
are implicitly a side-effect carrying construct.

So in essence, I think this is a bug in functionattrs which stems from the
decision to not delete infinite loops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120721/fcccd111/attachment.html>