similar to: [LLVMdev] #include problem

On Jun 3, 2008, at 6:48 AM, Zhongxing Xu wrote: > Hi, > > On Fedora 9 GCC 4.3, > > LLVMCConfigurationEmitter.cpp needs #include <typeinfo>. > ValueTracking.cpp needs #include <cstring>. Fixed, thanks: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080602/063303.html -Chris

Index: include/llvm/ADT/APInt.h =================================================================== --- include/llvm/ADT/APInt.h (revision 55101) +++ include/llvm/ADT/APInt.h (working copy) @@ -20,6 +20,7 @@ #include <cassert> #include <iosfwd> #include <string> +#include <cstring> namespace llvm { class Serializer; -------------- next part -------------- An

Please commit. On Aug 20, 2008, at 8:02 PM, Zhongxing Xu wrote: > Index: include/llvm/ADT/APInt.h > =================================================================== > --- include/llvm/ADT/APInt.h (revision 55101) > +++ include/llvm/ADT/APInt.h (working copy) > @@ -20,6 +20,7 @@ > #include <cassert> > #include <iosfwd> > #include <string> >

Sanjiv Gupta wrote: > Hi Mikhail, > > What is mentioned in the reference manual is this: > > // Evaluates to "cmdline1" if the option "-A" is provided on the > // command line; to "cmdline2" if "-B" is provided; > // otherwise to "cmdline3". > > (case > (switch_on "A"),

Hi, On Sat, Sep 5, 2009 at 9:12 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > Is the patch below ok? > > Index: LLVMCConfigurationEmitter.cpp > =================================================================== > --- LLVMCConfigurationEmitter.cpp    (revision 80668) > +++ LLVMCConfigurationEmitter.cpp    (working copy) > @@ -1141,6 +1141,7 @@ >          

At first I'll try the simplest strategy: put the instruction in the machine BB corresponding to the LLVM BB where it comes from. To implement this, I plan to add an operand to non-passive node which points to the BasicBlockSDNode which the node belongs to. Another idea is to use a side map to map each node to its block. But I guess it's difficult to keep the map consistent when

On Dec 21, 2009, at 5:30 PM, Zhongxing Xu wrote: > 2009/12/21 Chris Lattner <clattner at apple.com>: >> Hi All, >> >> A few of us got together and started an official LLVM (and its sub- >> projects) blog: >> http://blog.llvm.org/ > > Is it online? I cannot open it. If it's online, I highly suspect it's > blocked by the GFW. Yep, it's

The first question is code placement. How is the compiler going to decide which block (or blocks) to emit an instruction in? The answer to that will help determine how control relationships should be represented. Dan On Jun 7, 2010, at 11:56 PM, Zhongxing Xu <xuzhongxing at gmail.com> wrote: > I am trying to build a DAG for a whole function. The first problem I > met is to

I am trying to build a DAG for a whole function. The first problem I met is to assign a user for the last instruction of each basic block, be it BRCOND or other node. There is no natural user for such nodes. Without user, it will be removed in later phases. My idea is to use it as chain for nodes in the next basic block. Is this reasonable? -Zhongxing Xu -------------- next part -------------- An

I have another idea: let the BasicBlockSDNode points to the last node in its predecessor blocks. But this will introduce cycles into the selection DAG, making it not a DAG anymore. So what's the impact of a non-DAG on the existing DAG legalizers and combiner? On Wed, Jun 9, 2010 at 9:33 AM, Zhongxing Xu <xuzhongxing at gmail.com> wrote: > At first I'll try the simplest

2009/12/22 Chris Lattner <clattner at apple.com>: > > On Dec 21, 2009, at 5:30 PM, Zhongxing Xu wrote: > >> 2009/12/21 Chris Lattner <clattner at apple.com>: >>> >>> Hi All, >>> >>> A few of us got together and started an official LLVM (and its >>> sub-projects) blog: >>>  http://blog.llvm.org/ >> >> Is it

Hi Zhongxing, On 4/8/07, Zhongxing Xu <xuzhongxing at gmail.com> wrote: > I think the real difficult thing in path sensitive program analysis (or > symbolic execution) is not the lack of decision procedures, but the > translation of arbitrary pointer operations and library function calls in > C/C++ program into the mathematics supported by the automated theorem > prover. >

I am trying to symbolically execute LLVM assembly language. I found a possible semantic inconsistancy of the LLVM assembly language, or maybe my understanding is wrong. The C code is: #include <stdlib.h> 1 int f(void) 2 { 3 int a; 4 int *b = (int *) malloc(3*sizeof(int)); 5 a = 3; 6 return 0; 7 } I compile it with llvm-gcc 4 front end. The generated

Hi Mikhail, What is mentioned in the reference manual is this: // Evaluates to "cmdline1" if the option "-A" is provided on the // command line; to "cmdline2" if "-B" is provided; // otherwise to "cmdline3". (case (switch_on "A"), "cmdline1", (switch_on "B"), "cmdline2",

TableGen crashes while building llvm when it tries to generate /llvm/tools/llvmc/plugins/Base/AutoGenerated.inc from /llvm/tools/llvmc/plugins/Base/Base.td As a result AutoGenerated.inc is full of garbage and it's not possible to proceed any further. I've debugged TableGen and found out that it dies somewhere in EmitForwardOptionPropertyHandlingCode(). I've modified

I am doing inter-procedural static analysis, so I need to do DFS of call graph. llvm-gcc sometimes generates this kind of call instruction, which cause the call graph to be incomplete. But thanks for your information, instcombine really solves the problem. On 7/17/07, Chris Lattner <sabre at nondot.org> wrote: > > On Thu, 12 Jul 2007, Zhongxing Xu wrote: > > The current

On Apr 19, 2010, at 3:11 AM, Zhongxing Xu wrote: > Hi all, > > We did some benchmarks on code size with clang, gcc 4.5, and open64. Clang performed second in the test. The benchmark is CSiBE. Clang can't compile the linux kernel (some inline asm not supported) and replaypc (error: use of unknown builtin '__builtin_next_arg'). The concrete results are attached. Nice, I

On Mon, Apr 19, 2010 at 3:11 AM, Zhongxing Xu <xuzhongxing at gmail.com> wrote: > Hi all, > > We did some benchmarks on code size with clang, gcc 4.5, and open64. Clang > performed second in the test. The benchmark is CSiBE. Clang can't compile > the linux kernel (some inline asm not supported) and replaypc (error: use of > unknown builtin '__builtin_next_arg').

On Jun 11, 2010, at 12:48 AM, Zhongxing Xu <xuzhongxing at gmail.com> wrote: > I have another idea: let the BasicBlockSDNode points to the last > node in its predecessor blocks. But this will introduce cycles into > the selection DAG, making it not a DAG anymore. > > So what's the impact of a non-DAG on the existing DAG legalizers and > combiner? Lots of stuff

On 29 nov 2010 03:47 "Xu Zhongxing" <xuzhongxing at gmail.com> wrote: > Hi, > I enjoyed the new coding style in recent patches. Camel case makes it > easy to pick a descriptive name. Starting functions and variables with > lower cases reduces chances to conflict with a type name. On the other hand, having names that only differ in the case of a single character, is not