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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |missed-optimization
   Last reconfirmed|                            |2016-02-08
          Component|c                           |tree-optimization
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|excessive stack usage with  |[4.9/5/6 Regression]
                   |-fprofile-arcs              |excessive stack usage with
                   |                            |-fprofile-arcs, LIM store
                   |                            |motion lacks a register
                   |                            |pressure aware cost model
   Target Milestone|---                         |4.9.4

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We're more aggressively moving coverage counter updates out of loops by
promoting
them to registers.  That might cause extra spilling due to increased register
pressure.

Confirmed.  -fno-tree-loop-im "fixes" the regression.

Caused by (I'm quite sure, but not actually verified):

2014-03-21  Richard Biener  <rguent...@suse.de>

        PR tree-optimization/60577
        * tree-core.h (struct tree_base): Document nothrow_flag use
        in DECL_NONALIASED.
        * tree.h (DECL_NONALIASED): New.
        (may_be_aliased): Adjust.
        * coverage.c (build_var): Set DECL_NONALIASED.

which fixed a regression from earlier releases that did not properly do
alias analysis for those (and thus applied store-motion to them anyway).

In general store motion lacks a cost model taking into account register
pressure increase of its transform.  That's a know deficiency.  Ideally we'd
have a later
pass undo the transform rather than limiting the transform here.

Reply via email to