%rsp-relative loads, stores, effective addresses

[matsc-at-sics-se]

I'm not sure where in the tool-chain this should go, but here are some initial thoughts. This issue is strongly related to spilling.

From SU_init_alloc_mem.uni:

    o53: [t69] <- LEA64r [%stack.0,1,_,0,_]
    o58: [t79] <- MOV64rm [%stack.0,1,_,0,_] (mem: 5)
frame:
    %stack.0: offset = 0, size = 16, align = 8

Now pretend that the last line had read:

    %stack.0: offset = 32, size = 16, align = 8

Then somewhere the two operations should be transformed into:

    o53: [t69] <- LEA64r [%rsp,1,_,32,_]
    o58: [t79] <- MOV64rm [%rsp,1,_,32,_] (mem: 5)

Note that o53/t69 is in fact rematerializable, provided that %rsp does not change in the mean time. That could depend on context and is related to ADJSTACKCALL* magic.

Finally, the "memory" part of the register array should roughly correspond to the stack frame, I guess.

[matsc-at-sics-se]

Some more thoughts.

On ARM, transformations that expose the stack pointer in sp-relative reads/writes/leas seem to happen in uni export. I suppose X86 can do the same.

Here is an idea for handling temporaries allocated to the memory register bank on X86. X86 has plenty of instructions of the forms:

• ADD64mi32: adds a constant to a memory operand
• ADD64mr: adds the context of a register to a memory operand
• ADD64rm: adds the context of a memory operand to a register
• ADD64rr: adds the context of a register to another register

plus some variants, for most ALU operations.

Suppose that we introduce Unison pseudos ("u" for Unison) for most instructions with memory operands:

• [t1] <- ADD64ui32 [t2,Constant] where t1 and t2 are congruent and in memory
• [t1] <- ADD64ur [t2,t3] where t1 and t2 are congruent and in memory and t3 is among the GPR
• [t1] <- ADD64ru [t2,t3] where t1 and t2 are congruent and among the GPR and t3 is in memory
• [t1] <- ADD64rr [t2,t3] where t1 and t2 are congruent and among the GPR and t3 is among the GPR (not a pseudo)

Then uni export can transform them to native X86:

• ADD64mi32 [%rsp,1,,offset,,constant]
• ADD64mr [%rsp,1,,offset,,reg]
• ADD64rm [reg,%rsp,1,,offset,]
• ADD64rr [reg,reg]

and an ADD64* selected by llvm can be turned into a choice

{ADD64ur, ADD64ru, ADD64rr}

Congruent memory operands is a new(?) Unison feature, which likely interferes with their current preassignment logic. So that algorithm needs revisiting.

[matsc-at-sics-se]

I added an ImportPostLift transformation that turns things like:

    o97: [t94] <- MOV32rm [%stack.0,4,t93,0,_] (mem: 0)
frame:
    %stack.0: offset = 80, size = 12, align = 8

into:

    o97: [t94] <- MOV32rm [rsp,4,t93,80,_] (mem: 0)

It seems to work for now, but may need revisiting when stack frames are sorted out.

[matsc-at-sics-se]

Largely handled in the closed issue #14 . Closing the issue. Temporaries residing in memory and congruent memory operands will be the topic of another issue.