[Bug c++/102876] New: GCC fails to use constant initialization even when it knows the value to initialize

[Bug c++/102876] New: GCC fails to use constant initialization even when it knows the value to initialize

[redbeard0531 at gmail dot com]

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

            Bug ID: 102876
           Summary: GCC fails to use constant initialization even when it
                    knows the value to initialize
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

See: https://godbolt.org/z/KnKv9j8b9

#include <chrono>
using namespace std::literals;
/*not constexpr*/ inline std::chrono::sys_days compute_days() {
    return 1776y/7/4;
}
std::chrono::sys_days BURN_IN_TO_BINARY = compute_days();

Clang and MSVC both correctly burn BURN_IN_TO_BINARY into the binary image with
the correct value. Even with -O3, gcc zero-initializes it then uses a dynamic
initializer to complete the initialization. Both are valid implementation
strategies according to https://eel.is/c++draft/basic.start.static#3, however,
I think the strategy used by clang and MSVC is clearly superior QoI here.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
   Last reconfirmed|                            |2021-10-21
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Why not just make the function constexpr though?

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org
            Version|unknown                     |11.2.0

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's known that other compilers try to consteval things that are not in const
context, esp. for initializers.  We should think of doing the same (IIRC I saw
patches from Jason flowing by treating inline functions as constexpr
opportunistically).

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[redbeard0531 at gmail dot com]

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

--- Comment #3 from Mathias Stearn <redbeard0531 at gmail dot com> ---
> Why not just make the function constexpr though?

That isn't always possible. Sometimes the initializer may call a third-party
function that is inline, but not yet marked constexpr (it may need to support
older language versions where it couldn't be constexpr). Other times the
initializer may call a function that is out of line (so can't be constexpr at
all), but defined in the same TU. MSVC and clang handle this somewhat more
realistic example nicely, gcc doesn't: https://godbolt.org/z/jYKx8359T

The original example using chrono was just something that when reading I
thought "any optimizer worth its salt should be able to do this even without
explicit constexpr annotation". I was disappointed to learn that gcc couldn't,
so I filed a bug in the hope that it can be improved.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |4131
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The example in comment #3 is basically PR4131 I think.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug 4131] The C++ compiler doesn't place a const class object to ".rodata"
section with non trivial constructor

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, for comdat variables (inline vars, variable templates) we need to be
careful, see PR99456 ABI discussions whether it is ok to change whether
something is initialized dynamically or statically.
When the function isn't constexpr though, trying to evaluate it as
non-manifestly constant evaluated expression will fail though, so we'd need
some even less pedantic constant expression evaluation mode that would handle
inline non-constexpr functions as if they were constexpr.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
It's not clear to me that this optimization should use the constexpr machinery;
as I commented on bug 4131.  If optimization turns the initialization of a
static variable into a simple matter of storing a constant value, it should go
one step further and turn that constant value into a constant initializer.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
But yes, the implicit constexpr patch I've been working on would likely improve
this as well.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #6)
> It's not clear to me that this optimization should use the constexpr
> machinery; as I commented on bug 4131.  If optimization turns the
> initialization of a static variable into a simple matter of storing a
> constant value, it should go one step further and turn that constant value
> into a constant initializer.

I guess that would be possible, a targetted optimization pass for
__static_initialization_and_destruction_* and _GLOBAL__sub_I_* functions (or
just the latter).
It would need to be done after IPA and after various optimization passes
afterwards so that the functions can be optimized enough, on the other side
with some further optimization passes still to go, so that when we optimize
away all the stores something can cleanup the function and some further
optimization can kick in and kill empty _GLOBAL__sub_I_* functions altogether.
For each dynamically initialized var it would probably need to try to build
updated DECL_INITIAL CONSTRUCTOR (starting from the one the var has if any),
maybe punt whenever some particular leaf field is initialized multiple times,
certainly punt if initialized by non-constant, maybe punt if a union has more
than one field initialized, etc.
But I'm worried about larger TUs where not all dynamic initialization can be
optimized into constants.  E.g. if there remain any function calls where the
alias analysis could think they can read or modify the vars or their subobjects
etc., we'd need to punt.
Perhaps we could when generating these functions wrap the dynamic
initialization of each var by calls into some new IFN that would take address
of the variable and for alias analysis say it reads it but doesn't modify and
doesn't escape the address.  In C++ one can't read the var in other
initializers until it has been constructed, right?  So the opening IFN would
stand as the first stmt that may read or write the variable and similarly
everything after the closing IFN would be considered unrelated code to that.
Not sure if we can reliably detect that the variable was declared read-only and
isn't TREE_READONLY only because it has dynamic initialization (and that it is
safe to optimize it into a .rodata var).
And, probably it would be best if we could arrange for post-IPA to handle these
global initialization functions as early as possible so that we don't need to
give up because the vars were already emitted into assembly.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> But I'm worried about larger TUs where not all dynamic initialization can be
> optimized into constants.  E.g. if there remain any function calls where the
> alias analysis could think they can read or modify the vars or their
> subobjects etc., we'd need to punt.

