similar to: [LLVMdev] Code Size Benchmark

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 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

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

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

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

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

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. >

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

On 4/9/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > > > Traditionally, such analyses have been considered too expensive to be > practical, and were mostly an academic curiosity. The core of the > problem is the lack of adequate automated decision procedures which > could quickly determine whether a set of constraints is satisfiable or > not, and if it is

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. 2010/11/23 Zhanyong Wan (λx.x x) <wan at google.com> > On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> > wrote: > > +llvmdev > > >

> > Spear takes a different approach - it is bit-precise, handles all > operators, but > currently doesn't handle arrays directly. However, the other mentioned > thm provers > handle arrays by encoding them as UIFs + several axioms. As UIFs can be > encoded > to SAT, I think that the theory of arrays could be as well. So, with a > bit of effort, > you should be

I build llvm+clang almost every day with Ubuntu 10.04. Everything goes fine. I guess it's your VirtualBox has too little memory. On Thu, May 6, 2010 at 4:12 AM, Samuel Crow <samuraileumas at yahoo.com> wrote: > After waiting through about 2 hours of hard drive spinning for Clang to > link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just > gave up trying

Dear LLVMers, This email is intended for those interested in path-sensitive analysis, integer overflow analysis, static analysis, and (perhaps) loop invariant computation. Traditionally, such analyses have been considered too expensive to be practical, and were mostly an academic curiosity. The core of the problem is the lack of adequate automated decision procedures which could quickly

After waiting through about 2 hours of hard drive spinning for Clang to link under my Xubuntu Lucid Lynx Linux setup on VirtualBox, ld finally just gave up trying to link it. I was using CMake's build scripts on version 2.7 release of LLVM and Clang. The version of ld is (GNU Binutils for Ubuntu) 2.20.1-system.20100303. Can anyone confirm this problem? If needed I'll cross-post this to

Is anyone using CSiBE ? http://www.inf.u-szeged.hu/csibe/ What things are people using for code size benchmarks for clang/llvm? tia. Reed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131115/7097624f/attachment.html>

I can't make R on a Solaris 9 box. Does anyone have any suggestions? Thanks in advance. <3>-> make `Makedeps' is up to date. `libbz2.a' is up to date. `Makedeps' is up to date. `libpcre.a' is up to date. `Makedeps' is up to date. `libz.a' is up to date. ../../../src/include/libintl.h is unchanged ../../../include/libintl.h is unchanged `localecharset.h'

Hi, I have been working towards developing compiler optimization tools targeting multi core processors while using LLVM IR as the starting point and building on top of the analysis and optimization passes available in the llvm source. Recently, I looked into Open64 and its intermediate representation WHIRL. Documentation for developers to use Open64 seems to be inadequate (when compared to LLVM