public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c++/99091] New: constexpr variable evaluated at runtime @ 2021-02-13 21:55 barry.revzin at gmail dot com 2021-02-14 9:27 ` [Bug tree-optimization/99091] " jakub at gcc dot gnu.org ` (3 more replies) 0 siblings, 4 replies; 5+ messages in thread From: barry.revzin at gmail dot com @ 2021-02-13 21:55 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091 Bug ID: 99091 Summary: constexpr variable evaluated at runtime Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: barry.revzin at gmail dot com Target Milestone: --- Consider the following (link to compiler explorer: https://godbolt.org/z/jWsxsK) #include <array> static constexpr auto doy = []{ std::array<int, 13> month_offset{}; for (int m=1; m<=12;++m) { month_offset[m] = (153*(m > 2 ? m-3 : m+9) + 2)/5; } return month_offset; }(); auto foo(int m) -> int { #ifdef LOCAL constexpr auto doy = []{ std::array<int, 13> month_offset{}; for (int m=1; m<=12;++m) { month_offset[m] = (153*(m > 2 ? m-3 : m+9) + 2)/5; } return month_offset; }(); #endif return doy[m]; } This is a fragment of code that does some calculation to figure out the date, which isn't super important. If LOCAL is not defined (i.e. we declare the array as a namespace-scope constexpr), the -O3 codegen of 'foo' is: foo(int): movsx rdi, edi mov eax, DWORD PTR doy[0+rdi*4] ret However, if we want to move the declaration of doy to be more local to the calculation and compile with -DLOCAL, the codegen instead is (on -O3): foo(int): pxor xmm0, xmm0 mov rax, QWORD PTR .LC0[rip] movsx rdi, edi mov DWORD PTR [rsp-24], 275 movaps XMMWORD PTR [rsp-72], xmm0 movdqa xmm0, XMMWORD PTR .LC1[rip] mov QWORD PTR [rsp-68], rax movaps XMMWORD PTR [rsp-56], xmm0 movdqa xmm0, XMMWORD PTR .LC2[rip] movaps XMMWORD PTR [rsp-40], xmm0 mov eax, DWORD PTR [rsp-72+rdi*4] ret This can be alleviated by marked the local variable doy as being static constexpr. Except that this prevents 'foo' from being a constexpr function (can't have static variables). This just seems like bad codegen, I'm not sure there's any reason that the compiler needs to do work here. It would be nice if the codegen with a local constexpr variable were the same as if it were a non-local constexpr variable. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/99091] constexpr variable evaluated at runtime 2021-02-13 21:55 [Bug c++/99091] New: constexpr variable evaluated at runtime barry.revzin at gmail dot com @ 2021-02-14 9:27 ` jakub at gcc dot gnu.org 2021-02-15 10:31 ` jakub at gcc dot gnu.org ` (2 subsequent siblings) 3 siblings, 0 replies; 5+ messages in thread From: jakub at gcc dot gnu.org @ 2021-02-14 9:27 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org Component|c++ |tree-optimization --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I don't see anything wrong on that, the constexpr var is not evaluated at runtime, it has a constant initializer. So in the end it is static const int doy1[] = { 306, 337, 31, 61, 92, 122, 153, 184, 214, 245, 275 }; int foo1(int m) { return doy1[m]; } int foo2(int m) { static const int doy2[] = { 306, 337, 31, 61, 92, 122, 153, 184, 214, 245, 275 }; return doy2[m]; } int foo3(int m) { const int doy3[] = { 306, 337, 31, 61, 92, 122, 153, 184, 214, 245, 275 }; return doy3[m]; } and there is nothing C++ specific on it. The compiler may promote the doy3 variable from automatic variable into static variable if it can prove it is safe to do so (it would be unsafe e.g. if foo3 could be called recursively and compare the addresses of the var between the recursive invocations). GCC does that early (during gimplification) if the variable is not address taken, but the array reference implies address taking. And, especially for the original testcase where operator[] is overloaded, it really can't do better early, so we'd need an optimization that would promote automatic vars to static when possible later (e.g. after inlining) if it can prove it is safe to do so. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/99091] constexpr variable evaluated at runtime 2021-02-13 21:55 [Bug c++/99091] New: constexpr variable evaluated at runtime barry.revzin at gmail dot com 2021-02-14 9:27 ` [Bug tree-optimization/99091] " jakub at gcc dot gnu.org @ 2021-02-15 10:31 ` jakub at gcc dot gnu.org 2021-08-28 22:56 ` [Bug tree-optimization/99091] local array not prompted to static pinskia at gcc dot gnu.org 2024-03-15 0:07 ` pinskia at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: jakub at gcc dot gnu.org @ 2021-02-15 10:31 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jamborm at gcc dot gnu.org --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Wonder if SRA doesn't have the right infrastructure to optimize this. In any case, GCC 12 material. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/99091] local array not prompted to static 2021-02-13 21:55 [Bug c++/99091] New: constexpr variable evaluated at runtime barry.revzin at gmail dot com 2021-02-14 9:27 ` [Bug tree-optimization/99091] " jakub at gcc dot gnu.org 2021-02-15 10:31 ` jakub at gcc dot gnu.org @ 2021-08-28 22:56 ` pinskia at gcc dot gnu.org 2024-03-15 0:07 ` pinskia at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: pinskia at gcc dot gnu.org @ 2021-08-28 22:56 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|constexpr variable |local array not prompted to |evaluated at runtime |static Last reconfirmed| |2021-08-28 Severity|normal |enhancement --- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Confirmed, there is another bug which is very similar to this one but filed years ago. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/99091] local array not prompted to static 2021-02-13 21:55 [Bug c++/99091] New: constexpr variable evaluated at runtime barry.revzin at gmail dot com ` (2 preceding siblings ...) 2021-08-28 22:56 ` [Bug tree-optimization/99091] local array not prompted to static pinskia at gcc dot gnu.org @ 2024-03-15 0:07 ` pinskia at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: pinskia at gcc dot gnu.org @ 2024-03-15 0:07 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Dup. *** This bug has been marked as a duplicate of bug 59863 *** ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-03-15 0:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-13 21:55 [Bug c++/99091] New: constexpr variable evaluated at runtime barry.revzin at gmail dot com 2021-02-14 9:27 ` [Bug tree-optimization/99091] " jakub at gcc dot gnu.org 2021-02-15 10:31 ` jakub at gcc dot gnu.org 2021-08-28 22:56 ` [Bug tree-optimization/99091] local array not prompted to static pinskia at gcc dot gnu.org 2024-03-15 0:07 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).