search for: yafl

...it seems to me you could just avoid the stack walking entirely and add > $k-1$ arguments to each function at level $k$, i.e., at most 2 arguments > in all. This may even be an easy first implementation. I use this method with filtering unused in nested function args and local vars in my YAFL frontend (not finished :(( - at this moment generate LLVM bytecode but doesn't have all runtime suport code writed) Vladimir

>> I use this method with filtering unused in nested function args and local >> vars >> in my YAFL frontend (not finished :(( - at this moment generate LLVM >> bytecode but doesn't have all runtime suport code writed) > > So do you mean you pass static links for parent function stack frames as > arguments? How do you generate them? > Sorry, I must more careful read text....

...ust avoid the stack walking entirely >> and add $k-1$ arguments to each function at level $k$, i.e., at most >> 2 arguments in all. This may even be an easy first implementation. > > I use this method with filtering unused in nested function args and > local vars > in my YAFL frontend (not finished :(( - at this moment generate LLVM > bytecode but doesn't have all runtime suport code writed) So do you mean you pass static links for parent function stack frames as arguments? How do you generate them? --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc....

...f >> LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars). > > I'm not sure about this, perhaps Reid would like to comment? > Patch attached. This patch with header installation patch ( http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html ) let external project (I am test it at my YAFL frontend for LLVM) build using installed LLVM version instead using LLVM obj/src dirs. After patch applying: If LLVM_SRC_ROOT/LLVM_OBJ_ROOT variables set project use for build LLVM object/source dir (current behavior) or else if LLVM_ROOT set project use for build installed LLVM dir or else proj...

...T vars). >> >> I'm not sure about this, perhaps Reid would like to comment? >> > Patch attached. > > This patch with header installation patch ( > http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html ) > let external project (I am test it at my YAFL frontend for LLVM) build using > installed LLVM version instead using LLVM obj/src dirs. I think the patch looks basically sane. The one wierd thing I notice is the replacement of mklib with libtool. However, this is definitely something Reid should review. I think he's currently out...

>> Patch attached. >> >> This patch with header installation patch ( >> http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html ) >> let external project (I am test it at my YAFL frontend for LLVM) build >> using installed LLVM version instead using LLVM obj/src dirs. > > I think the patch looks basically sane. The one wierd thing I notice is > the replacement of mklib with libtool. Ops... I must be more careful. Updated patch attached. I use for build l...

On Nov 21, 2004, at 4:11 AM, Dirk Muysers wrote: > Was there already some reflection about how to lower the concept of > nested > functions (and the corresponding static links) into llvm? > > Dirk Muysers. I have not seen a discussion of this and none of our current front-ends need it. A straightforward way to add support for this would be: (a) Lower nested procedures into

On Wed, 9 Mar 2005, Vladimir Merzliakov wrote: > I create test program and assert failed in it: > > { \2 *, sbyte * } > Assertion failed: (!NewSTy->isAbstract()), function main, file > /usr/home/wanderer/work/LLVMTest/obj/../src/tools/tool/Test.cc, line 28. > > Testcase source attached. Thanks, that definitely is a bug. Patch here:

In VMCore/Module.cpp i found line (254): ((Value*)Ty)->setName(Name, &ST); Type is not Value now and for me this code call llvm::DerivedType::addAbstractTypeUser (I think it have same index in Type VMT in as setName in Value VMT) with random argument values and terminated with assert fail: Assertion failed: (isAbstract() && "addAbstractTypeUser: Current type not

On Thu, 3 Feb 2005, Vladimir Merzliakov wrote: >> Doing it this way >> allows you to re-use the LLVM build system, as opposed to building your >> own set of Makefiles. > I have pre-LLVM projects in C++ with often used at Unix C++ source file > extention .cc > I modify LLVM build system (original LLVM Makefile.rules already partly > support .cc extention, > for

...w building from installed) Reid. Vladimir Merzliakov wrote: >>> Patch attached. >>> >>> This patch with header installation patch ( >>> http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html ) >>> let external project (I am test it at my YAFL frontend for LLVM) >>> build using installed LLVM version instead using LLVM obj/src dirs. >> >> >> I think the patch looks basically sane. The one wierd thing I notice >> is the replacement of mklib with libtool. > > Ops... I must be more careful. Update...

Was there already some reflection about how to lower the concept of nested functions (and the corresponding static links) into llvm? Dirk Muysers.

> Doing it this way > allows you to re-use the LLVM build system, as opposed to building your > own set of Makefiles. I have pre-LLVM projects in C++ with often used at Unix C++ source file extention .cc I modify LLVM build system (original LLVM Makefile.rules already partly support .cc extention, for example, in Sources and FakeSources make vars setup code). Is attached patch

----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, March 08, 2005 6:31 PM Subject: Re: [LLVMdev] Recursive Types using the llvm support library > On Tue, 8 Mar 2005, Vladimir Merzliakov wrote: > >>>> An example where something really simple like the