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

[Evan Cheng]

Can someone summarize the current plan to address this? The current behavior is fairly unfriendly and I don't see it providing any benefit. I would love to see it fixed. :-)

Evan

On Jul 24, 2012, at 3:15 AM, Duncan Sands <baldrick at free.fr> wrote:

> 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.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits