similar to: [LLVMdev] constructing 'for' statement from LLVM bitcode

Seung, On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > Ok. Note that LLVM can represent irreducible loops. You can handle > this through code duplication. > -Chris If you are willing to invest more effort into a more complicated analysis, in many cases you can even avoid code duplication. See this paper for details: @inproceedings{erosa94taming, author = {Ana M.

>> It has a section on "structural analysis" that you will find useful. >> >> Why do you want "for statements"? >> > > Thank you for this info, Chris. > I'm doing this 'cause I'm making a backend for a virtual machine > assembly has an instruction which is very similar to 'for' statement. > I know this seems quite

On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > Seung, > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > Ok. Note that LLVM can represent irreducible loops. You can handle > > this through code duplication. > > -Chris > > > If you are willing to invest more effort into a more complicated analysis, > in many cases you

Hello, guys. I am trying to construct higher-level 'for' from the low-level LLVM bitcode(ver 1.9). It's partly successful thanks to David A. Greene's advice suggested to use Control Dependence Graph(CDG). I could find which BB contributes to form which loop with CDG. For example, for this simple function: ----------------------------------------------------------- void bsloop(int

Daniel, On 8/30/07, Daniel Berlin <dberlin at dberlin.org> wrote: > On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > > Seung, > > > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > > Ok. Note that LLVM can represent irreducible loops. You can handle > > > this through code duplication. > > > -Chris >

New version of Calysto reports a warning that looks like a bug to me: ------------------------------------------ Possible NULL-ptr deref (vc27053): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1823 Bug: ?? Explanation: choose_dh (dh.c:111) calls fopen twice (@120). If the first call to fopen fails (returns NULL), but the second one succeeds, fgets (@129) is called with f==NULL.

Hi everybody! I recently started using llvm in a project on inferring additional information about pointers based on their types, casts, etc. The following simple example is giving me a headache :): typedef struct { int a; short b, c; int d, e, f; } foo; void bar(foo f) { short s; s = f.b; } int main(void) { foo p; bar(p); } Because llvm doesn't allow structures and arrays

Hi Fredrik, On Tue, 2006-12-19 at 15:13 +0100, Fredrik Svensson wrote: > Hi, > > As Christmas approaches rapidly I would like to get some suggestions for > interesting compiler books, papers and other type of information that one > can read the few slow days over Christmas. > > Any recommendations ? I have the dragon book, but it would be fun to read > something on what

Hi, I've ran my static checker Calysto on openssh and found the following bug: Possible NULL-ptr deref (vc536): @/work/benchmarks/SOURCES/openssh-4.6p1/moduli.c:173 + ptr gtm returned from gmtime dereferenced without checking (gmtime can return NULL). There are probably more possible NULL-ptr dereferences, but Calysto currently does not check the usage of library functions (for instance, if

I've been playing around with llvm lately and I was wondering something about the bitcode instructions for basic arithmetic. Is there any plan to provide instructions that perform widening multiply, or add with carry? It might be written as: mulw i32 %lhs %rhs -> i64 ; widening multiply addw i32 %lhs %rhs -> i33 ; widening add addc i32 %lhs, i32 %rhs, i1 %c -> i33 ; add with carry

We would like to develop a code generator using LLVM for a target language that does not support conditional branches and in fact only supports structured control flow, eg. If and while. As far as I can tell that the problem with doing this in LLVM today, is that it does not support these high-level constructs and instead all control flow is implemented as branches. It is ³fairly²

2008/4/10, David Erosa <david.erosa at gmail.com>: > Public bug reported: > > Binary package hint: nut > > After updating to last nut package (2.2.1-2.1ubuntu6), the megatec_usb > driver seems to be working, except for the charge percentage: > > $ /lib/nut/megatec_usb -DDDDD -a SAI > ... > Checking device (0665/5161) (001/007) > - VendorID: 0665 >

Hi all, I spent several hours today trying to compile llvm-gcc4 from svn and llvm from cvs on amd64 linux. In the case anyone else decides to try the same, this could ease your pain: 1) check out llvm, llvm-gcc 2) create llvm-obj llvm-gcc-obj export LLVM_INSTAL=<install_dir> cd llvm-obj export LLVM_OBJ=`pwd` ../llvm/configure --prefix=$LLVM_INSTALL --enable-debug-runtime 4) At one point,

Wow... Thank you so much for this. I'll try this one. Thanks again, Wojciech. SJL ---- Original message ---- >Date: Sat, 15 Sep 2007 15:07:34 +0200 >From: Wojciech Matyjewicz <wmatyjewicz at fastmail.fm> >Subject: Re: [LLVMdev] constructing 'for' statement from LLVM bitcode >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > >Hi, >

Hi, I'm trying to compile some apps with the new llvm-gcc4 on amd64 linux to .bc files, rather than to the native code. The same process I used to build those apps before with llvm-gcc3 doesn't work: 1) export CC=llvm-gcc CXX=llvm-g++ CFLAGS="-g -fno-inline" CXXFLAGS="-g -fno-inline" 2) cd <whatever-app>; ./configure 3) make CFLAGS+=-emit-llvm

On Sep 29, 2006, at 2:05 PM, Domagoj Babic wrote: > > Check out scc_* iterators. Also note that the call graph > is not aware of the indirect calls, so you will need to write your > own CG implementation if you need to handle function pointers > soundly. > Chris, is this true? If so, it seems like a bad property for the CallGraphSCCPass framework. --Vikram

Hi all, On 11/28/06, Reid Spencer <rspencer at reidspencer.com> wrote: > * Venue: West Coast, USA. Probably either San Francisco Bay Area or > Seattle > * Time Frame: Post 2.0 release, summer 2007 > * Topics: Anything related to use or development of LLVM I'd vote for Seattle. The costs of organization should be lower than in the Bay Area. > * An indication of how

Unless I'm missing something, the problem lies directly with the fact that you are trying to do a link-stage operation with the GCC frontend. GCC, by default, probably runs "ld" or another system linker, which grabs the executable from binutils. This linker hasn't been modified (yet) to include support for .bc files, but you're compiler is emitting byte code to the *.o files.

On Oct 2, 2007, at 1:03 AM, Domagoj Babic wrote: > Hi all, > > I have the same problem. My guess is that when a structure > is passed as a parameter, you cast it into an array for optimization > reasons (less parameters, less stack space). This is not an optimization. This behavior is to be ABI complaint when emitting code for your OS. That said, this is not a very good way to

I appreciate your suggestions, some follow-up questions though.... >1) LLVM has the capabilities to do everything that you are trying to >re-implement. >2) Have you looked at the C backend? It recreates loops. It may not >create "for" loops but you can hack on it to do that. I wonder if you mean "goto elimination technique" by Ana Maria Erosa (