[Bug c/105728] New: dead store to static var not optimized out

[Bug c/105728] New: dead store to static var not optimized out

[felix-gcc at fefe dot de]

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

            Bug ID: 105728
           Summary: dead store to static var not optimized out
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

Consider this piece of test code:

int dummy1()
{
  static int removeme = 0;
  if (removeme)
  {
      return 0;
  }
  removeme = 1;
  return 0;
}

int dummy2()
{
  static int removeme = 0;
  if (!removeme)
    removeme = 1;
  return 0;
}

int dummy3()
{
  static int removeme = 0;
  removeme = 1;
  return 0;
}

To me, all of these do the same thing and should generate the same code.
As nobody else can see removeme, and we aren't leaking its address, shouldn't
the compiler be able to deduce that all accesses to removeme are
inconsequential and can be removed?

My gcc 11.3 generates a condidion and a store and a return 0 for dummy1, the
same thing for dummy2, but for dummy3 it understands that it only needs to emit
a return 0.

Re: [Bug c/105728] New: dead store to static var not optimized out

[Jan Hubicka]

> To me, all of these do the same thing and should generate the same code.
> As nobody else can see removeme, and we aren't leaking its address, shouldn't
> the compiler be able to deduce that all accesses to removeme are
> inconsequential and can be removed?
> 
> My gcc 11.3 generates a condidion and a store and a return 0 for dummy1, the
> same thing for dummy2, but for dummy3 it understands that it only needs to emit
> a return 0.

GCC detects "write olny" variables and that is what matches for dummy3.
I am not 100% sure it is valid to do the optimization in other two cases
since when multiple threads are considered. In any case we lack tracking
of constants stored to global variables which is something ipa-cp can be
extended to.

Honza

[Bug c/105728] dead store to static var not optimized out

[hubicka at kam dot mff.cuni.cz]

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

--- Comment #1 from hubicka at kam dot mff.cuni.cz ---
> To me, all of these do the same thing and should generate the same code.
> As nobody else can see removeme, and we aren't leaking its address, shouldn't
> the compiler be able to deduce that all accesses to removeme are
> inconsequential and can be removed?
> 
> My gcc 11.3 generates a condidion and a store and a return 0 for dummy1, the
> same thing for dummy2, but for dummy3 it understands that it only needs to emit
> a return 0.

GCC detects "write olny" variables and that is what matches for dummy3.
I am not 100% sure it is valid to do the optimization in other two cases
since when multiple threads are considered. In any case we lack tracking
of constants stored to global variables which is something ipa-cp can be
extended to.

Honza

[Bug ipa/105728] dead store to static var not optimized out

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |ipa
   Last reconfirmed|                            |2022-05-27
     Ever confirmed|0                           |1
           Keywords|                            |missed-optimization
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
the dummy1/dummy2 optimizations could eventually be done by DCE if we knew that
'removeme' is only ever accessed from 'dummy1' / 'dummy2', in that case we
could consider the variable local and since there's no data dependence on it
we could elide it.

Don't we track that already in IPA?  I think local passes cannot rely on
IPA references?  We also need to consider

void foo (int *);
int dummy1()
{
  static int removeme = 0;
  static int *p = &removeme;
  foo (p);
  if (removeme)
  {
      return 0;
  }
  removeme = 1;
  return 0;
}

thus global CTORs (the above will see the init in dummy1(), but not sure
whether we can rely on that?)

[Bug ipa/105728] dead store to static var not optimized out

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, any such optimization would be prone to remove 'debug_cnt' in

void foo()
{
  static int debug_cnt = 0;
  debug_cnt++;
  .. stuff ..
}

because here nothing depends on debug_cnt.  For some printf-style
debugging that might be surprising.  It of course already happens for

void foo()
{
  static bool ever_reached = false;
  ever_reached = true;
}

[Bug ipa/105728] dead store to static var not optimized out

[felix-gcc at fefe dot de]

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

--- Comment #4 from felix-gcc at fefe dot de ---
If you do have a printf that references debug_cnt, it wouldn't be removed,
right?

If you expect unreferenced variables to not be optimized out, you can always
compile without optimizer. For local variables even that doesn't help with
clang already.

OTOH we do have attributes "used" and "unused". They could be extended to
variables.