Would we?  If the variable isn't const, it's OK for later initializers to
modify its value, I wouldn't think that would prevent us from turning its
initializer into a constant value.

> Perhaps we could when generating these functions wrap the dynamic
> initialization of each var by calls into some new IFN that would take
> address of the variable and for alias analysis say it reads it but doesn't
> modify and doesn't escape the address.  In C++ one can't read the var in
> other initializers until it has been constructed, right?  So the opening IFN
> would stand as the first stmt that may read or write the variable and
> similarly everything after the closing IFN would be considered unrelated
> code to that.

This seems like a more general issue: after a variable declared const has
completed its initialization, it can't be modified.  Would this be useful to
mark, kind of like we use a clobber for end of life?

> Not sure if we can reliably detect that the variable was declared read-only
> and isn't TREE_READONLY only because it has dynamic initialization (and that
> it is safe to optimize it into a .rodata var).

Can't you just look at the type?

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > But I'm worried about larger TUs where not all dynamic initialization can be
> > optimized into constants.  E.g. if there remain any function calls where the
> > alias analysis could think they can read or modify the vars or their
> > subobjects etc., we'd need to punt.
> 
> Would we?  If the variable isn't const, it's OK for later initializers to
> modify its value, I wouldn't think that would prevent us from turning its
> initializer into a constant value.

I'm talking about e.g.
extern int b;
int foo (int &);
int bar (int &);
int baz () { return 1; }
int qux () { return b = 2; }
int a = foo (b);
int b = baz ();
int c = bar (b);
int d = qux ();
Here, b is initialized to constant 1 and we could optimize it into
.data
b: .long 1
or so and similarly d can be optimized into
.data
d: .long 2, but after IPA we see something like:
  _3 = foo (&b);
  a = _3;
  b = 1;
  _4 = bar (&b);
  c = _4;
  b = 2;
  d = 2;
where the fact that foo can only remember b's address somewhere, but can't
really access it because it hasn't been constructed yet is not visible.
So we'd just punt at optimizing that, we don't know if b is read or written by
foo (and, note, it doesn't have to be just the case of explicitly being passed
address of some var, it can get the address through other means).
On the other side, we can't optimize b to b: .long 2, because bar can use the
variable and/or modify it, so by using 2 as static initializer bar would be
miscompiled.
By turning the above into:
  .INIT_START (&a);
  _3 = foo (&b);
  a = _3;
  .INIT_END (&a);
  .INIT_START (&b);
  b = 1;
  .INIT_END (&b);
  .INIT_START (&c);
  _4 = bar (&b);
  c = _4;
  .INIT_END (&c);
  .INIT_START (&d);
  b = 2;
  d = 2;
  .INIT_END (&d);
we can optimize it into:
  _3 = foo (&b);
  a = _3;
  _4 = bar (&b);
  c = _4;
  b = 2;
with DECL_INITIAL (b) = 1 and DECL_INITIAL (d) = 2.
Not showing here any aggregate initializations, there we'd need to reconstruct
the CONSTRUCTOR for DECL_INITIAL from often more than one store.

> This seems like a more general issue: after a variable declared const has
> completed its initialization, it can't be modified.  Would this be useful to
> mark, kind of like we use a clobber for end of life?

I guess we could, but for this optimization we need it not just for const vars,
but also non-const.  And it isn't clear to me for what exactly we'd use it.

