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

[Nuno Lopes]

Quoting Duncan Sands <baldrick at free.fr>:

> Hi Chandler,
>
>> 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.
>
> I disagree.  Read-only is what it says: the function only reads  
> memory, doesn't
> write it.  What has that to do with infinite loops?  I would rather  
> see another
> attribute, call it "finite", for functions that can be proved to complete in
> finite time.  Then a function call with no uses can be deleted if read-only,
> nounwind and finite.

I agree with Duncan.
Overloading readonly is not the way to go, since their usage is quite  
different. For example, alias analysis cares about pointers not  
escaping (and readonly/readnone are useful to prove that), but it  
doesn't care about non-terminating functions. BTW, readnone functions  
may not terminate either.
That said, computing termination of loops is a really tricky business.  
We can use SCEV to give a hand, but... Moreover, the termination  
property may depend on the inputs given to the function.
AFAIR, GCC's pure/const function attributes imply terminating behavior.

Nuno