similar to: [LLVMdev] Compiling errors for tracelib.c

On Fri, 28 Jan 2005, Henrik Bach wrote: > Is there something wrong with my llvm-gcc compiler?: > c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:54: warning: type > defaults to `int' in declaration of `PRIMES' > c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:56: warning: data > definition has no type or storage class It looks like that file had

Rahul, Were you talking about tracing in the sense of "profiling" (which Anand did), or tracing of values as they are computed for debugging generated code (which I did)? For tracing of values for debugging, the answer is yes: we insert code in each BB and print out the values computed in that BB that are live at the end of the BB (so we don't print out temporaries computed and

> > yesterday I got new SuSE 9.1 DVD, so i am going to enter this > > river again. Perhaps, this time all will be fine. > > Sounds great, please let me know how it goes. SuSE 9.1 is running OK. after 30 minute of compilation i get first errors: ********************* make[2]: Leaving directory `/pool/tmp/llvm/runtime/libtrace' make[2]: Entering directory

Hi, Thank Brian Gaeke so much. Following TraceBasicBlocks.cpp, I modified the code as below and could insert instruction or function I need into anywhere in Module. But it works well without BB->getInstList().push_back(InstrCall), and if I add the BB->getInstList().push_back() following new CallInst(), I got error information when runing opt. What is the reason for it? And is it necessary

Anyone else getting this when building the latest mesa? make[3]: Entering directory `/usr/local/nouveau/mesa2/mesa/src/gallium/targets/dri-nouveau' gcc -c -I. -I../../../../src/mesa/drivers/dri/common -Iserver -I../../../../include -I../../../../include/GL/internal -I../../../../src/mapi -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary

> What I want to do is to insert a call funcation into each basic > block, which is for statistic some information. I recommend that you look at the various pieces of code under llvm/lib/Transforms/Instrumentation, e.g. BlockProfiling.cpp and TraceBasicBlocks.cpp. They do essentially the same thing as you are trying to do. > 1) I implement call function in another c/cpp file and >

Hi llvmer, I am trying to learn how to use llvm. My question is described as the following, there has already a testcase code, and I get bytecode by using llvmgcc. What I want to do is to insert a call funcation into each basic block, which is for statistic some information. 1) I implement call function in another c/cpp file and can I insert the external call function to existed bytecode ? if it

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

Right now I am trying to capture the function name and the number of arguments , so this following is the pass I wrote . ------------------------------------------------------------- struct pass06a : public ModulePass { virtual bool runOnModule(Module &M) { std::vector<const Type*> pList; pList.push_back( PointerType::get(Type::SByteTy) ); pList.push_back(

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

HI , I understand that the standard C library functions are executed using the native library of the host machine. ( for example when we execute a bytecode to extract the profile info ) Is it possible to extract for each standard library function that is executed , the arguments that the function is called with. For example if printf ("%d", some_int ) when called during runtime

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

On Sat, 1 May 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > > > yesterday I got new SuSE 9.1 DVD, so i am going to enter this > > > river again. Perhaps, this time all will be fine. > > > > Sounds great, please let me know how it goes. > > SuSE 9.1 is running OK. > after 30 minute of compilation i get first errors: > *********************

https://bugs.freedesktop.org/show_bug.cgi?id=45454 Bug #: 45454 Summary: Compilation failure: nouveau_dri.so.tmp: undefined reference to `st_gl_api_create' Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity:

On Fri, 30 Apr 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > > The nightly tester is used for two purposes: making sure that nothing > > breaks (the unit tests) and keeping tabs on how well performance is doing > > (the spec and most multisource tests). It's not a reliable way to do > > serious benchmarking, but can give good insights into where

> The nightly tester is used for two purposes: making sure that nothing > breaks (the unit tests) and keeping tabs on how well performance is doing > (the spec and most multisource tests). It's not a reliable way to do > serious benchmarking, but can give good insights into where things can be > improved. hm, one day, the great benchmarking will be a reason to use LLVM, so, i

Hi LLVM'ers, has anyone read the license details for MASM32 and understood how these fit in with Open Source projects, especially GPL? - As far as I can see - no one is allowed to license projects under GPL or at worst other OS licenses nor the deritives of the project, if you're using MASM32. Are the MASM backend compatible with the MS version of MASM or other not so license

Here's the new MASM backend. It has the following files :- lib/Target/X86/X86AsmPrinter.h lib/Target/X86/X86AsmPrinter.cpp lib/Target/X86/X86MASMPrinter.h lib/Target/X86/X86MASMPrinter.cpp lib/Target/X86/X86.td lib/Target/X86/X86InstrInfo.td lib/Target/X86/makefile Makefile.rules win32/x86/x86.vcproj