similar to: [LLVMdev] doxygen docs

On Tue, 15 Nov 2005, Sameer D. Sahasrabuddhe wrote: > The docs available on illuvium.com are different from the one's present in > the doxygen tarball on the same page ... can the tarball be generated from > the same docs as the browseable version? I considered crawling the > illuvium.com site, but it would be better to simply have a tarball available. Agreed. I have been

Chris Lattner wrote: >> I tried generating the docs myself ... doxygen simply refuses to >> create pages for classes defined in anonymous namespaces in cpp files. >> I enabled options such as EXTRACT_ALL, EXTRACT_PRIVATE and >> EXTRACT_LOCAL, but no luck. How is the publicly available >> documentation generated? > > They are generated from the Makefile in

Marco Matthies wrote: >> make[2]: Entering directory `/home/sameerds/data/llvm-1.6/tools/llc' >> llvm[2]: Linking Debug executable llc >> `.gnu.linkonce.t._ZNK4llvm14TargetLowering12getValueTypeEPKNS_4TypeE' >> referenced >> in section `.rodata' of >> /home/sameerds/data/llvm-1.6/Debug/lib/LLVMSelectionDAG >> .o: defined in discarded

It seems the mail you are referring to never made the list: it's not in the archives and not in my mailbox. Take a look here: http://lists.xiph.org/pipermail/flac-dev/2012-December/thread.html It's probably still waiting for moderation. On 07-01-13 17:07, Olivier BLIN wrote: > On 29/12/2012 00:06, Olivier Blin wrote: >> When building outside of the source tree, the Doxyfile

I want to create a simple map from a Value to the instruction that defines it. Such a map is present inside SchedGraph, but I need it in a much simpler context. If I got it right, I create a new AnalysisGroup, and write a pass that implements it. What kind of pass should I derive it from? The mapping only makes sense within a function, so FunctionPass seems to be the right choice ... is that

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

Hi, Tried to build the 1.6 release on Debian unstable, but ran into link problems for some utils ... Copying the messages when building llc, the same error occurs for lli, llvm-db and some of the examples. Is this a problem with the compiler version? LLVMSelectionDAG.o itself builds correctly. make[2]: Entering directory `/home/sameerds/data/llvm-1.6/tools/llc' llvm[2]: Linking Debug

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

On Sat, Apr 02, 2005 at 11:35:30AM -0600, Chris Lattner wrote: > On Sat, 2 Apr 2005, Sameer D. Sahasrabuddhe wrote: > > I want to create a simple map from a Value to the instruction that > > defines it. Such a map is present inside SchedGraph, but I need it in > > a much simpler context. > > Is this in the context of the code generator? No ... I am just trying to feel

Just noticed that quite a few passes like LoopSimplify are implemented in a single .cpp file ... this makes it impossible to specify LoopSimplify using the "addRequired" method. Was there any particular reason to do it this way? I wouldn't mind doing the splitting myself, though I am not using the CVS versions right now. Also, it would be nice to have support for some sort of a

On Fri, Apr 29, 2005 at 08:10:17AM -0500, Chris Lattner wrote: > AU.addRequiredID(LoopSimplifyID); > > "LoopSimplifyID" is a marker that is used to identify the pass, which is > exported from the .cpp file. I'll have to declare a PassInfo* called LoopSimplifyID inside namespace llvm, in order for that to compile correctly, right? I was wondering why not simply

On Fri, Apr 29, 2005 at 10:32:18PM -0500, Chris Lattner wrote: > We could definitely expose the pass class itself, but there are no > implementation details or any other state that is useful. Yeah ... this, and Transforms/Scalar.h answer my original original question about why a lot of passes are present as a single CPP. The whole LLVM code generally abhors including class definitions

Recently wrote a pass that inserts a preheader for a loop that doesn't have one. When I tried to run it, I ran into a problem that became obvious in hindsight - the PHINodes need to be updated in places where the incoming control-edge has changed. Is there anything else that can be affected when a block is inserted into the CFG? Also, planning to write a helper function which will take care

On Sat, 2 Apr 2005, Sameer D. Sahasrabuddhe wrote: > I want to create a simple map from a Value to the instruction that > defines it. Such a map is present inside SchedGraph, but I need it in > a much simpler context. Is this in the context of the code generator? > If I got it right, I create a new AnalysisGroup, and write a pass that > implements it. What kind of pass should I

On Thu, Apr 28, 2005 at 11:22:26PM -0500, Chris Lattner wrote: > BasicBlock *SplitBlockPredecessors(BasicBlock *BB, const char *Suffix, > const std::vector<BasicBlock*> &Preds); > > Basically, given a BB with multiple predecessors, it inserts (and returns) > a new block, moving the predecessors in Preds to the new block and leaving

In LLVM 1.5, the function isLoopHeader fails to check for a null pointer after calling getLoopFor. Dunno if this is fixed in CVS, but attaching a patch anyway ... Sameer. -- Research Scholar, KReSIT, IIT Bombay http://www.it.iitb.ac.in/~sameerds/ -------------- next part -------------- --- LoopInfo.h 2005-06-29 17:42:43.000000000 +0530 +++ llvm/include/llvm/Analysis/LoopInfo.h 2005-06-29

On Tue, Jan 13, 2015 at 10:27 PM, Sameer Sahasrabuddhe < sameer.sahasrabuddhe at amd.com> wrote: > Ping! We need to close on whether everyone is convinced that symbolic > memory scopes have a significant advantage over opaque numbers. Either of > them will be examined by optimizations using a target-implemented API. I > personally don't think that readability in the LLVM

Hi, I’m trying to build the documentation. Running make in /docs, I get the following error: Makefile:44: Makefile.config: No such file or directory make: *** No rule to make target `Makefile.config'. Stop. According to this answer: http://stackoverflow.com/questions/4763381/no-rule-to-make-target-makefile-needed-by-makefile#comment40533198_4908782

Sameer D. Sahasrabuddhe wrote: > Hi, > > Tried to build the 1.6 release on Debian unstable, but ran into link > problems for some utils ... > > Copying the messages when building llc, the same error occurs for lli, > llvm-db and some of the examples. Is this a problem with the compiler > version? LLVMSelectionDAG.o itself builds correctly. > > make[2]: Entering

On 1/9/2015 4:14 AM, Chandler Carruth wrote: > On Wed, Jan 7, 2015 at 8:03 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > Here's what this looks like to me: > > 1. LLVM text format will use string symbols for memory scopes, > and not numbers. The set of strings is target