similar to: [LLVMdev] Changes to the DEBUG macro.

On Sat, 8 Jan 2005, Francisco Puentes wrote: >>> Would be great if we append into the documentation several "patters" >>> to show how perform with LLVM. It would accelerate the learn curve for >>> beginners like me, avoiding basic errors and mistakes. If I reach a >>> good level with LLVM I can make these. >> >> I'm not sure if I

> >>> Would be great if we append into the documentation several "patters" > >>> to show how perform with LLVM. It would accelerate the learn curve for > >>> beginners like me, avoiding basic errors and mistakes. If I reach a > >>> good level with LLVM I can make these. > >> > >> I'm not sure if I understand what you

On Fri, Jan 07, 2005 at 12:04:04PM +0100, Francisco Puentes wrote: > Would be great if we append into the documentation several "patters" > to show how perform with LLVM. It would accelerate the learn curve for > beginners like me, avoiding basic errors and mistakes. If I reach a > good level with LLVM I can make these. I'm not sure if I understand what you mean. Are

> > Would be great if we append into the documentation several "patters" > > to show how perform with LLVM. It would accelerate the learn curve for > > beginners like me, avoiding basic errors and mistakes. If I reach a > > good level with LLVM I can make these. > > I'm not sure if I understand what you mean. Are you looking for an > "LLVM

Ok, the last status update (http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-June/000416.html) was over 7 weeks ago, sorry about that. We've been really busy squishing bugs, improving stability, and otherwise improving the system for the release. Here are some of the major accomplishments in LLVM since the last update... 1. We finally have the go-ahead from the university to release LLVM

Many places in the documentation says the -debug and the -debug-only=... can be used to debug modules. However, I cannot find this option in llc (llvm version 2.8rc, DEBUG build). This doc explicitly uses -debug/-debug-only: http://llvm.org/docs/ProgrammersManual.html#DEBUG_TYPE Thanks, Jeff Kunkel

On Fri, 27 Feb 2004, Reid Spencer wrote: > This works as long as the libraries are fine-grained _enough_. They > probably are so I'm not going to make an issue out of this because there > are bigger fish to fry. If not, they can always be split up later. :) > > Well, in the long term we want to switch everything over to docbook, at > > which point it should just be a

----- Original Message ----- > From: "Matthias Braun via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, November 2, 2015 1:16:18 PM > Subject: Re: [llvm-dev] Prefixing DEBUG messages with DEBUG_TYPE (was re: [PATCH] D13259: LLE 6/6: Add

> I see a bunch of definitions scattered throughout LLVM, and I could not > find good documentation on them. I don't understand why they exist when > LLVM is being compiled with RTTI enabled. It seems to me that: > > isa<T>(x) is a substitute for (dynamic_cast<T>(x) != NULL) Misha seems to have answered your question, but documentation is found here:

Moving this discussion here from the review thread. RIght now, we have a few passes that prefix DEBUG message with various things, so folks using -debug can tell where the debug message came from. But this is not consistent, and in fact, most passes don't do it. Worse, the prefixes used do not often match the DEBUG_TYPE of the pass. It would be nice to fix this, and just have the DEBUG

Really JIT isn't my goal. I prefer use a native execution engine; and ok, I don't need save the generated Module so it ever lives in memory, so if LLVM doesn't generate relocatable code it's fine for me. About the reentrant lacks of LLVM, I can convert my own code - which build the Module - into a critical section so I think it is enough; but I need to know if several independent

>> Ok, here's the first batch. It converts the RecTy hierarchy over to >> use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to >> set up LLVM-style RTTI for your class hierarchy", which covers the >> previously undocumented (albeit not that complicated) process for >> hooking into Support/Casting.h. > > Cool. Please pull this

Hi All, I am going to clean up those doxygen links on LLVM Programmer’s Manual [1], some are lost and some are too old. However, I am confused on which doxygen link I should pick up. I see there are mutiple links exist on LLVM web site for LLVM classes. Take class Statistic as example, there are: - http://llvm.org/doxygen/Statistic_8h-source.html (the oldest one, I believe it's

Thanks for the info, Philip. I will update the LLVM Programmer’s Manual first. Regards, chenwj Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj 2017-04-02 18:11 GMT+08:00 Philip Pfaffe <philip.pfaffe at gmail.com>: > Hi chenwj, > > http://llvm.org/doxygen/Statistic_8h_source.html is the correct one. The > other two are remnants from older doxygen deployments.

> While I understand the motivations you describe above, something about > this bothers me. As a tool provider the LLVM developers are trying to > provide small/fast/quick linking tools. The above approach helps with > some of that. However, I'm an LLVM user and a big part of using LLVM is > linking my code with LLVM code. When the LLVM developers opt to make a > .o

FYI. I just changed how statistics are defined. This eliminates one static constructor for each statistic in the system, causing them to be statically initalized instead. To update any out of tree code, change this: Statistic foo("blah", "desc"); into: #define DEBUG_TYPE "blah" // before any #includes ... STATISTIC(foo, "desc"); Statistics are

>*nod* That's been the historic ELF+DWARF approach, but both MacOS (with dsyms+DWARF) and Windows >(COFF+CodeView+PDB) don't do it that way, and instead involve the linker to a degree. >Mostly I'm wondering if it'd be reasonable to (and if anyone would be interested in doing it) do >something more like the PDB support - fully debug-aware linking. Honestly saying I only

> Nope, types are immutable once created. The only thing you can do is "refine" opaque types to other types. There is a section in the programmer's manual on this: > http://llvm.org/docs/ProgrammersManual.html#TypeResolve > > -Chris So I succeeded in using a "PATypeHolder" for the "opaque" type, define a Type* with PointerType::getUnqual, prepare

June Status Update ------------------ Hi everyone, Since the last status update, we've had a lot of progress on various fronts. In particular, we passed the 15,000th commit to the llvm-commits list, we have some great new features and documentation, new people using LLVM, and (strangely enough) the MachineBasicBlock class seems to have received a lot of love. At this point, I'm

Thank you, I tried to compile it with llvm 3.4 through these commands: petsas at shinigami:~/software/poolalloc$ ./configure --with-llvmsrc=/home/petsas/software/llvm --with-llvmobj=/home/petsas/software/llvm petsas at shinigami:~/software/poolalloc$ make but I'm getting get this error: make[1]: Entering directory `/home/petsas/software/poolalloc/lib' make[2]: Entering directory