https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #18 from Jakub Jelinek ---
I think Richi didn't like it much, but my memory is fuzzy on it.
The latest version of the patch was
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588539.html
I'll need to look at IRC logs if somet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Patrick Palka changed:
What|Removed |Added
Last reconfirmed|2021-10-21 00:00:00 |2024-10-9
--- Comment #17 from Patrick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Patrick Palka changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #14 from Jakub Jelinek ---
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
optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #13 from Jakub Jelinek ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #12 from Mathias Stearn ---
(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
> pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #11 from Jakub Jelinek ---
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 j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #10 from Jakub Jelinek ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #9 from Jason Merrill ---
(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
> ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #7 from Jason Merrill ---
But yes, the implicit constexpr patch I've been working on would likely improve
this as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #6 from Jason Merrill ---
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 co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Patrick Palka changed:
What|Removed |Added
Depends on||4131
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #3 from Mathias Stearn ---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirme
19 matches
Mail list logo
