--- Comment #14 from borntraeger at de dot ibm dot com 2010-07-26 10:13
---
I have seen the original problem only with bitfields.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
--- Comment #11 from borntraeger at de dot ibm dot com 2010-07-25 16:54
---
Something like the following should do the trick.
Is endian.h available on all supported platforms?
*** gcc.c-torture/execute/pr45017.c.orig
--- gcc.c-torture/execute/pr45017.c
***
*** 1,9
--- Comment #4 from borntraeger at de dot ibm dot com 2010-07-22 12:41
---
the testcase will fail on big endian machines.
since r2=f and r1=2 instead of r2=2 and r1=f.
Can you adopt the testcase to check the endianess?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
: borntraeger at de dot ibm dot com
GCC build triplet: i686-pc-linux-gnu and s390x-ibm-linux-gnu
GCC host triplet: i686-pc-linux-gnu and s390x-ibm-linux-gnu
GCC target triplet: i686-pc-linux-gnu and s390x-ibm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
--- Comment #9 from borntraeger at de dot ibm dot com 2010-06-27 11:09
---
So there seem to be at least two problems:
1. exploding complexity in compute_miss_rate (the start for this bugzilla)
2. effects due to prefetching seen in other passes
I think the attached patch cures 1. What
--- Comment #6 from borntraeger at de dot ibm dot com 2010-06-26 20:30
---
Richard,
can you check if compute_miss_rate is the problem?
does the attached patch helps?
thanks
Christian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
--- Comment #3 from borntraeger at de dot ibm dot com 2010-06-25 09:02
---
Created an attachment (id=21001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001action=view)
Potential fix for compile time regression
Here is a potential fix. We just limit prefetching to loops
--- Comment #6 from borntraeger at de dot ibm dot com 2010-06-24 12:35
---
HJ confirmed that the patch worked and Andreas applied the patch. So from my
point of view, the problem is fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44203
on prefetching+peeling
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: borntraeger at de dot ibm dot com
GCC host triplet
--- Comment #1 from borntraeger at de dot ibm dot com 2010-06-18 07:59
---
4.6 (trunk) is also affected
--
borntraeger at de dot ibm dot com changed:
What|Removed |Added
--- Comment #22 from borntraeger at de dot ibm dot com 2010-06-08 19:42
---
I bootstrapped with patches 0002 and 0003.
The results are also good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
--- Comment #20 from borntraeger at de dot ibm dot com 2010-06-08 05:51
---
both patches look sane. I will test both.
thank you for your work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
--- Comment #12 from borntraeger at de dot ibm dot com 2010-06-01 19:30
---
Ok. So I will let you continue to look into that and wait for your results?
Do you have any feedback on separate.patch and its influence on performance?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #10 from borntraeger at de dot ibm dot com 2010-05-31 08:58
---
Created an attachment (id=20783)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20783action=view)
experimental patch to have separate values for min_insn_to_prefetch_ration
Changpeng,
thank you
--- Comment #4 from borntraeger at de dot ibm dot com 2010-05-28 07:24
---
Created an attachment (id=20767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20767action=view)
Patch that makes loop invariant prefetches backend specfic
Three observations:
1. the patch had a bug which
--- Comment #5 from borntraeger at de dot ibm dot com 2010-05-28 07:41
---
An alternative approach might be have different values for
prefetch-min-insn-to-mem-ratio and min-insn-to-prefetch-ratio
depending on constant/non-constant step size.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from borntraeger at de dot ibm dot com 2010-05-20 08:29
---
Indeed. I think I found a typo when handling array prefetches.
a potential fix might be:
--- gcc/tree-ssa-loop-prefetch.c(Revision 159557)
+++ gcc/tree-ssa-loop-prefetch.c(Arbeitskopie
--- Comment #2 from borntraeger at de dot ibm dot com 2010-05-20 12:28
---
Created an attachment (id=20709)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20709action=view)
new version of the fix.
There is actually a second bug :-(
We not only have to replace step with stepsize
--- Comment #1 from borntraeger at de dot ibm dot com 2010-05-11 13:43
---
From a first look this looks like that the test case scans for
nontemporal store which is also emitted by the new debug messages:
-return false;
+{
+ if (dump_file (dump_flags TDF_DETAILS
--- Comment #2 from borntraeger at de dot ibm dot com 2010-05-11 13:57
---
Created an attachment (id=20629)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20629action=view)
Testfix for the prefetch-7.c testcase
There always was
fprintf (dump_file, Marked reference %p
20 matches
Mail list logo
