similar to: [LLVMdev] Publication - ErLLVM: An LLVM backend for Erlang

ping. :-) On 09/07/2012 08:24 PM, Yiannis Tsiouris wrote: > [...] > The citation is the following (this time with a url to the paper): K. > Sagonas, C. Stavrakakis, and Y. Tsiouris. "ErLLVM: An LLVM backend > for Erlang"[1]. In Eleventh ACM SIGPLAN Erlang Workshop, September > 2012. ACM Press. > > [1]: http://erllvm.softlab.ntua.gr/files/erlang03-sagonas.pdf >

On 9/10/12 5:29 PM, Yiannis Tsiouris wrote: > ping. :-) I've been on vacation since August 28 and disabled llvmdev delivery so that I wouldn't get flooded with emails while I was gone, so I didn't see your message. I've added the entry to the publications page, but I haven't made a separate page for the abstract. Is that alright, or would you like an abstract page

Hi, I attach a publication that we have at the ACM Sigplan Erlang Workshop 2012, Copenhagen, Denmark. The abstract is: This paper describes ErLLVM, a new backend for the HiPE compiler, the native code compiler of Erlang/OTP, that targets the LLVM compiler infrastructure. Besides presenting the overall architecture of ErLLVM and its integration in Erlang/OTP, we describe the changes to LLVM that

Hi Kostis, Just to check, did you send the patch originally to llvmdev or llvm-commits? The latter is where all commit review takes place. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kostis Sagonas Sent: 02 May 2012 13:16 To: llvmdev at cs.uiuc.edu Cc: erllvm at softlab.ntua.gr Subject: Re: [LLVMdev] RFC:

On 04/24/12 17:10, Yiannis Tsiouris wrote: > This patch (and the others that will follow) are rebased on svn r155440: > > "AVX2: The BLENDPW instruction selects between vectors of v16i16 using an i8 > immediate. We can't use it here because the shuffle code does not check that > the lower part of the word is identical to the upper part" > > Patch 1/3: >

This patch (and the others that will follow) are rebased on svn r155440: "AVX2: The BLENDPW instruction selects between vectors of v16i16 using an i8 immediate. We can't use it here because the shuffle code does not check that the lower part of the word is identical to the upper part" Patch 1/3: The attached commits add a new calling convention to support the LLVM backend for

Hi, We 've been working on an LLVM backend for High Performance Erlang (HiPE) [1], the native code compiler of Erlang/OTP [2]. ErLLVM [3] targets the X86 and AMD64 architectures for now but there is some ongoing work from a team on the Uppsala University to also support ARM. In our implementation, we have paid special attention on retaining ABI-compatibility with the Erlang Runtime System in

Hi, Following Chris' advice, I will rebase the patches and break them in 3 distinct emails (one at a time) in order to be easier for a reviewer to approve/comments. Please note that the three patches while being code-wise independent, they 're strongly-connected *semantically*, meaning that including just a subset of these patches to LLVM's code base is quite weak if the others are

On 4/6/12 2:21 AM, Talin wrote: > I would really like to see someone work on LLVM's garbage collection > support - it hasn't been updated in 4 years, and while there's been a > lot of talk about ways that it could be improved, there's been no action. That is *sooo* true! :-) I'm one of the authors of an LLVM backend for Erlang (ErLLVM [1]); we have tested and

Hi, I'm currently working for the next 6 months, but I would be very interested in looking into this. Are there any discussions in this mailing list that would be useful in finding out more information? Regards Michael Thorpe Internet Services Developer Netcraft Ltd -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Yiannis

Sorting through all of the discussions would be difficult, as the ideas have morphed over the years. Also, some of the discussion took place offline at various LLVM dev conferences. I can summarize the main points here: The biggest improvement in GC would be to allow SSA values to be declared as GC roots - currently only alloca values, that is, values in memory, can be GC roots. This means that

I would really like to see someone work on LLVM's garbage collection support - it hasn't been updated in 4 years, and while there's been a lot of talk about ways that it could be improved, there's been no action. On Sun, Apr 1, 2012 at 8:41 PM, Patrick Edwards <pedwar11 at kent.edu> wrote: > Hi, my name is Patrick Edwards, and I'm currently a CS major at Kent State

I realize that this was written in a hurry, and may not have been entirely clear. If there are any questions, critiques, etc., I'd be happy to respond to them. I'd really like it if LLVM's garbage collection support didn't continue to languish... On Fri, Apr 6, 2012 at 12:43 PM, Talin <viridia at gmail.com> wrote: > Sorting through all of the discussions would be

Just a thought, but it would it make sense for garbage collection to be some sort of minimal debug information for potentially optimized code. Store just enough debug information to reconstruct call stacks and know where gc-roots are. Perhaps an approach like this could minimize the work required as it is shared between gc-support and debug information support. >From what I understand, DWARF

Actually, I'm pretty happy with the way that LLVM handles this aspect of garbage collection now. LLVM does not itself generate any data related to garbage collection - all it does is supply a plugin interface that lets your code know where on the stack the roots are. Your code is responsible for generating any static data structures that would be read by your garbage collector. So if you

Yiannis, Pedro, I'm not an expert here. Taking closer look I see that it makes sense to do this cleanup job in doFinalization() of the pass, which requested GC info. So the current fix seems to be ok and all external clients will need to do cleanup directly doing the same jobs as Printer::doFinalization() does now. By the way, I've just noticed that comments for GCModuleInfo::clear()

Pedro, Yiannis, What's about the usage case, when LLVM is used as a library and the user implements its custom pass, which dump the code (implemented as a FunctionPass, but not as Printer)? You also missed in your changes the declaration of llvm::createGCInfoDeleter() in include/llvm/CodeGen/Passes.h -Dmitry. On Mon, Feb 18, 2013 at 9:34 PM, Pedro Artigas <partigas at apple.com>

Hello! Is there a way to force explicit register usage (e.g. %r15 in amd64 architecture) in LLVM assembly code? I was proposed in #llvm channel at irc.oftc.net to use inline assembly but i find it rather impractical in my case. Is there any other way? Thanx, ~y.

Hi , Can someone commit the attatched (cleanup) patch for r175528? Thanks, yiannis On 02/25/2013 08:11 PM, Dmitry Babokin wrote: > Yiannis, Pedro, > > I'm not an expert here. Taking closer look I see that it makes sense > to do this cleanup job in doFinalization() of the pass, which > requested GC info. So the current fix seems to be ok and all external > clients will

Hi, my name is Patrick Edwards, and I'm currently a CS major at Kent State University. I have always been interested in doing work with compilers and LLVM seems to be a perfect fit for me to learn more over the summer, and also contribute to open-source projects at the same time. However, while browsing through the project ideas, the only ideas I found accessible were the code reduction and