This is the mail archive of the
mailing list for the GCC project.
Re: LRA handling of subreg (on AARCH64 with ILP32)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Pinski <pinskia at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Thu, 15 Jan 2015 11:15:52 +0000
- Subject: Re: LRA handling of subreg (on AARCH64 with ILP32)
- Authentication-results: sourceware.org; auth=none
- References: <CA+=Sn1k-_qLb-RqE1mHcrVN2f_MiXbCkFbxW1L1P5RuYZiVcsQ at mail dot gmail dot com>
On 15/01/15 04:11, Andrew Pinski wrote:
> I have some code where we generate some weird code that has stores
> followed by a load from the same location.
> For an example we get:
> add x14, sp, 240
> add x15, sp, 232
> str x14, [sp, 136]
> mov w2, w27
> ldr w1, [sp, 136]
> str x15, [sp, 136]
> ldr w0, [sp, 136]
> The RTL originally using an offset of the frame pointer and in DImode
> and then we use it in SImode because pointers are 32bit in ILP32.
> Can you explain how LRA decides to create this code and ways of improving it?
> This is in perlbench in SPEC CPU 2006. I can provide the preprocessed
> sources (since I am using LTO) if needed.
> Andrew Pinski
So it looks like it's spilling a 64-bit value, but then reloading it as
a 32-bit value. That seems quite strange and I can see why the reload
cse pass would miss the connection.
Does this even produce the right code in big-endian, where the stack
slot offset changes slightly?