> Can't you just look at the type?

Probably.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though, I guess the FE would need to express in the ifns how exactly is the
dynamic initialization ordered, whether it is unordered, partially ordered or
ordered, so that the middle-end optimization could just rely on what the FE
tells it.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[redbeard0531 at gmail dot com]

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

--- Comment #12 from Mathias Stearn <redbeard0531 at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> So we'd just punt at optimizing that, we don't know if b is read or written
> by foo (and, note, it doesn't have to be just the case of explicitly being
> passed address of some var, it can get the address through other means).
> On the other side, we can't optimize b to b: .long 2, because bar can use
> the variable and/or modify it, so by using 2 as static initializer bar would
> be miscompiled.

I'm pretty sure that that is explicitly allowed by
https://eel.is/c++draft/basic.start.static#3, so it should *not* be considered
a miscompilation. The example only shows reading from another static-duration
variable's initializer, but I believe writing would also be covered.

I took a look at how other compilers handle this, and it is somewhat
interesting: https://godbolt.org/z/9YvcbEeax

int foo(int&);
inline int bar() { return 7; }
extern int b;
int z = bar();
int a = foo(b); // comment this out and watch clang change...
int b = bar();
int c = bar();

GCC: always does dynamic init for everything.
MSVC: always does static init for z, b, and c. always dynamic init for a.
Clang: it seems like if it does any dynamic init in the TU, it doesn't promote
any dynamic init to static. So with that code all four variables are
dynamicially initialized, but if you comment out a, the remaining 3 become
static. If you add an unrelated variable that requires dynamic init, those 3
become dynamically initialized again.

I don't understand why clang does what it does. I don't think it is required to
do that by the standard, and it clearly seems suboptimal. So I would rather GCC
behave like MSVC in this case than like clang.

Also note what happens if we provide a definition for foo like `inline int
foo(int& x) { return x += 6; }`: https://godbolt.org/z/sWd6chsnP. Now both MSVC
and Clang will static initialize z, b, and c to 7 and *static* initialize a to
6. GCC gets the same result dynamically, but for some reason tries to load b
prior to adding 6, even though it has to be 0 (barring a UB write to b from
another TU).

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Mathias Stearn from comment #12)
> (In reply to Jakub Jelinek from comment #10)
> > So we'd just punt at optimizing that, we don't know if b is read or written
> > by foo (and, note, it doesn't have to be just the case of explicitly being
> > passed address of some var, it can get the address through other means).
> > On the other side, we can't optimize b to b: .long 2, because bar can use
> > the variable and/or modify it, so by using 2 as static initializer bar would
> > be miscompiled.
> 
> I'm pretty sure that that is explicitly allowed by
> https://eel.is/c++draft/basic.start.static#3, so it should *not* be
> considered a miscompilation. The example only shows reading from another
> static-duration variable's initializer, but I believe writing would also be
> covered.

You are clearly talking about a different case than I was.
Once a variable is initialized, dynamic initializers which are ordered after
that certainly can't see a different value of the var than it should.
What you refer to is that because of the foo call in my testcase the optimizer
can still optimize b's initialization from dynamic to static b = 1
initialization.  But, when bar is called, b needs to be 1, not 2.

>From what you wrote, I bet llvm implements what I was talking about in #c8
before
"But I'm worried", i.e. if the static initialization function is optimized into
just a series of constant stores, all the vars in it can be optimized.
With the markers I've mentioned, we could consider each dynamic initialization
individually, rather than just are all initializations constant, then optimize,
otherwise punt.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51680&action=edit
gcc12-pr102876-wip.patch

WIP patch that adds the internal fns around dynamic initializers that could be
optimized, but doesn't add the pass that would use these yet.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51731&action=edit
gcc12-pr102876.patch

Untested implementation of the optimization.
So far a little bit limited, either it handles initialization of the whole var
at once (usually scalar vars), or uses native_{encode,interpret}*
infrastructure
and in that case it can't handle unions or anything that needs relocations in
the initializers.  I guess in some cases it could be improved, but especially
unions can be harder or very hard if the access path is not visible in the
stores.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim.yegorushkin at gmail dot com

--- Comment #16 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 94184 has been marked as a duplicate of this bug. ***