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

[Duncan Sands]

Hi Richard,

>>>> That said, computing termination of loops is a really tricky business.
>>> this is probably why no one implemented this :)
>> But I have implemented this:
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103998.html
>>
>> One of the truly unfortunate quirks in the implementation is that
>> FunctionAttrs is a CGSCC pass and we need SCEV which is a FunctionPass,
>> and that doesn't work. Chandler is working on fixing that. The patch in
>> that link actually handles it by having a dumb ModulePass analysis that
>> uses SCEV, and that FunctionAttrs uses. Lunacy.
>>
>> Chris was concerned that it we wouldn't be able to solve it much of the
>> time, as seen in this paragraph:
>>
>>   > The other thing that concerns me is that there is a lot of cases that
>>   > really can't be handled.  Iterating over an std::map or another
>> node-based
>>   > container can't be handled with this.  If you have some sort of front-end
>>   > attributes (like the halting attribute you proposed for clang) or other
>>   > language semantics that would be useful, then it makes sense.
>>
>> but I think that's something we have to live with. I eventually gave up
>> on the thread because I wasn't able to easily find examples of things
>> that were broken with the current status quo.
>>
>> Nick
> Yes, I saw this thread - I didn't try and resurrect your patch because I
> suspected I'd run into the same problems you did (CGSCC pass needing a function
> pass). I wanted to do something simpler which, while not a complete fix to PR965
> would still be an improvement on the current situation. If people don't think
> this isn't a useful step on the way then I think it would be best to leave this
> issue for now and revisit it after the proposed changes to the pass manager have
> landed.

once this attribute is in then your patch would no longer be useful.  In the
example you mentioned of a read-only noreturn function, the function would not
be marked finite and so the call to it would not be removed.  Maybe it is OK as
a workaround if the pass manager fixes and "finite" attribute won't make it into
the 3.2 release.

Ciao, Duncan.