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 rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level


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

--- Comment #5 from Patrick Marlier <patrick.marlier at gmail dot com> ---
The regression starts from this commit:

trunk@200103
commit f82f0ea592c2d78077e03f5a1a3b9b40751cc116
Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri Jun 14 18:52:32 2013 +0000

        * gimple.h (gimple_can_coalesce_p): Prototype.
        * tree-ssa-coalesce.c (gimple_can_coalesce_p): New function.
        (create_outofssa_var_map, coalesce_partitions): Use it.
        * tree-ssa-uncprop.c (uncprop_into_successor_phis): Similarly.
        * tree-ssa-live.c (var_map_base_init): Use TYPE_CANONICAL
        if it's available.

        * gcc.dg/tree-ssa/coalesce-1.c: New test.

And especially from this:
gcc/tree-ssa-coalesce.c:gimple_can_coalesce_p (tree name1, tree name2)
...

  /* If the types are not the same, check for a canonical type match.  This
     (for example) allows coalescing when the types are fundamentally the
     same, but just have different names. 

     Note pointer types with different address spaces may have the same
     canonical type.  Those are rejected for coalescing by the
     types_compatible_p check.  */

  if (TYPE_CANONICAL (t1)
      && TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2)
      && types_compatible_p (t1, t2))
    return true;

But as Richard mentioned, I think the problem is in the RTL part.


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