Yes :) I am asking about 3.2.3 but I think the reload concepts should
be about the same. From what I can tell, most of the code I looked at
was almost identical to GCC 4.7.3.
Yes, the instruction 2219 is a paradoxical subreg. There is a little
bit more to the story than I had outlined, let me try again.
>From 22.lreg:
(insn 2219 2227 2221 60 0x2aaaad7e5980 (set (reg:SI 1296)
(plus:SI (subreg:SI (reg/v:HI 879) 0)
(const_int 1 [0x1]))) 9 {addsi3} (nil)
(expr_list:REG_DEAD (reg/v:HI 879)
(nil)))
There is also
(insn 33 32 4922 0 0x2aaaad7a6800 (set (reg/v:HI 879)
(const_int 0 [0x0])) 79 {*movhi_i} (nil)
(nil))
What happens is that in alloc/reload/greg we spill:
Spilling for insn 2219.
(insn 5044 2227 5045 60 (nil) (set (reg:SI 45 r45)
(plus:SI (reg/f:SI 323 sp)
(const_int 144 [0x90]))) 9 {addsi3} (nil)
(nil))
(insn 5045 5044 2219 60 (nil) (set (reg:SI 45 r45)
(mem:SI (reg:SI 45 r45) [9442 sec 0 space 0, cmsmode 0
x86_nmbr S2 A16])) 74 {*movsi} (nil)
(nil))
(insn 2219 5045 2221 60 0x2aaaad7e5980 (set (reg:SI 46 r46 [1296])
(plus:SI (reg:SI 45 r45)
(const_int 1 [0x1]))) 9 {addsi3} (nil)
(nil))
as well as for insn 33:
(insn 4979 32 33 0 (nil) (set (reg:SI 45 r45)
(plus:SI (reg/f:SI 323 sp)
(const_int 144 [0x90]))) 9 {addsi3} (nil)
(nil))
(insn 33 4979 4922 0 0x2aaaad7a6800 (set (mem:HI (reg:SI 45 r45) [9442
sec 0 space 0, cmsmode 0 x86_nmbr S2 A16])
(const_int 0 [0x0])) 79 {*movhi_i} (nil)
(nil))
Note that we did not support 144 displacement in memory addresses
which is why you see the additional add for the stack pointer, please
disregard. Here are the things that are unclear to me:
Note that insn 33 gets reloaded into mem:HI, while insn 2219 gets
reloaded into mem:SI. This happens in
reload.c:find_reloads_subreg_address:
/* If the address changes because of register elimination, then
it must be replaced. */
if (force_replace
|| ! rtx_equal_p (tem, reg_equiv_mem[regno]))
{
int offset = SUBREG_BYTE (x);
unsigned outer_size = GET_MODE_SIZE (GET_MODE (x));
unsigned inner_size = GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)));
XEXP (tem, 0) = plus_constant (XEXP (tem, 0), offset);
PUT_MODE (tem, GET_MODE (x));
Note that we are setting the mode of the memory to the bigger
(paradoxical) part of the subreg. How can we just set the mode, does
somebody make sure this memory is actually allocated? I noticed even
new GCC does that. Is this correct?
Going back where we call find_reloads_subreg_address:
else if (regno >= FIRST_PSEUDO_REGISTER
#ifdef LOAD_EXTEND_OP
&& (GET_MODE_SIZE (GET_MODE (x))
<= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))
#endif
&& (reg_equiv_address[regno] != 0
|| (reg_equiv_mem[regno] != 0
&& (! strict_memory_address_p (GET_MODE (x),
XEXP (reg_equiv_mem[regno], 0))
|| ! offsettable_memref_p (reg_equiv_mem[regno])
|| num_not_at_initial_offset))))
x = find_reloads_subreg_address (x, 1, opnum, type, ind_levels,
insn);
I have 2 questions here. Why does the fact whether or whether we don't
have load extended ops matter when widening (or narrowing) the reload
location (find_reloads_subreg_address)? Same question for
req_equiv_address, why does this matter whether or not we end up
widening/narrowing the memory location?
Generally speaking, does it look fine to you that we end up
spilling/reloading mem:HI on the one hand, but mem:SI on the other?
Thanks!! Regards,
Hendrik Greving
On Wed, Jun 5, 2013 at 5:19 PM, Ian Lance Taylor <i...@google.com> wrote:
> On Wed, Jun 5, 2013 at 9:14 AM, Hendrik Greving
> <hendrik.greving.in...@gmail.com> wrote:
>> I am looking at a case (old GCC 3.2.3 is used), which I like to
>> outline as follow:
>
>
> Are you really asking about GCC 3.2.3, released over 10 years ago?
>
>> (insn 2219 2218 2220 (nil) (set (reg:SI 1296)
>> (plus:SI (subreg:SI (reg/v:HI 1277) 0)
>> (const_int 1 [0x1]))) -1 (nil)
>> (nil))
>
> This is a paradoxical subreg. It means that the bits in reg 1277
> outside of HImode are irrelevant.
>
>> (insn 2219 2227 2221 60 0x2aaaad83aa80 (set (reg:SI 1296)
>> (plus:SI (subreg:SI (reg/v:HI 879) 0)
>> (const_int 1 [0x1]))) 9 {addsi3} (nil)
>> (expr_list:REG_DEAD (reg/v:HI 879)
>> (nil)))
>>
>> As you can see is, what happens is that the addsi insn 2219 in 22.lreg
>> (we only have addsi, not addhi), is getting a reload, but what happens
>> to be a HI, is now fully SI resulting into a 32 bit load later in the
>> assembly.
>>
>> Question: is it possible to say, is this a bug or a feature?
>
> Based on what you have shown, it is not a bug.
>
> Ian
