search for: erllvm

Sorry for double-posting to the list, 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. Thanks! Yiannis [1]: http://erllvm.softlab.ntua.gr/files/erlang03-sagonas.pdf On 09/07/2012 08:13 PM, Yiannis Tsiouris wrote: > Hi, > > I attach a publication that we have at the A...

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 09/07/2012 08:13 PM, Yiannis Tsiouris wrote: >> Hi, >> >> I attach a publication...

...ou like an abstract page like some of the older publications in the list? -- John T. > > 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 09/07/2012 08:13 PM, Yiannis Tsiouris wrote: > >> Hi, >...

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 ErLLVM required and discuss technical challenges...

...ts. 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 not included also. Best regards, Yiannis Tsiouris (as part of the ErLLVM team) On Sat, Apr 14, 2012 at 11:49:41PM +0300, Yiannis Tsiouris wrote: > 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 i...

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 order to support loading both HiPE- a...

...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: ErLLVM - Implemented HiPE Calling Convention 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...

...tches 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 not included also. > > > Best regards, > Yiannis Tsiouris (as part of the ErLLVM team) > > On Sat, Apr 14, 2012 at 11:49:41PM +0300, Yiannis Tsiouris wrote: > > 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 > >...

...patch soon? A five minute look at the changes in this patch will most probably reveal that the changes are non-intrusive and non-controversial and will allow us to proceed further in discussing the next two parts of the patch we would like to submit. Thanks in advance, Kostis Sagonas (for the ErLLVM team) > 0001: > | Implemented a new calling convention (cc 11) for HiPE similar to GHC's cc 10. > | In detail: > | * Inserted new symbol "cc 11" (CallingConv::HiPE). > | * Created cc and retcc for both 32 and 64 bit. > | * HiPE cc defines no calleE-save registers...

...e 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 measured our backend and noticed that with the current GC infrastructure we see 20-40% performance degradation (because of the loads/stores on the stack for all gcroots). It is clear to me and the rest of the team that with this infrastructure the LLVM might not be sui...

...ee 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 measured our backend and noticed that with the current GC infrastructure we see 20-40% performance degradation (because of the loads/stores on the stack for all gcroots). It is clear to me and the rest of the team that with this infrastructure the LLVM might not be suitabl...

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

...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 measured our backend and noticed > that with the current GC infrastructure we see 20-40% performance > degradation (because of the loads/stores on the stack for all gcroots). It > is clear to me and the rest of the team that with this infrastructure the > LLVM...

...ction >> > 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 measured our backend and noticed >> that with the current GC infrastructure we see 20-40% performance >> degradation (because of the loads/stores on the stack for all gcroots). It >> is clear to me and the rest of the team that with this infrastructure th...

...gt; 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 measured our backend and noticed >>> that with the current GC infrastructure we see 20-40% performance >>> degradation (because of the loads/stores on the stack for all gcroots). It >>> is clear to me and the rest of the team that with this infra...

...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 measured our backend and noticed >>>> that with the current GC infrastructure we see 20-40% performance >>>> degradation (because of the loads/stores on the stack for all gcroots). It >>>> is clear to me and the rest of the team that wit...

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