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

[Richard Osborne]

Yes, this is about infinite loops and it isn't me marking the function readonly - its 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 - main ends up containing a single unreachable instruction and it crashes at runtime when execution falls through to whatever happens to be after main(). Using the fact that the loop is infinite to delete the code after the call and then ignoring the fact it is infinite to delete the call itself seems nasty to me.

On 21 Jul 2012, at 09:26, Chandler Carruth wrote:

On Sat, Jul 21, 2012 at 1:09 AM, Duncan Sands <baldrick at free.fr<mailto: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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120721/41e34436/attachment.html>