[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-05 15:49:44 UTC --- Another approach is to not create CLOBBERs in the outermost scope at all but re-create those during inlining when building the containing BLOCK. That would probably avoid CLOBBERs for most C code that is not inlined.
[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 --- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-12-05 16:02:10 UTC --- As said, this would still require ugly fiddling with exception edges. Getting rid of some of the clobbers a posteriori seems cleaner.
[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|pinskia at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-29 22:54:16 UTC --- Actually I was just posting a first pass at fixing this and not really doing a full patch just yet.
[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-23 10:54:07 UTC --- The question is if we should do this in the fab pass or elsewhere. Also, I'm afraid it is O(n^2) compile time written this way, consider a basic block containing 10 clobber stmts followed by a normal assignment, optimize_clobbers will return 10 times false in that case, the first call will walk through 11 stmts, second call through 10 stmts, third through 9 stmts, etc. to find that out. So, IMHO it would be better to call optimize_clobbers not for each clobber stmt, but instead for the GIMPLE_RETURN or GIMPLE_RESX and walk backwards from it. BTW, for the internal GIMPLE_RESX I think we perhaps could move over the clobber stmts to where the exception would land.
[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 --- Comment #4 from Michael Matz matz at gcc dot gnu.org 2011-11-23 14:12:11 UTC --- Andrew: yes, I considered something similar. To work really well it requires some changes to the conflict generation code, though. Without the clobbers all objects stay live on the exit-block entry and therefore conflict (and hence won't be shared). Conflicts generated only because of the exit block need to be ignored. As Jakub says, the implementation should be improved by walking from the exit block upwards. fab seems like the wrong place to do this. Something like DSE feels more natural perhaps. But it's correct that the removal should happen after inlining but before eh optimizations.
[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-23 00:40:40 UTC --- I think this patch has a bug in it when dealing with DEBUG_STMT's.
[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Attachment #25890|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-23 AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-23 01:50:53 UTC --- Created attachment 25892 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25892 New patch Here is a new patch which fixes the DEBUG_STMT issue which I thought of after I created the bug.
