------- 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 +0000, sje at cup dot hp dot com wrote:
> 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.
This isn't a simple issue, performance wise.
If the compiler puts an address+offset into sdata, then we get something
like
.sdata
.align 8
.LC2:
data8 mv_tables#+72
.text
addl r14 = @gprel(.LC2), gp
;;
ld8 r40 = [r14]
If the compiler emits the code that the ABI intended here, we get
something like
addl r14 = @ltoff(mv_tables#), r1
;;
ld8 r14 = [r14]
;;
adds r40 = 72, r14
This sequence is one instruction longer.
We deliberately do this to avoid accidentally overflowing the got. If
you access the same array with a thousand different offsets, then
instead of putting a thousand entries into the got, we put one entry in
the got, and then add in the offset. So this is a smaller got, but an
extra add instruction that may add to latency if we can't hide it.
This code is working for got entries, but not when an address is forced
into constant pool. So which one is better depends on what the code
looks like. If you have a small number of variables and a large number
of offsets, then you will get a lot more memory references and a larger
got with the first alternative. If you have a large number of variables
and a small number of offsets, then you will get more add instructions
with the second alternative.
This issue originally came up via PR 41567, which triggers a linker
error. Perhaps that testcase would not have triggered the linker error
if we were using the second alternative. I haven't looked at this PR as
yet, so I don't know the details of what is going on here.
Jim
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
