similar to: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC

On 24.11.2012, at 17:53, Negar Mir <nmiralaei at gmail.com> wrote: > Thanks for your information. So, do you think it's better working with MCJIT instead of JIT specially for ARM platforms? I'm going to work on .bc files of some benchmarks for ARM platform. And, I decided to work with the JIT. Now, you proposed working with MCJIT. Could I get all the benefits of JIT in MCJIT as

Thanks for your information. So, do you think it's better working with MCJIT instead of JIT specially for ARM platforms? I'm going to work on .bc files of some benchmarks for ARM platform. And, I decided to work with the JIT. Now, you proposed working with MCJIT. Could I get all the benefits of JIT in MCJIT as well? Regards Negar On Sat, Nov 24, 2012 at 4:06 PM, Benjamin Kramer

On 11/24/2012 05:06 PM, Benjamin Kramer wrote: > I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts for those backends. Why is this holding back MCJIT development? If the old JIT with the x86 backend can coexist with MCJIT, why isn't this possible with the other backends? I have mixed

On 25.11.2012, at 00:34, Albert Graef <Dr.Graef at t-online.de> wrote: > On 11/24/2012 05:06 PM, Benjamin Kramer wrote: >> I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts for those backends. > > Why is this holding back MCJIT development? If the old JIT with the x86 >

On 11/25/2012 11:16 AM, Benjamin Kramer wrote: > It's possible to coexist, but increases the maintenance burden. Ok, I understand. > I can understand your concerns and I wouldn't have proposed this change if the old JIT for ARM and PPC actually worked. When running LLVM's regression tests on a ARM or PPC64 host most of the JIT tests simply fail. That's why the regression

Sorry for speaking too soon. It is missing from 3.2 which is the version I have been using. If it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To: Manny Ko Cc: Albert Graef; Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT

I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though. Another critical feature missing from MCJIT is the JITEventListener. This is usually for supporting debuggers and profiling tools. Ciao. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Albert

Thanks Andrew for the update. Does it support NotifyFunctionEmitted? Cheers. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:06 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC The current 3.2 code branch has events being broadcast from the MCJIT engine

The current 3.2 code branch has events being broadcast from the MCJIT engine when a new object is emitted, but the profiling listeners do not do anything with the events (and I don't expect they will before the 3.2 release becomes official). I have implemented some code in trunk since the 3.2 branch to traverse the emitted object and pick out named functions in the IntelJITEventsListener. An

No. It adds a new event, 'NotifyObjectEmitted'. The Intel JIT listener that I mentioned then uses the emitted object to find the functions (which are all emitted together). Because of the way that MCJIT is implemented, it isn't really feasible to reconstruct things like the EmittedFunctionDetails in the NotifyFunctionEmitted event. -Andy -----Original Message----- From: Manny Ko

I see. If I am writing my own listener can I still get back the (llvm::Function, void* Code, size_t Size)? Ciao. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:24 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC No. It adds a new event,

On Mon, Nov 26, 2012 at 9:18 AM, Manny Ko <Manny.Ko at imgtec.com> wrote: > I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though. > > Another critical feature missing from MCJIT is the JITEventListener. This is usually for supporting debuggers and profiling tools. What makes you say it is missing? Eli

On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: > Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced > by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on > the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. Hi Duncan, Thanks for the pointers. We hadn't stumbled across the

On 07/20/2012 10:35 AM, Will Schmidt wrote: > On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: >> Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced >> by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on >> the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. > Hi Duncan,

Ops. I meant to say 3.1. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manny Ko Sent: Monday, November 26, 2012 9:27 AM To: Eli Bendersky Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC Sorry for speaking too soon. It is missing from 3.2 which is the

On 07/31/2012 11:26 AM, Adhemerval Zanella wrote: > On 07/20/2012 10:35 AM, Will Schmidt wrote: >> On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: >>> Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced >>> by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on >>> the old JIT, so I suggest

On Sat, 28 Apr 2012 13:55:13 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > On Sat, 28 Apr 2012 13:46:02 -0500 > Hal Finkel <hfinkel at anl.gov> wrote: > > > On Sat, 28 Apr 2012 11:19:13 -0500 > > Peter Bergner <bergner at vnet.ibm.com> wrote: > > > > > On Fri, 2012-04-27 at 20:30 -0500, Hal Finkel wrote: > > > > Thanks! Do you

Hi, I am wondering why we dont support PPC32 LE? Here is the output of llvm-mc --version, in which only PPC32, PPC64 & PPC64LE are supported. $ llvm-mc --version LLVM (http://llvm.org/): LLVM version 3.6.2 Optimized build with assertions. Built Aug 2 2015 (11:39:46). Default target: x86_64-apple-darwin15.4.0 Host CPU: core-avx2 Registered Targets: aarch64 - AArch64

On Sat, 2012-04-28 at 15:51 -0500, Hal Finkel wrote: > > > - There is no support for generating position-independent code on > > > PPC32. (PIC on PPC64 now works well). Nevertheless, I have > > > sometimes run into linking errors when compiling shared libraries > > > with C++ on PPC64. PPC64 is PIC by nature. As for the linking issue, possibly you blew the

Writing some patches for MC I noticed that the old (non MC) JIT still has a lot of duplicated code for producing EH frames which makes it a bit harder to refactor code used by both implementations. Given that MCJIT is making good progress and that we just branched 3.2, can we delete the old JIT or at least its EH support? The attached patch removes just the EH bits. Cheers, Rafael --------------