[cfe-dev] Patch attached for stack-less model

[Alireza.Moshtaghi at microchip.com]

Thank you for your reply,
Attached please find the patch I made from my latest update of clang
from Friday. This is my first time to submit patch to this group, so
please let me know if there is any problem.

Thanks
Ali

-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com] 
Sent: Wednesday, April 23, 2008 9:19 PM
To: Alireza Moshtaghi - C13012
Cc: cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] stack-less model on small devices

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-svn.txt
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080428/ff57be1b/attachment.txt>