load/store in IR without stack/heap

Hi all,

Can anyone give an idea to solve my problem? I’m implementing backend part
using LLVM for my research architecture. The main issue is that this architecture
cannot use stack/heap. So, all the value should be stored in the register.
Given that architecture, load/store instruction in IR uses virtual register to load/
store the value. For example:
C source code is:

if(…) {
a = 1;
}
else {
a = 0;
}
c = a;

It’s IR from the front-end is:

;:3
store i16 1, i16 *a, align 2
br label %5
;:4
store i16 0, i16 *a, align 2
br label %5

;:5
%6 = load i16 *a, align 2
store i16 %6, i16 c

I used getCopyToReg in SelectionDAG for store instruction to store value, and getCopyFromReg
for load instruction. So, storage values in block ‘:3’ and ‘:4’ are stored in VR0 and
VR1 respectively. However, load instruction in block ‘:5’ cannot choose which register
should be read.
Can anybody give an idea to overcome such a case?

Thanks.

Jin

did you try mem2reg optimization pass?
this transform load/store operations to cheaper operations with virtual registers.

Hi all,

Can anyone give an idea to solve my problem? I’m implementing backend part
using LLVM for my research architecture. The main issue is that this architecture
cannot use stack/heap. So, all the value should be stored in the register.
Given that architecture, load/store instruction in IR uses virtual register to load/
store the value. For example:

It’s difficult to answer this question without understanding your architecture’s replacement for the stack and heap. While variables like those below can be moved into LLVM virtual registers using -mem2reg, not all variables can be promoted in such a fashion (for example, an address-taken local variable cannot be promoted to a register). Also, how does your architecture support structures and arrays? Does it support global variables? Is it designed to support programs written in languages such as C (in which the stack and heap are assumed to exist)?

There are some things that you can do to promote stack objects to global objects. If a call graph analysis (like the one found in LLVM or the one we provide in DSA) indicates that a function is not called recursively (i.e., it is not part of a strongly connected component in the call graph), then you should be able to replace the stack allocations within the function with a global variables (provided that the allocas are not in loops). I think you can do the same with heap allocations provided that they don’t escape the function in which they are allocated.

– John T.