similar to: [LLVMdev] CFE debug info progress

Hi, I have a large-ish application I'm trying to build with LLVM, so I replaced g++ in the Makefiles with llvm-g++. This appears to work fine when I pass -Wl,-native to generate an ELF executable, but I want to control the inlining threshold it uses, so I am now passing -Wl,-disable-inlining and -Wa,-disable-inlining, and having it generate LLVM bytecode, then running opt -inlining to generate

On Mon, 3 Apr 2006, Michael McCracken wrote: > the bytecode with lli - I get the following error: > > $ lli -load=/home/mmccrack/linux/lib/libTau.sh leo-inline-300-tau.bc > ERROR: Program used external function > '__llvm_cxxeh_allocate_exception' which could not be resolved! This is most likely because you are trying to link with llvmgcc, not with llvm-g++. Make sure that

Hi, I'm having some problems cross-compiling from ppc (OS X) to x86 object files and to ia64, at all. I'd appreciate some advice as to whether or not I'm actually supposed to be able to do this, and what's wrong if so. Here's how I configured it: ../llvm-darcslocal/llvm/configure --with-llvmgccdir=$LLVMGCCDIR --prefix=$HOME/Documents/hpcl/LLVM/install The results work fine

OK, I noticed a few problems with my previous email, so I will boil the question down: What I want to do is compile for x86 and ia64 from darwin. I also want to load my own passes into opt and llc. Should I be using llvmc at all here, or should I be doing something like llvmgcc -> gccas -> opt -> llc ? I've given up on the filetype=obj argument, so now the problem is that llc is

I'm having troubles running the test suite on OS X 10.4. Inside my objdir, 'make check' gives this: % make check llvm[0]: Running test suite

Hi, I'm just getting back to working on the cfe debug info after a brief hiatus. It appears that the appropriate place to be inserting stoppoints is starting in llvm_expand_stmt, using STMT_LINENO(t) . If that's not the best place, comments would be appreciated. Using the debug_hooks seems to be a non-starter, because they're called during rtl generation, which apparently isn't

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.

Michael, I've implemented a LOADABLE_MODULE feature in the makefiles: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html The approach taken is almost what you described below. However, I want to retain the distinction between a "regular" shared library and one that can be dlopened. So, if you specify SHARED_LIBRARY=1 you get a regular shared library

On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 1 Sep 2006, Michael McCracken wrote: > > I wanted to know if I should submit patches with comments around them > > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > > the tree. I'd like to make it as easy as possible to apply these, so > > let me know any rules I

Hi, I would like to get at the source line number(s) that a BasicBlock is generated from, and the only interface I see to this info in the code is from the debugger. After sifting through that, I think I might be able to do what I want by finding dbg_stoppoint intrinsics, but I'm not sure how to get to them. And, if there's an easy way, that'd be cool to know about. Also, I cant seem

Hi, It's taking me a while to get familiar with the cfe in order to add emitting stop points for debugging. It's a lot to work through, so in order to speed things up, I've got a few questions. Any help would be appreciated. I understand the design of the intrinsics once they're in the code, but how to generate them is still a little fuzzy, mainly because llvm_expand is a little

Unfortunately it's not that easy, although I'd love to fix it if I can figure out how. OS X 10.3 does have dlfcn.h and dlopen() - for 10.3, they added the dlcompat library that uses the OS X NSLink* stuff to support dlopen and dlsym. configure seems to pick that up fine. It seems like the code that's there already should work fine, so I'm not sure where else to look. I'm

OK, seems like I've got some more looking to do. From what I can find, the only difference with OS X and dynamic libraries is that you can't depend on the order of calling static constructors, but not that you can't depend on them getting called. :) If I find that library handling in LLVM needs changes to work with OS X, I'll send a patch. Thanks, -mike On Jun 19, 2004,

Hi, I can't get opt to list (in -help) passes that I load using -load. I see in the list archives that a similar problem has been brought up before but I didn't see whether it was resolved. Also, this is on Mac OS X, and the previous question was about Linux. This problem happens with the Hello pass, so I'll use that to illustrate. I'm using LLVM 1.2. The plugin loads with no

Hi, a while back I wrote that the llvm makefiles didn't create the correct kind of file for use on darwin with -load. Since then, both the shared library and makefile system have been overhauled significantly. So I checked again - as updated from CVS, the current makefiles don't build the right object type on darwin. If you follow the advice of 'Writing an LLVM Pass" tutorial,

Hi, just a quick question about the intent of the ApproximateLoopSize() function in LoopUnroll.cpp: If a loop contains debug stoppoint intrinsics, does it make sense to count them? My understanding is that they are removed when not running under llvm-db anyway, so we probably shouldn't make size judgements based on them. Is that right, or am I missing something? Anyway, if I'm right,

On 9/1/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > > On Fri, 1 Sep 2006, Michael McCracken wrote: [snip] > Now f951 doesn't crash when compiling, but still can't compile the > libgfortran files. It now finds some syntax errors in a generated file > that's part of the intrinsics

On Sat, 19 Jun 2004, Michael McCracken wrote: > I used the following short code to test loading the .dylib, and dlopen > works fine, but dlsym is less pretty - on OS X, it automatically > prepends an underscore to the symbol, which means that if you are > looking for main(), you ask for "main" and it looks for "_main", which > is how the symbols are named in

On Oct 31, 2008, at 1:29 PM, Török Edwin wrote: > Hi Dan, > I am actually more interested in Analysis working in presence of debug > info, but in order to get any meaningful results, you need to run some > transformations, at least GVN, otherwise loops aren't transformed to > canonical form either. Right. > So we could: > - teach GVN that a dependency on a debug

Solved. Short version: You don't need to change DynamicLinker.cpp at all. dlopen() should just work, except that the defaults for libtool are to produce the wrong kind of shared object. On OS X, libtool needs to be passed the -module option to create dlopen-able objects: % diff Makefile.rules.old Makefile.rules 326c326 < Link := $(LIBTOOL) --mode=link $(CXX) --- > Link