This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Abt RTL expression
"Rohit Arul Raj" <rohitarulraj@gmail.com> writes:
> (insn 106 36 107 6 (set (reg:SI 13 a5)
> (const_int -20 [0xffffffec])) 17 {movsi_short_const} (nil)
> (nil))
>
> (insn 107 106 108 6 (parallel [
> (set (reg:SI 13 a5)
> (plus:SI (reg:SI 13 a5)
> (reg/f:SI 14 a6)))
> (clobber (reg:CC 21 cc))
> ]) 29 {addsi3} (nil)
> (expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 a6)
> (const_int -20 [0xffffffec]))
> (nil)))
>
> (insn 108 107 38 6 (set (reg:SI 13 a5)
> (mem/c:SI (reg:SI 13 a5) [0 S4 A32])) 15 {movsi_load} (nil)
> (nil))
>
> My Deductions:
> 1. In insn 106, we are storing -16 in to the register 13 (a5).
Yes.
> 2. In insn 107, we are taking the value from register 14 (a6) which is
> a pointer and subtracting 16 from it and storing in a5.
Yes.
> Now a6 contains the stack pointer. Therefore a5 now contains SP-16.
>
> 3. In insn 108, we are storing the value pointed by the register a5 in to a5.
I would describe it as a load from memory, but, yes.
> Is my deduction for insn 108 right?
> If it is right, shouldn't the expression be like this:
> (mem/c:SI (reg/f:SI 13 a5) [0 S4 A32])) 15 {movsi_load} (nil)
Yes, probably it should. You neglected to say which dump you are
looking at. REG_POINTER, which is the flag that generates the /f, is
not reliable after reload.
Does it matter? In a memory load, the register has to hold a pointer
value anyhow, so I don't see how it could matter for code generation.
REG_POINTER exists because on the PA addresses which use two registers
need to know which one is the pointer and which is the offset, for
some hideous reason which I hope I never learn. In a memory address
with only one address REG_POINTER doesn't seem like an interesting
flag.
Ian