similar to: [LLVMdev] Name of Function's original module during link-time optimization

Hi Bram, On Sun, 2006-09-24 at 22:58 +0200, Bram Adams wrote: > Hi, > > During link-time optimization using llvm-ld, I occasionally need to > find the name/ID of the original module/bytecode file a Function > belonged to. In order to do this I added a nameOfPreviousModule- > attribute to Function and some getters/setters (see attached patch). > However, I can't

Hi, Reid Spencer wrote: > Call getBytecodeModuleProvider (see Reader.h). The problem is that one needs to provide the filename of the original module as the argument of getBytecodeModuleProvider, whereas this is unknown (it's exactly what we're trying to find out). But, by looking where this method is called in the original bytecode loading process, I figured out a way to set the

On Mon, 25 Sep 2006, Bram Adams wrote: > Reid Spencer wrote: >> Call getBytecodeModuleProvider (see Reader.h). > The problem is that one needs to provide the filename of the original module > as the argument of getBytecodeModuleProvider, whereas this is unknown (it's > exactly what we're trying to find out). > > But, by looking where this method is called in the

Hi, Op 25-sep-06, om 23:26 heeft Chris Lattner het volgende geschreven: > On Mon, 25 Sep 2006, Bram Adams wrote: >> Haven't tried them extensively yet, so I'm >> wondering whether the remark in your mail of 09/04/2006 to Nikhil >> Patil about >> "-g currently disables many optimizations" still holds. > > Yes, that is true. What are you trying

Hi, Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven: > What are you trying to accomplish? Why not use location records from > debug info? You mean the debugging intrinsics? Just discovered them :-), and I guess that's exactly what I need. Haven't tried them extensively yet, so I'm wondering whether the remark in your mail of 09/04/2006 to Nikhil Patil

On Mon, 25 Sep 2006, Bram Adams wrote: > Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven: >> What are you trying to accomplish? Why not use location records from >> debug info? > > You mean the debugging intrinsics? Just discovered them :-), and I guess > that's exactly what I need. Haven't tried them extensively yet, so I'm >

On Mon, 25 Sep 2006, Bram Adams wrote: >> On Mon, 25 Sep 2006, Bram Adams wrote: >>> Haven't tried them extensively yet, so I'm >>> wondering whether the remark in your mail of 09/04/2006 to Nikhil >>> Patil about >>> "-g currently disables many optimizations" still holds. >> >> Yes, that is true. What are you trying to do?

Hi, Chris Lattner wrote: > I'd suggest writing a little pass that strips out debug intrinsics. > OK, I did this and it works (the strange seg fault also disappears after all declared debug variables are gone)! In a first phase, all intrinsic instructions are discarded after extracting their data into annotations attached to the relevant Function. Then, a second phase wipes out the

Hi, Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven: > I looked over your patch and it looks good. I applied a patch based on > yours. The llvm-ld tool now uses the PluginLoader just like the opt > tool. It will also run some cleanup passes after the loaded plugins > run > to ensure cruft is removed. OK, thanks. Your patch seems to work, although I also get

Hi, Today I managed to link ioquake3, but generating a binary does not work yet. 1) On OSX, I get: Error: Code generator does not support intrinsic function 'llvm.ppc.altivec.lvsl'! when I do: llc file.bc -march=c -o file.c 2) On Linux X86, llc does not give any problem, but I get this while compiling the generated .c file: error: unknown register name 'S' in

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with the > header files using uintptr_t (not recognised as a type). Putting "#include > <stdint.h>" in include/llvm/BasicBlock.h (llvm) and in > "include/llvm/ValueSymbolTable.h" (frontend) resolved this. Ok. This is now fixed on the release branch. Thanks! > Also, I got linking

Hi, Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven: 1) Download llvm-gcc4 binary and llvm. Compile and run make check. I did a debug build on OSX 10.4.9 and everything went fine. Results of "make check" (see ppc.log): === Summary === # of expected passes 1630 # of unexpected failures 21 # of expected failures 2

Hi, There is a typo in $LLVM_SRC/Makefile.rules on line 750 where it says : SharedLibKindMessage := "Lodable Module" instead of SharedLibKindMessage := "Loadable Module" Op 15-nov-06, om 15:54 heeft Bram Adams het volgende geschreven: > Didn't check > LLVM's test suite. Doing the simple LLVM-tests (on Slackware 10.2) gets: === Summary ===

> When building LLVM 1.9 on OSX 10.4.8, I get (after a while, see attachment): > > make[1]: *** No rule to make target `/path/to/llvm-build/Debug/bin/tblgen', > needed by `/path/to/llvm-build/lib/VMCore/Debug/Intrinsics.gen.tmp'. Stop. > make: *** [install] Error 1 > > when doing: > > $LLVM_SRC/configure --prefix=$LLVM_INSTALL --with-llvmgccdir=$LLVM_FRONT

Do you have a verify option in your loaded module? Reid. On Sun, 2006-08-20 at 22:04 +0200, Bram Adams wrote: > Hi, > > Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven: > > > I looked over your patch and it looks good. I applied a patch based on > > yours. The llvm-ld tool now uses the PluginLoader just like the opt > > tool. It will also run

Hi, Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven: >> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build >> with the header files using uintptr_t (not recognised as a type). >> Putting "#include <stdint.h>" in include/llvm/BasicBlock.h (llvm) >> and in "include/llvm/ValueSymbolTable.h" (frontend)

Hi, Op 20-aug-06, om 22:26 heeft Reid Spencer het volgende geschreven: > Do you have a verify option in your loaded module? What exactly do you mean by "verify option"? Anyway, I did a grep on "verify" in my code, but found nothing. Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium)

Hi, Op 15-nov-06, om 03:26 heeft Tanya M. Lattner het volgende geschreven: > I'm able to reproduce this if I skip doing a "make" and directly do a > "make install" after configuring. I believe we require people to do > a full > build before attempting to install. So I don't think its really a bug. > Could you try doing a make first and then install?

Hi, Today, I've made the transition from LLVM 2.1 to 2.3. I invoke opt with two dynamic libraries to "-load", the first of which contains transformation passes and support code whereas the second one provides extra passes which make use of the first library's support code. In other words, the symbols loaded in for the first library should be available when the second