https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439
pthaugen at gcc dot gnu.org changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, hubicka at gcc dot gnu.org,
segher at gcc dot gnu.org, seurer at gcc dot gnu.org
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, marxin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921
Pat Haugen changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921
--- Comment #4 from Pat Haugen 2013-04-11
20:02:09 UTC ---
This is another failure due to the same revision.
FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921
--- Comment #5 from Pat Haugen 2013-04-11
21:03:50 UTC ---
As are these forran failures also:
FAIL: gfortran.dg/minloc_3.f90 -O3 -fomit-frame-pointer -funroll-loops
(internal compiler error)
FAIL: gfortran.dg/minlocval_3.f90 -O3 -f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921
--- Comment #13 from Pat Haugen 2013-04-15
19:37:27 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > Created attachment 29877 [details]
> > patch papering over the issue with TODO_do_not_ggc_collect
> >
> > Patch paper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497
Bug #: 54497
Summary: Revision 190015 causes 22% degradation on 172.mgrid on
PowerPC
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497
--- Comment #2 from Pat Haugen 2012-09-06
21:05:05 UTC ---
(In reply to comment #1)
> I suppose the loop is no longer predicted to execute enough times?
I don't think that's the issue, I'm thinking it's somewhere in the data
dependence analysis.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
--- Comment #10 from Pat Haugen 2012-09-12
23:04:55 UTC ---
Created attachment 28181
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28181
Reduced testcase
Martin,
Have you done any more digging on this? I just discovered that cpu2006
benc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
--- Comment #5 from Pat Haugen 2012-09-20
19:13:25 UTC ---
Forgot to include the error message, which is causing the failures:
/home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/c-c++-common/torture/vector-compare-2.c:9:1:
warning: GCC vecto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497
Pat Haugen changed:
What|Removed |Added
Attachment #28135|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #5 from Pat Haugen 2012-10-17
23:38:16 UTC ---
I'm seeing the same thing on cpu2006 benchmark 44.namd on PowerPC64. A load is
being moved above a store to the same location, starting with revision 191493.
Reduced testcase and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #6 from Pat Haugen 2012-10-18
01:44:35 UTC ---
> The sched1 dump correctly lists forward dependencies of the initial store(s)
> to
> p1[i] to the subsequent loads of p1[i], but those dependencies are gone in the
> .sched2 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #7 from Pat Haugen 2012-10-18
01:50:00 UTC ---
Created attachment 28473
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28473
sched1 dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #8 from Pat Haugen 2012-10-18
01:51:03 UTC ---
Created attachment 28475
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28475
sched2 dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850
--- Comment #11 from Pat Haugen 2012-10-22
15:50:06 UTC ---
(In reply to comment #9)
> Created attachment 28482 [details]
> Candidate patch.
>
> Could you both please test this patch?
The patch fixes the issue for me too, on both the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
Summary: cpu2000 benchmark 301.apsi fails with revision 169782
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
Pat Haugen changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
Pat Haugen changed:
What|Removed |Added
Attachment #23248|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
--- Comment #9 from Pat Haugen 2011-02-08
21:08:28 UTC ---
Thanks Jakub, check_for_inc_dec() does indeed fix the issue as desired (still
elminates the redundant load, but keeps the increment). I'll fire off
bootstrap/regtest.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
--- Comment #14 from Pat Haugen 2011-02-09
21:03:31 UTC ---
(In reply to comment #13)
> Alternatively, if we go the first patch route, I
> think side_effects_p guard in reload_cse_simplify_operands is still desirable.
My bootstrap/regtest (of es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
--- Comment #16 from Pat Haugen 2011-02-11
20:52:58 UTC ---
Author: pthaugen
Date: Fri Feb 11 20:52:55 2011
New Revision: 170059
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170059
Log:
PR rtl-optimization/47614
* rtl.h (check_f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
Pat Haugen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862
Summary: Incorrect code for spilling a vector register
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862
--- Comment #1 from Pat Haugen 2011-02-24
21:54:00 UTC ---
Looks like the bogus spill/restore insns are being inserted via caller-save.c
routines since IRA assigned volatile regs to pseudos which are live across a
call.
190.sched1 dump for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862
--- Comment #2 from Pat Haugen 2011-02-25
00:55:20 UTC ---
The DI mode for the spill locations is being decided in
caller-save.c:init_caller_save(), which appears to decide what mode should be
used when a caller-saved reg needs to be saved/restor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862
--- Comment #3 from Pat Haugen 2011-02-25
17:36:03 UTC ---
The following fixes the problem by changing the save mode for FP regs to V2DF
mode for TARGET_VSX. But I have questions/concerns on this that need more
digging:
- I believe this will aff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947
Pat Haugen changed:
What|Removed |Added
Target Milestone|--- |4.6.0
--- Comment #7 from Pat Haugen 2011-0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947
--- Comment #8 from Pat Haugen 2011-03-02
23:03:36 UTC ---
(In reply to comment #6)
> Created attachment 23520 [details]
> Assembly output from testcase
David,
Can you post your output you get from this run, since we've seen variations
now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947
Pat Haugen changed:
What|Removed |Added
Target Milestone|4.6.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947
--- Comment #10 from Pat Haugen 2011-03-03
22:12:12 UTC ---
This is looking like a dup of PR47862, note the following snippet of assembler.
stfd 0,360(1) #,
stfd 12,344(1) #,
stfd 13,352(1) #,
stfd 11,336(1) #,
..
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, mikestump at comcast dot net
Host: powerpc64-linux
Target: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57304
--- Comment #5 from Pat Haugen ---
The patch fixes the benchmark failure as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #8
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, jakub at gcc dot gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57741
--- Comment #2 from Pat Haugen ---
Created attachment 30402
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30402&action=edit
full .i file
The proposed patch fixes the error for the reduced testcase and also fixes the
problem for the apsi ben
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, meissner at gcc dot gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
Build
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, meissner at gcc dot gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
Build
,
||powerpc64-linux
CC||pthaugen at gcc dot gnu.org
--- Comment #2 from Pat Haugen ---
Seeing the same thing on powerpc64-linux.
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje.gcc at gmail dot com,
hubicka at gcc dot gnu.org, marxin.liska at gmail dot com
Host: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096
Pat Haugen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
rguenth at gcc dot gnu.org
Host: powerpc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453
--- Comment #1 from Pat Haugen ---
Created attachment 30841
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30841&action=edit
Source file
pdv.f source file from benchmark, which results in successful execution if
compiled with prior revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453
--- Comment #2 from Pat Haugen ---
Created attachment 30842
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30842&action=edit
r202429 ldist dump
Loop distribution dump for pdv.f using rev 202429.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453
--- Comment #3 from Pat Haugen ---
Created attachment 30843
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30843&action=edit
r202431 ldist dump
Loop distribution dump for pdv.f using rev 202431.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453
--- Comment #4 from Pat Haugen ---
Just discovered that -fwrapv results in successful execution also, so possibly
bad source.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
ppluzhnikov at google dot com
Host: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50102
Bug #: 50102
Summary: ICE in cp/mangle.c:write_type()
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862
--- Comment #8 from Pat Haugen 2011-08-22
18:44:01 UTC ---
I've verified the proposed patch fixes the testcase from bug 50102.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48722
--- Comment #4 from Pat Haugen 2011-08-22
18:55:49 UTC ---
The testcase from comment 1 no longer fails on trunk, so I'm unable to test the
patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49890
Pat Haugen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
--- Comment #3 from Pat Haugen 2011-09-01
20:34:00 UTC ---
This also shows up on PowerPC in the 3 cpu2000 benchmarks 178.galgel, 191.fma3d
and 200.sixtrack.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665
Pat Haugen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439
Bug #: 50439
Summary: gfortran infinite loop with -floop-interchange
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49629
--- Comment #7 from Pat Haugen 2011-10-12
15:19:54 UTC ---
No, I no longer see the failure on PowerPC, for the reduced testcase or the
full benchmark.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50969
Bug #: 50969
Summary: 17% degradation in 168.wupwise for interleave via
permutation
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50969
--- Comment #1 from Pat Haugen 2011-11-02
21:38:28 UTC ---
I swapped the numbers, should be:
-m64 -O3 -mcpu=power7
zaxpy : -79%
zscal : -24%
-m64 -O3 -mcpu=power7 -funroll-loops
zaxpy : -61%
zscal : -65%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
Pat Haugen changed:
What|Removed |Added
Last reconfirmed|2010-03-31 11:56:08 |2011-11-08
--- Comment #36 from Pat Haugen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180
Bug #: 53180
Summary: Revision 186378 generates incorrect code for cpu2006
416.gamess
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180
Pat Haugen changed:
What|Removed |Added
Target Milestone|4.8.0 |---
--- Comment #2 from Pat Haugen 2012-05-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54131
Bug #: 54131
Summary: ICE building 416.gamess, reload_cse_simplify_operands
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614
--- Comment #6 from Pat Haugen 2012-03-20
17:21:21 UTC ---
Adding -fno-common fixes the failures on powerpc64 also.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52760
Bug #: 52760
Summary: Revision 185599 causes miscompare on sphinx3
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52797
Bug #: 52797
Summary: Revision 185913 causes ICE in get_loop_body, at
cfgloop.c:831 on PowerPC
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
Bug #: 52890
Summary: Revision 185336 causes 10% degradation on cpu2000
benchmark 252.eon
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
--- Comment #1 from Pat Haugen 2012-04-06
21:13:04 UTC ---
My main question on this is why the MEM_REF has an alignment of 8 (i.e. byte)?
Breakpoint 1, expand_assignment (to=0xfffafed2790, from=,
nontemporal=) at
/home/pthaugen/src/gcc/temp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
Pat Haugen changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever Confirmed|1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
Pat Haugen changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
Pat Haugen changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #7 from Pat Haugen 2012-04-
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje.gcc at gmail dot com,
rguenth at gcc dot gnu.org
Host
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, tromey at gcc dot gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58608
--- Comment #1 from Pat Haugen ---
Current trunk bootstraps now (r203154). Bisecting to see revision that fixed
it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58608
Pat Haugen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
meissner at gcc dot gnu.org
Host: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58673
--- Comment #1 from Pat Haugen ---
Created attachment 30972
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30972&action=edit
testcase
Another similar example, but this one is on a store to memory instead of a
load. Reduced from CPU2006 bench
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
meissner at gcc dot gnu.org
Host: powerpc64-linux
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, jakub at gcc dot gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #2 from Pat Haugen ---
Yes, this still fails with r204348.
I did discover that adding -mrecip=rsqrt allows the benchmark to succeed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #5 from Pat Haugen ---
Well, it looks to be an interaction amongst 3 files from the benchmark. All 3
have to be compiled with r203979 compiler for the benchmark to fail (others are
compiled with r203978). I captured assembler output fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #8 from Pat Haugen ---
(In reply to Kostya Serebryany from comment #7)
> Is this fixed by http://gcc.gnu.org/viewcvs?rev=204726&root=gcc&view=rev ?
I just tried r204726 on powerpc64-linux and it's failing as follows now.
In file inc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787
--- Comment #12 from Pat Haugen ---
Working on PowerPC also.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51074
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51074
--- Comment #9 from Pat Haugen 2011-11-22
16:15:09 UTC ---
(In reply to comment #7)
> Created attachment 25878 [details]
> gcc47-pr51074-be.patch
>
> Big endian fix, untested.
This patch fixes the issue on both my testcase and the cpu2000 bench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #16 from Pat Haugen ---
>
> Do you observe the same slowdown if you restore either of the params to
> the value before the r257582 change?
>
--param max-inline-insns-auto=40 results in the same degradation.
--param inline-min-spee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #19 from Pat Haugen ---
(In reply to Jan Hubicka from comment #18)
> which makes it to be inlined. Does it solve the perofmrance problem for both
> benchmarks?
Looking at our nightly spec runs, the bzip2 degradation has indeed been c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #21 from Pat Haugen ---
> Knowing what inline decision matters for VPR, I can try to fix it too.
Gathering some perf data, the hot functions for various revisions are as
follows. All other functions report < 0.5% of execution time.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154
--- Comment #3 from Pat Haugen ---
(In reply to Segher Boessenkool from comment #1)
> The new version needs to save r4 because it reuses the reg for storing r7+r8.
> And we still don't wrap CR separately, sigh.
Yes, and similar for r3 since it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #2 from Pat Haugen ---
(In reply to Pat Haugen from comment #0)
>
> Very initial look at profile of bzip2 shows degradation is contained to
> mainSort(), which showed a 54% increase in run cycles. Appears one of the
> calls to mainGt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #3 from Pat Haugen ---
(In reply to Jan Hubicka from comment #1)
> Pat, can you try to figure out what value of min-speedup is neeed to recover
> from this regression?
Using r257582, either of the following options restores the behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #5 from Pat Haugen ---
A little more detail. 48t.fnsplit splits mainGtU() into 2 functions:
mainGtU(): which contains a few early exit tests and then a call to
mainGtU.part.0()
mainGtU.part.0(): contains the remainder of mainGtU(),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #6 from Pat Haugen ---
Created attachment 43900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43900&action=edit
inline dump
1 - 100 of 371 matches
Mail list logo