https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #13)
> > Yes, that object is defined const so can't be changed. But is this
> > something we
> > care about? Is it important to apply this optimization to noinline
> > functions?
> There are few things where this helps. First inside the loop body and
> everything called from it we may assume that the value is unchanged.
Yes. Note that this is the same for non-parameter local variables, which we
also don't seem to use for optimization currently:
extern "C" int puts (const char *);
struct A { int i; };
void f(const A&);
void g()
{
const A a {42};
f(a);
if (a.i != 42)
puts ("changed"); // should optimize away
}
Clang does perform this optimization.
> We can also use it to build jump functions. For example:
>
> #include <functional>
> //const std::function <void()> *escape;
>
> void test (const std::function <void()> f)
> {
> //escape=&f;
> f();
> f();
> }
> void bar();
> int
> main2()
> {
> test (bar);
> return 0;
> }
>
> is IMO correct to be optimized to direct calls to bar() which we don't
> since we are worried about call to _M_manager modifying f.
Yes.
> Also the original testcase is about optimizing destructors after
> function return...
But the original testcase doesn't define foo, so we don't know whether it can
change its parameter; that's why I closed the bug as INVALID. Do we want to
redefine this PR as being about the correct optimizations we've been
discussing, or open a new PR?
