On April 9, 2016 1:17:51 PM GMT+02:00, Richard Biener <rguent...@suse.de> wrote: >On April 8, 2016 10:00:58 PM GMT+02:00, Jakub Jelinek ><ja...@redhat.com> wrote: >>On Fri, Apr 08, 2016 at 09:14:33PM +0200, Richard Biener wrote: >>> Hmm, I think this means GIMPLE_has_side_effects is to be fixed then. >> >>> Note that honza had plans to compute things like 'uses FP' and >>'contains arith with undefined overflow' and propagate that alongside >>pure/const-ness. >>> >>> Can you try to asses the impact of fixing no-side-effects? >> >>That sounds extremely risky to me, there are lots of callers of that, >>and >>many really don't care, they e.g. check if they can remove the stmt, >or >>if it can be moved towards the exit block, etc. >>Plus even other side-effects like maybe throwing are not included in >>gimple_has_side_effects and are tested separately. >>Maybe just return true on all calls in gimple_could_trap_p, but even >>that >>has 5 other callers that would need to be carefully analyzed. Even >>that >>looks too risky for late stage4 to me. > >I agree, but even PPRE may cause wrong code in this case, phiopt comes >to myind as well as ifcvt. So this is papering over an issue in our >infrastructure really. > >Let me think about this some more after returning from my sick leave. > >Your patch is OK for trunk (with a comment added), but please make sure >a bug is left open for the general issue.
To followup myself here - we can also make sure the function doesn't become pure/const. Similar issues exist with pure/const functions with ops with undefined overflow (and code gen taking advantage of that). So it's not only trapping that needs to be guarded against... :/ Richard. >Richard. > >> Jakub
