search for: hipe

...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 HiPE compiler, as described in a previous email. The corresponding commit messages are: 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...

...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 HiPE compiler, as described in a previous email. The corresponding commit > messages are: We understand that the LLVM developers may be busy, but any chance that we will get some reaction on this patch soon? A five minute look at the changes in this patch will most probably reveal that the change...

...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 an i8 > immediate. We can't use it here because the shuffle cod...

Hi all I saw presentation http://www.softlab.ntua.gr/~gtsiour/files/erllvm_pres-20111107.pdf and I have couple question to the HiPE calling convention. I am trying to enable HiPE call for Rust compiler. That presentation mentioned that: Virtual registers with “special” use, pinned to hardware registers (unallocatable). VM Register AMD64 Register Native stack pointer %nsp Heap pointer %r15 Process point...

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 Erlan...

...ches 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 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-compatib...

> On Sep 29, 2017, at 4:12 AM, denisgolovan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all > > I saw presentation http://www.softlab.ntua.gr/~gtsiour/files/erllvm_pres-20111107.pdf > and I have couple question to the HiPE calling convention. I am trying to enable HiPE call for Rust compiler. > > That presentation mentioned that: > Virtual registers with “special” use, pinned to hardware registers > (unallocatable). > VM Register AMD64 Register > Native stack pointer %nsp > Heap poi...

.../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 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 and dec...

...onas.pdf > > On 09/07/2012 08:13 PM, Yiannis Tsiouris wrote: >> 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 ch...

...on over local function related optimization in IPRA. I have added following method to achieve this: > > bool isEligibleForTailCallOptimization(Function *F) { > CallingConv::ID CC = F->getCallingConv(); > if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) > return true; > return false; > } > > Any other suggestions are always welcomed. Why aren’t checking for the presence of a tail call? — Mehdi > > and I am checking this condition along with hasLocalLinkage() and hasAddressTaken(). > > Due to this test-suite...

...ptimization in IPRA. I have added following method to achieve this: >>> >>> bool isEligibleForTailCallOptimization(Function *F) { >>> CallingConv::ID CC = F->getCallingConv(); >>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>> return true; >>> return false; >>> } >>> >>> Any other suggestions are always welcomed. >> >> Why aren’t checking for the presence of a tail call? > Are you asking about if tail call optimization is enable or not? If not then...

According to this http://llvm.org/docs/CodeGenerator.html#tail-call-section, it seems that adding a new CC for the purpose of local function optimization seems a good idea because tail call optimization only takes place when both caller and callee have fastcc or GHC or HiPE calling convention. -Vivek On Sun, Jun 26, 2016 at 1:26 AM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > On Sat, Jun 25, 2016 at 11:03 PM, vivek pandya <vivekvpandya at gmail.com> > wrote: > >> Hello LLVM Community, >> >> To improve Interproc...

...tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: bool isEligibleForTailCallOptimization(Function *F) { CallingConv::ID CC = F->getCallingConv(); if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) return true; return false; } Any other suggestions are always welcomed. and I am checking this condition along with hasLocalLinkage() and hasAddressTaken(). Due to this test-suite now has only 2 runtime failure where as before this there were around 43 due to local function related optimi...

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 and decisions we took. Fina...

...outcomes of interest to me are all binary variables. The one in the example here, Dead30d, is death within 30 days of admission. Sexf is gender (M or F), Age is age in years at the start of the admission. The standard glm is a logistic regression :- glmDead.AS <- glm(Dead30d~Sexf+Age, data=HIPE,family=binomial(link="logit")) The corresponding GAM, with a smooth for age, is :- gamDead.AS <- gam(Dead30d~Sexf+s(Age), data=HIPE,family=binomial(link="logit")) For my work, age is a nuisance. We already know exactly the effect of age (which has an odd shape). I have n...

...:13 PM, Yiannis Tsiouris wrote: > >> 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 > &...

...d following method to achieve this: >>>>> >>>>> bool isEligibleForTailCallOptimization(Function *F) { >>>>> CallingConv::ID CC = F->getCallingConv(); >>>>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>>>> return true; >>>>> return false; >>>>> } >>>>> >>>>> Any other suggestions are always welcomed. >>>> >>>> Why aren’t checking for the presence of a tail call? >>> Are you askin...

...ocal function related optimization in IPRA. I have added > following method to achieve this: > > bool isEligibleForTailCallOptimization(Function *F) { > CallingConv::ID CC = F->getCallingConv(); > if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == > CallingConv::HiPE) > return true; > return false; > } > > Any other suggestions are always welcomed. > > > Why aren’t checking for the presence of a tail call? > Are you asking about if tail call optimization is enable or not? If not then above method is inspired from X86ISelLowerin...

...od to achieve this: >>>>>> >>>>>> bool isEligibleForTailCallOptimization(Function *F) { >>>>>> CallingConv::ID CC = F->getCallingConv(); >>>>>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>>>>> return true; >>>>>> return false; >>>>>> } >>>>>> >>>>>> Any other suggestions are always welcomed. >>>>> >>>>> Why aren’t checking for the presence of a tail call...

...ptimization in IPRA. I have added following method to achieve this: >>> >>> bool isEligibleForTailCallOptimization(Function *F) { >>> CallingConv::ID CC = F->getCallingConv(); >>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>> return true; >>> return false; >>> } >>> >>> Any other suggestions are always welcomed. >> >> Why aren’t checking for the presence of a tail call? >> Are you asking about if tail call optimization is enable or not? If not...