similar to: [LLVMdev] source to source translation

Chris, I'm fine with using JIT, but I'm trying to understand this problem: 1. My LLVM program does not produce correct results 2. Using llvm-dis, I disassemble the bytecode to C 3. I recompile using GCC and the program _works correctly_. The only odd thing is when I recompile with GCC, I see these messages: pal3.c:195: warning: conflicting types for built-in function `strcmp'

Is there a pass that will transform this: %cc = seteq ushort %val, 0 into this: %cc = cast ushort %val to bool Would instcombine be the logical place to do this? Thanks.

The only thing I can think of is that string.h is being #included and has different signatures for memcpy and strncpy. Possibly "char" is not signed on your machine (very unusual) or some of the parameters are declared as "const". Reid. On Wed, 2004-04-14 at 18:19, Eric Zimmerman wrote: > Chris, > > I'm fine with using JIT, but I'm trying to understand this

Is there a way to set how aggressive the inliner pass (createFunctionInliningPass) without going through the command line interface? Is there any reason InlineLimit isn't an argument to the createFunctionInliningPass function? Thanks, Robert

Hi, I'm working on a CS326 compiler project, and I'm having some problems using string functions. Some LLVM programs produced are either aborting or giving incorrect results; however, if I disassemble the LLVM bytecode and recompile with GCC, everything works fine. I encountered the following error when running lli with '-force-interpreter' option: "Tried to execute an

On Thu, May 19, 2005 at 03:27:02PM -0500, Eric Zimmerman wrote: > Is there a pass that will transform this: > %cc = seteq ushort %val, 0 > > into this: > %cc = cast ushort %val to bool > > Would instcombine be the logical place to do this? In my situation, this bool value feeds a select instruction. Because casting inverts the condition, the select would have to

There was some discussion in the summer on the mailing list about atomicity and synchronization primitives for LLVM. Is there any progress being made in that department? -- Pertti

Is it possible to take the address of a basic block ? I'd like to put a whole bunch of these addresses into an array, and then select one to branch to. Eg. like a switch statement. (i'm thinking also of GCC's computed goto's) I'm finding the code generated by an llvm switch is a big bunch of compares and jump instructions, which i'm not sure is the most efficent way of

Guys, Is there some uniform way to find data dependence between two (sets of) instructions? There is use/def data, and there is AliasAnalysis information, but I am looking for something more high-level and uniform. I guess I am missing something, because such interface seems to exist once and then was abandoned. Any ideas? Victor -- IBM Research Lab in Haifa, Israel

Hi, i have some code that allocate some memory, store the pointer to a variable, read it back and deallocates it, like this: int %main(int %argc, ubyte** %argv) { %c_19 = alloca ubyte* %malloc_206 = malloc ubyte, uint 10 store ubyte* %malloc_206, ubyte** %c_19 %tmp_207 = load ubyte** %c_19 free ubyte* %tmp_207 ret int 0 } i expected the optimized to remove everything, but after running it the

On Wed, Mar 16, 2005 at 09:16:20PM -0600, Chris Lattner wrote: > >I am fairly new to the LLVM pass framework. My goal is to extend the > >CFGPrinter analysis pass to label the edges of the graph with their > >edge-counts from profile data. > > > >I can generate the CFGs using 'analyze', but I am having trouble > >loading the profile data. I added the

Chris Lattner wrote: >>ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and >>InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes >>from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, >>but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at >>least in CSIL) unfortunately does not have stdint.h, but it does

I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This is on persephone. Are you not getting this error? Perhaps I should check out a fresh tree and try to compile it? Rob On Apr 7, 2006, at 11:40 AM, Chris Lattner wrote: > On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: >> I just updated from CVS, and after doing a clean rebuild I get >> this

Just out of curiosity, now that explicitly managed stack frames [1] are possible (given support in the code generators), is the stack register freed for other uses when the LLVM system stack isn't being used? Sandro [1] http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt

> Is there some uniform way to find data dependence between two (sets of) > instructions? There is use/def data, and there is AliasAnalysis > information, but I am looking for something more high-level and uniform. > I guess I am missing then was abandoned. Any ideas? Nope, there currently isn't a uniform interface for doing so, at least not at the LLVM level. As you said,

On Wed, 28 Jun 2006, Simon Burton wrote: > Is it possible to take the address > of a basic block ? Nope. > I'd like to put a whole bunch of these > addresses into an array, and then select > one to branch to. Eg. like a switch statement. > (i'm thinking also of GCC's computed goto's) llvm-gcc supports gcc's computed goto's. You can see what code it

On Fri, 9 Nov 2007, [ISO-8859-1] Pertti Kellom�ki wrote: > There was some discussion in the summer on the mailing list > about atomicity and synchronization primitives for LLVM. Is > there any progress being made in that department? Nope, not that I know of. -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Tue, 13 Feb 2007, Nicola Lugato wrote: > Hi, i have some code that allocate some memory, store the pointer to a > variable, read it back and deallocates it, like this: ok > i expected the optimized to remove everything, but after running it > the code i get is: > > int %main(int %argc, ubyte** %argv) { > %malloc_206 = malloc [10 x ubyte] > %malloc_206.sub =

On Mon, 7 Jan 2008, Robert Zeh wrote: > Is there a way to set how aggressive the inliner pass > (createFunctionInliningPass) without going through the command line > interface? Nope. Well, you could call cl::ParseCommandLine yourself (passing in a static array) like llvm-gcc does, but other than that "no". > Is there any reason InlineLimit isn't an argument to the

Is the #include <endian.h> necessary for Linux or is that a leftover artifact from before? I'm trying to get this code to compile on MacOS (which is based on BSD), and stdint.h exists there, but not endian.h. --Vikram ---------------------------------------------------------------------- VIKRAM S. ADVE Assistant Professor E-MAIL: vadve at cs.uiuc.edu