similar to: [LLVMdev] libs-only target

After running through bugpoint, I get this reduced function You can reproduce the problem with: opt bugpoint-reduced-function.bc -break-crit-edges -adce -verify Bugpoint is currently trying to narrow down which block breaks this, but is so far failing. It seems to be running out of memory rather than failing on a particular block. This is on freebsd 5.4, X86, llvm is compiled with gcc 3.4.2

How do I tell the code generator to enable tail calls on the X86? Since it is part of a library, I cannot pass a command line argument. -- -Alex

This was indeed a memory issue - the hard datasize limit on my freebsd box was 512 mb and this opt went over. Increasing hard limit fixed the problem. However, most unices have a 512mb limit - maybe insanely huge functions as this one should be automagically split somewhere? On Dec 24, Alexander Friedman wrote: > > After running through bugpoint, I get this reduced function > >

On May 16, Chris Lattner wrote: > On Mon, 16 May 2005, Alexander Friedman wrote: > > Would it be possible (ie, relatively straitforward) to do the > > following: Take the code in module A, compile it with the JIT (since > > we cannot make libraries in Windows), and save the resulting binary > > goo in some file. Later (in a different instance of the runtime), with >

On Sat, Jul 23, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sat, Jul 23, 2011 at 5:09 PM, Talin <viridia at gmail.com> wrote: >> So this was working fine for me until a few days ago when I checked out the >> most recent LLVM - the one with the new type system. Now I am getting the >> same error that I was getting previously. >> Is it

On Sat, Jul 23, 2011 at 5:09 PM, Talin <viridia at gmail.com> wrote: > So this was working fine for me until a few days ago when I checked out the > most recent LLVM - the one with the new type system. Now I am getting the > same error that I was getting previously. > Is it possible that your fix got unfixed when they merged in the new branch? I wouldn't be surprised if

Hi all, At the moment, LLVM includes the .l, .y sources that are compiled by flex and biston via make. This is fine for most unix developers. For windows developers, it's a bit more of a pain to download flex/bison, but is still a one-time thing. However, anyone releasing an llvm frontend will require their users to have flex/bison. Most (but not all) unix boxes have them, but almost no

On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote: >>> A couple of months ago, I started the process of updating my CMake scripts >>> to allow my compiler to be compiled

On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote: >> A couple of months ago, I started the process of updating my CMake scripts >> to allow my compiler to be compiled with clang. I quickly ran into a problem >> calling the LLVM libraries, which is that I would get

Cool, I'll check it out - thanks! On Wed, Jun 29, 2011 at 12:07 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: > > On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com> > wrote: > >> On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at

Hi list, The short version of my question: Is it easy to make a lightweight (read: small in size) linker loader for code produced by the llvm jit. Does it even make sense to do so? The longer version: Suppose I have some llvm bytecode module A, and I want to load and use that code in some runtime. The two obvious ways to do that are a) use the LLVM jit, or b) compile the module into a dynamic

Hi Alex, That sounds like the sort of information that should be extractable from the debug information metadata. Once you're in LLVM IR, things like class names and source types are not guaranteed to be preserved in a reverse-mappable sort of way (from IR names to source names) in the IR itself. The debug information, however, is intended to do exactly that. -Jim On Oct 19, 2010, at 12:52

Hi, we use the llvm to lower c++ code to c code which can be run through our abstract interpretation framework (based on CIL). Along with the c code we emit some structured text files that contain the "lost" information (class hierarchy, private/public attributes etc). In order to output this information in a sensible way we need to pass unix paths and some more case sensitive

On Sun, Jun 8, 2008 at 7:57 PM, Thomas Hudson <hudson at speakeasy.net> wrote: > I've been playing with LLVM for a couple of months now and really am > enjoying myself. I finally got around to doing something useful and > had started implementing bindings for Ruby. I've been working off the > tip of trunk and realized my build didn't have shared libs. I've spent

I've been playing with LLVM for a couple of months now and really am enjoying myself. I finally got around to doing something useful and had started implementing bindings for Ruby. I've been working off the tip of trunk and realized my build didn't have shared libs. I've spent the better part of a day trying to build llvm with shared libraries with no luck on either Mac

LLVM list, I bumped into Alex Friedman in the hall today and by coincidence he mentioned that they were switching to LLVM for their PLT Scheme JIT project. I had evaluated LLVM a few weeks ago for my own purposes, but decided that it was too C/C++ centered and that critical features such as tail call optimization and other stack manipulation features were likely stagnant. So naturally I asked

On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote: > A couple of months ago, I started the process of updating my CMake scripts > to allow my compiler to be compiled with clang. I quickly ran into a problem > calling the LLVM libraries, which is that I would get segfaults when calling > LLVM API functions. I posted about this on both the clang and llvm-dev >

On Jun 8, 2008, at 9:36 PM, Eli Friedman wrote: > > If you'd like to elaborate on why exactly you need shared libs, you > might get a better answer. > Because I'm writing an extension to a scripting language interpreter. Perl/Python/Ruby all need to be able to dynamically load the library when the user 'requires' or 'imports' the extension. Obviously I can

Hi, we're writing a new target backend (based on the c backend) for the llvm. We need to pass case sensitive strings from the command line to the backend (unix paths). Currently we're using the Subtarget features string to relay the information. It turns out that the llvm applies a to_lower to the this string, so unix paths become basically useless. Is there a better way to pass this

On May 9, Chris Lattner wrote: > To me, the best interface is the most simple: I would suggest just > wrapping the llvm classes and methods you need with simple functions, e.g. > > llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function, > etc. > > If kept simple, standardized, and generic, I think it would be very useful > to people (even if