similar to: [LLVMdev] Directly emit LLVM IR?

Hello! I'm interested in using LLVM as a target for a compiler I've written in common lisp (SBCL). While I looked at perhaps wrapping the LLVM C++ interface, wrapping C++ in, well, anything not C++ is a pain. Someone on IRC mentioned that they didn't think I'd miss out on any functionality by directly emitting IR, but suggested I query the list. Do I miss out on any optimizations

On Feb 22, 2008, at 11:11, Eric Jonas wrote: > Hello! I'm interested in using LLVM as a target for a compiler I've > written in common lisp (SBCL). While I looked at perhaps wrapping > the LLVM C++ interface, wrapping C++ in, well, anything not C++ is a > pain. Someone on IRC mentioned that they didn't think I'd miss out > on any functionality by directly

> • Emit LLVM assembly from your compiler's native language. > for: very straightforward to get started > against: the .ll parser is slower than the bitcode reader when > interfacing to the middle end > against: you'll have to re-engineer the LLVM IR object model > and asm writer in your language > against: it may

thomas weidner wrote: > Hello, > > i want to implement a common lisp subset using llvm for fun. Out of curiousity, for which CL implementation is this targeted? sbcl? Or something you're rolling? The reason why I ask is that I expressed an outrageous opinion at Supercomputing back in November, to wit, that CL is probably the best language suited for today's multicore

I came across a quite interesting post from Ross Ihaka, thought would be good to share it and get the opinion of folks around here. I am not sure where to post this for the R community but since it has to do with development I thought or R-devel Ross Ihaka Newsgroups: comp.lang.lisp From: Ross Ihaka <ih... at stat.auckland.ac.nz> Date: Wed, 23 Jan 2008 10:35:26 +1300 Local: Tues, Jan 22

Scott Michel <scottm <at> rushg.aero.org> writes: > Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling? I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned. >

Yes, indeed! The SBCL lisp compiler (not llvm based) used to emit functions which would return either via ret to the usual instruction after the call, or else load the return-address from the stack, then jump 2 bytes later (which would skip over either a nop or a short jmp at original target location). Which one it used depended upon whether the function was doing a multi-valued return (in which

On 7/23/19 8:42 PM, John McCall via llvm-dev wrote: > > On 21 Jul 2019, at 12:29, James Y Knight via llvm-dev wrote: > > Yes, indeed! > > The SBCL lisp compiler (not llvm based) used to emit functions > which would > return either via ret to the usual instruction after the call, or > else load > the return-address from the stack, then jump 2

On Jan 3, 2010, at 10:10 PM, James Y Knight wrote: > In working on an LLVM backend for SBCL (a lisp compiler), there are > certain sequences of code that must be atomic with regards to async > signals. So, for example, on x86, a single SUB on a memory location > should be used, not a load/sub/store sequence. LLVM's IR doesn't > currently have any way to express this

> From: Wensui Liu <liuwensui at gmail.com> > Just curious how xlispstat is used in the industry and what's it strengthen > compared with other computing languages such as R or matlab? Almost not at all, though there are a few holdouts. On a related note, I've been doing some interesting things with a branch of LispStat for CommonLisp. It'll be more interesting when

>How is this different from the LISP and scheme macro system? The >program source is available to the programmer at both compile and >run-time and may be operated on arbitrarily (transforming code, adding >code, removing code, specializing code, making new "primitives", >modifying other macros, etc). There is a reason for LISP's syntax, it >is so you can program

On Mon, Jan 4, 2010 at 12:20 AM, Owen Anderson <resistor at mac.com> wrote: > > On Jan 3, 2010, at 10:10 PM, James Y Knight wrote: > >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. So, for example, on x86, a single SUB on a memory location >> should be

Responding to the original email... On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: > In working on an LLVM backend for SBCL (a lisp compiler), there are > certain sequences of code that must be atomic with regards to async > signals. Can you define exactly what 'atomic with regards to async signals' this entails? Your descriptions led me to think

In working on an LLVM backend for SBCL (a lisp compiler), there are certain sequences of code that must be atomic with regards to async signals. So, for example, on x86, a single SUB on a memory location should be used, not a load/sub/store sequence. LLVM's IR doesn't currently have any way to express this kind of constraint (...and really, that's essentially impossible since

Hi, > • Emit LLVM assembly from your compiler's native language. > for: very straightforward to get started > against: the .ll parser is slower than the bitcode reader when > interfacing to the middle end > against: you'll have to re-engineer the LLVM IR object model and asm > writer in your language > against: it may be harder to track changes to the IR One more

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what

Well, nothing has changed in the issues that I brought up earlier, except that I can confirm core dumps in non-threaded lisps as well (CLISP), using svn version 37840 (this morning, Seattle time) for R-2-3-patches. I've not tried Thomas' suggested fixes, as I'm hesistant to go down the road of fixing R in such a way that would require constant patching. (so for those counting,

Is there some neat way of storing the printed representation of an object as a character string? I can see how it could be done via disk using sink() and then scan(), but that's ugly. Something like Lisp-Stat's "with-output-to-string" macro perhaps? David Firth Phone +44 1865 278544 Nuffield College Fax +44 1865 278621 Oxford OX1

Hi Jonas, On 04/06/13 10:23, Jonas Wagner wrote: > Hi, > > I often use the gold plugin's also-emit-llvm option to verify the final LLVM > bitcode of a program. However, I realized that the gold plugin generates the > bitcode file before running LTO optimizations, such that the changes performed > by LTO are not reflected in the bitcode file. > > What is the reason for

I didn't make it clear that I load my Common Lisp application into "lldb" and then load a compiled bundle into my application using dlopen (I'm on OS X and I'm generating a kind of shared library called a "bundle"). Once everything is loaded, the functions from the bundle are accessible to my Common Lisp environment but I don't seem to be able to access the