https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Alan Modra :
https://gcc.gnu.org/g:0c3519218fb11bdde5356aec9fcac133b4988698
commit r9-8556-g0c3519218fb11bdde5356aec9fcac133b4988698
Author: Alan Modra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #11 from CVS Commits ---
The master branch has been updated by Alan Modra :
https://gcc.gnu.org/g:19e5389debb03c3623f6a2ce8a8f6f4aa2118901
commit r10-7430-g19e5389debb03c3623f6a2ce8a8f6f4aa2118901
Author: Alan Modra
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #10 from Segher Boessenkool ---
The resolved address can only change before the first call to it, so we
could even automatically insert code checking that, perhaps.
My other concern is not slowing down the code if LD_BIND_NOW is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #9 from Richard Biener ---
(In reply to Alan Modra from comment #8)
> (In reply to Richard Biener from comment #7)
> > OTOH CSEing the load from the PLT once it is resolved _would_ be an
> > optimization.
>
> Possibly. Sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #8 from Alan Modra ---
(In reply to Richard Biener from comment #7)
> OTOH CSEing the load from the PLT once it is resolved _would_ be an
> optimization.
Possibly. Sometimes making the call sequence seem more efficient runs into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #6 from Alan Modra ---
Transformations to indirect calls and hoisting function addresses out of loops
is fine. That sort of thing has nothing to do with this problem.
The problem is that the PLT really is volatile, and the inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #5 from Richard Biener ---
So what prevents GIMPLE from doing the transform to an indirect call and
hoisting the call address computation out of the loop? I fear your volatile
marking is
papering over an entirely different issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #3 from Segher Boessenkool ---
C11 6.6/9 says it *always* is constant, even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #2 from Segher Boessenkool ---
How could the function address ever not be constant?
Hoisting it to somewhere where it is (dynamically) more expensive is a
bad idea, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
--- Comment #1 from Michael Meissner ---
Created attachment 48021
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48021=edit
Example code
Compile with -mcpu=future -mpcrel -O3 to see the load of the address being
moved out of the loop.
14 matches
Mail list logo
