--- Comment #14 from sje at cup dot hp dot com 2010-03-24 21:34 ---
Well it looks like the big SPEC slowdowns were a glitch. The generated code is
only slightly different and when I tried to reproduce the results I saw a
slight
speed up in mcf instead of a slowdown. I still got an
--- Comment #12 from sje at cup dot hp dot com 2010-03-22 20:48 ---
Since the proposed patch to meant to address non-optimimal code generation I
decided to try the patch with SPEC2006 and see if it helped the performance. On
SPECint, I got a 3% slowdown, mostly due to 429.mcf slowing
--- Comment #13 from wilson at codesourcery dot com 2010-03-23 02:11
---
Subject: Re: [ia64] Inappropriate address spills
On Mon, 2010-03-22 at 20:48 +, sje at cup dot hp dot com wrote:
Since the proposed patch to meant to address non-optimimal code generation I
decided to try
--- Comment #8 from sje at cup dot hp dot com 2010-03-17 22:09 ---
I tried the patch and didn't have any problem bootstrapping and I didn't see
any regressions. It also fixed my small test case, but when I went back and
tried some of the other tests from PR 28490 I still saw some of
--- Comment #9 from wilson at codesourcery dot com 2010-03-17 23:25 ---
Subject: Re: [ia64] Inappropriate address spills
On Wed, 2010-03-17 at 22:09 +, sje at cup dot hp dot com wrote:
I tried the patch and didn't have any problem bootstrapping and I didn't see
any regressions.
--- Comment #10 from sje at cup dot hp dot com 2010-03-17 23:47 ---
Reading Richard's initial comment I thought the problem was that the code was
(or could be) illegal because the relocation may be out of range and we
shouldn't
use the gprel relocation for any of these constant pool
--- Comment #11 from wilson at codesourcery dot com 2010-03-18 00:12
---
Subject: Re: [ia64] Inappropriate address spills
On Wed, 2010-03-17 at 23:47 +, sje at cup dot hp dot com wrote:
Reading Richard's initial comment I thought the problem was that the code was
(or could be)
--- Comment #6 from wilson at gcc dot gnu dot org 2010-03-15 04:08 ---
I can reproduce the original problem with 28490 by changing the line in
ia64_legitimate_constant_p from
return (addend 0x3fff) == 0;
to
return true;
and compiling the testcase with -O. What
--- Comment #7 from wilson at gcc dot gnu dot org 2010-03-15 04:11 ---
Created an attachment (id=20106)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20106action=view)
untested patch, imperfect solution
--
wilson at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from wilson at codesourcery dot com 2010-03-13 08:23 ---
Subject: Re: [ia64] Inappropriate address spills
On third thought...
The code here makes sense if we were having problems with invalid
constant recombinations. symbol+const gets split by ia64_expand_move
into
--- Comment #1 from sje at cup dot hp dot com 2010-03-12 19:22 ---
I once asked Jim Wilson about this but didn't get an answer. Here is a pointer
to that email. Also included here is a short example that generates the gprel
load.
My earlier example and question can be seen in:
--- Comment #2 from wilson at codesourcery dot com 2010-03-13 03:03 ---
Subject: Re: [ia64] Inappropriate address spills
This broke between gcc-4.0.0 and gcc-4.1.2. It appears to be the patch
for PR 28490. There is a test in ia64_legitimate_constant_p for symbol
+offset, where we
--- Comment #3 from wilson at gcc dot gnu dot org 2010-03-13 03:06 ---
Created an attachment (id=20097)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20097action=view)
Untested patch that works for sje's testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
--- Comment #4 from wilson at codesourcery dot com 2010-03-13 03:16 ---
Subject: Re: [ia64] Inappropriate address spills
Or maybe we should just accept any constant here? I tried that, and for
typedef struct table { int a; int b; int c; } table;
extern table mv_tables[10];
void
14 matches
Mail list logo
