https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #13 from Richard Biener ---
We arrive at different final optimizations depending on PUSH_ARGS_REVERSED
(see PR67203). Current (GCC 6) final state is either 3 or 4 calls depending
on that. And this is only because the final DCE (whic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #12 from rguenther at suse dot de ---
On Wed, 7 May 2014, glisse at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
>
> --- Comment #11 from Marc Glisse ---
> The committed patch doesn't seem to optimize a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #11 from Marc Glisse ---
The committed patch doesn't seem to optimize as well as the hack. fre2 (- is
the hack and + is the new trunk, unless I confused my directories):
- _8 = _98;
+ _8 = MEM[(const struct I &)b_9(D)].o;
- _224 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #10 from Richard Biener ---
Author: rguenth
Date: Wed May 7 14:19:14 2014
New Revision: 210160
URL: http://gcc.gnu.org/viewcvs?rev=210160&root=gcc&view=rev
Log:
2014-05-07 Richard Biener
PR tree-optimization/61034
* tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> (In reply to Marc Glisse from comment #7)
> > (In reply to rguent...@suse.de from comment #6)
> > > that's a conditional assignment AFAICS
> >
> > Ah, you are r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #8 from Richard Biener ---
(In reply to Marc Glisse from comment #7)
> (In reply to rguent...@suse.de from comment #6)
> > that's a conditional assignment AFAICS
>
> Ah, you are right of course. It shouldn't be conditional, but it wil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #7 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #6)
> that's a conditional assignment AFAICS
Ah, you are right of course. It shouldn't be conditional, but it will take a
VRP pass to notice that. If I schedule anoth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #6 from rguenther at suse dot de ---
On Mon, 5 May 2014, glisse at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
>
> --- Comment #5 from Marc Glisse ---
> (In reply to Richard Biener from comment #4)
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #5 from Marc Glisse ---
(In reply to Richard Biener from comment #4)
> you might want to check whether that improves things and point me to stuff
> that is left (FRE related).
The fre2 dump looks much nicer (the .optimized dump is a b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #4 from Richard Biener ---
Created attachment 32736
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32736&action=edit
hack
patch that does the job (but has wrong-code issues, so I need to add a new
hook to walk_non_aliased_vuses i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #3 from Richard Biener ---
points-to cannot be improved here as it is flow-insensitive for memory
accesses and the pointers are copied:
D.2327.o = _2;
D.2327.o = _79;
thus they blend together.
So we have to improve alias walking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #2 from Richard Biener ---
Actually it's the conditional free that "clobbers" the value as _83 may
point to the same thing as _86 (so we don't CSE (possible) use-after-frees).
if (_85 == 0)
goto ;
else
goto ;
:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
13 matches
Mail list logo
