This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I don't like (and see the point of) path-splitting but the patch was to avoid a
regression with PRE code-hoisting.  The path-splitting code is incredibly
stupid
when it comes to cost modeling.  That is, it tries to expose CSE but doesn't
actually verify there is any likeliness in achieving that.  In fact, if the
block we duplicate (the latch) doesn't contain any stmts (in this case just
the IV increment) then there is _zero_ CSE possibility.  Improving
path-splitting
for this case is welcome.  Or just remove that stupid pass and wire it into
a pass that can actually (opportunistically) perform the CSE before deciding
to duplicate the tail.

Note that unrolling likely gives up because of the loop now having two latches?

Note that there was a plan to move RTL unrolling (-funroll-loops) to GIMPLE,
but that wouldn't affect fallout like SMS not being able to unroll (not sure
if that can handle conditional code at all).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]