https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #26 from Andrew Pinski ---
Note I think we should be able to do this without the tracer.
After PRE we get now:
```
if (_1 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 531502204]:
_14 = operator new (16);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #25 from Martin Liška ---
SPEC CPU numbers (--size=train, --iterations=3):
First 3 columns present time (where smaller means faster) and for binary size
the same.
++--++---+-+-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #24 from Martin Liška ---
Hello Honza. I've been working on SPEC numbers, I will send it this evening.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #23 from davidxl ---
(In reply to Jan Hubicka from comment #22)
> > > Doing it at same approximately the same place as loop header copying
> > > seems to
> > > make most sense to me. It benefits from early cleanups and DCE definitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #22 from Jan Hubicka ---
> > Doing it at same approximately the same place as loop header copying seems
> > to
> > make most sense to me. It benefits from early cleanups and DCE definitly
> > and
> > it should enable more fun with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #21 from rguenther at suse dot de ---
nOn Sat, 27 Sep 2014, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
>
> Jan Hubicka changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #20 from rguenther at suse dot de ---
On Fri, 26 Sep 2014, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
>
> --- Comment #14 from Jeffrey A. Law ---
> This feels like the kind of situation where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #19 from davidxl ---
(In reply to Jan Hubicka from comment #18)
> > WE can try some internal benchmarks with this change too.
>
> That would be very welcome. Tracer used to be quite useful pass in old days,
> doing 1.6% on -O3+FDO S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #18 from Jan Hubicka ---
> WE can try some internal benchmarks with this change too.
That would be very welcome. Tracer used to be quite useful pass in old days,
doing 1.6% on -O3+FDO SPECint (for 1.4% code size cost) that put it ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #17 from davidxl ---
(In reply to Jan Hubicka from comment #16)
> I have moved tracer before the late cleanups that seems to be rather obbious
> thing to do. This lets us to optimize the testcase (with -O2):
> int main() ()
> {
> st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #15 from Jan Hubicka ---
Author: hubicka
Date: Sat Sep 27 00:03:23 2014
New Revision: 215651
URL: https://gcc.gnu.org/viewcvs?rev=215651&root=gcc&view=rev
Log:
PR middle-end/35545
* passes.def (pass_tracer): Move before last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #14 from Jeffrey A. Law ---
This feels like the kind of situation where I've always wanted a pass to be
able to say something like "I've done some set of transformations", schedule
the appropriate cleanup passes to run".
It's heavywe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #13 from Richard Biener ---
Well - ideally you'd want to do some CSE, not only VRP (constant propagation in
this case). So I'd move it even earlier, after pass_lower_vector_ssa? I
can't see what tracing would break (some odd cases c
14 matches
Mail list logo
