[Bug tree-optimization/36352] New: missed "inlining" of static untouched variable in linked once function

[Bug tree-optimization/36352] New: missed "inlining" of static untouched variable in linked once function

[pinskia at gcc dot gnu dot org]

While looking into PR 36297, I found this interesting missed optimization, it
only happens with linked once functions.  Testcase:
template <int a> int f(void)
{
  static int t = a;
  return t;
}

int g(void)
{
  return f<1>();
}

We should produce return 1 for both functions but currently we reference
f<1>::t .


-- 
           Summary: missed "inlining" of static untouched variable in linked
                    once function
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352

[Bug tree-optimization/36352] missed "inlining" of static untouched variable in linked once function

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-28 08:21 -------
I think this is more of an issue of changing the variable to be readonly than
an "inlining" the variable issue as the following source works as expected:
template <int a> int f(int i)
{
  static const int t = a;
  static const int t1 = a;
  return i?t:t1;
}

int g(void)
{
  return f<1>(1);
}


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|missed "inlining" of static |missed "inlining" of static
                   |untouched variable in linked|untouched variable in linked
                   |once function               |once function


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352

[Bug tree-optimization/36352] missed "inlining" of static untouched variable in linked once function

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-05-28 09:00:31
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352

[Bug tree-optimization/36352] missed "inlining" of static untouched variable in linked once function

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a testcase without templates:
inline int f(void)
{
  static int t = 1;
  return t;
}

int g(void)
{
  return f();
}

[Bug tree-optimization/36352] missed "inlining" of static untouched variable in linked once function

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at redhat dot com

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-11-10 18:17:15 UTC ---
We are not able to declare the var as readonly since we think that it might be
accessed by other module.
This is not true for local static of comdats as we know what that comdat does
with the function, but it is bit difficult to take advantage of this because we
see code after optimization and it is possible that we optimized away the
access in this unit but not in other.

Only way I see to handle this safely is to have ipa-reference done before early
optimization. I tried that some time ago and I know it broke thread local
storage because it does part of job at gimplification and part of job
afterwards leading to confusion when var becomes read only (it stays accessed
as thread local but it is not brought thread local by the later pass). This is
lost optimization.

Jakub, Richard, perhaps the rewrite made this possible?  It would be nice
cleanup.