[cfe-dev] stack-less model on small devices

[Eli Friedman]

On Wed, Apr 23, 2008 at 4:25 PM,  <Alireza.Moshtaghi at microchip.com> wrote:
>
>  Let me summarize...
>  (patches)
>  Ok, that makes sense to have the patches applied by someone else,
>  however, my patches will surely break other peoples work. I'm just
>  curious, how are you going to merge them? Conditional compiling?
>  Commandline flags?

You don't need to worry about it. Constantly remerging patchsets to
trunk is routine for anyone doing serious work in a large project like
this.

>  (Enforcing no recursion)
>  We are also implementing our own linker. In fact not only the recursion
>  thing, but also many other features can't work without a custom linker;
>  I can go over some details separately if you are interested.

Oh, okay.  Makes sense.

>  (llvm backend)
>  We have the code generation in llvm, although it is not complete, it is
>  just enough to prove the concept. The register spilling and other stack
>  dependent things will be handled in an unconventional way on the
>  function frame (the memory locations will be reserved at link time). The
>  linker can even decide if it can reuse (overlay) some of these frames
>  depending on how call graph looks like.
>
>  (alloca)
>  We tried code generation in llvm by replacing alloca with global
>  addresses however,
> (1) the name of local variable is not as easily
>  available,

Why does this matter?  I can't imagine that it's important to preserve
the names of local variables.

> (2)I don't feel quite comfortable with having the storage
>  class of variable change at the last phase of translation. It sounds
>  more reasonable to get it right in the front-end to begin with.

Hmm, my idea was that you'd allocate the memory for the alloca's along
with the space for spills and whatnot. I'm actually a bit surprised it
doesn't just work without any special changes; fixed-size alloca's
should be part of the stack layout, and therefore transparent to the
target.  That said, I don't know LLVM codegen that well.  I'd suggest
sending an email to LLVMdev if you're having trouble making it work.

If you really have to get rid of the allocas before codegen, I'd
suggest writing an llvm pass that converts the allocas to globals.  It
shouldn't be very hard; all you have to do is for every alloca, create
an equivalent global, then replace all references to the alloca with
references to the global.  It doesn't seem appropriate to attempt to
eliminate all allocas in the front-end; it limits your potential
flexibility with respect to other languages targeting LLVM, it makes
the code more difficult to optimize, and in theory an optimization
pass could introduce allocas (although I don't know of any such pass).

-Eli