similar to: [LLVMdev] ARM JIT support status?

The only reference that I found so far here: http://llvm.org/devmtg/2011-09-16/EuroLLVM2011-LLVMplusARM.pdf The presenter states that the ARM JIT support is broken. But this is about 10 months old. Is the ARM JIT support still broken? Am I not looking at the right places in the documentation? Help will be appreciated. thanks, Rahul On Mon, Jul 30, 2012 at 4:53 AM, Rahul Garg <rahulgarg44 at

Hi Rahul, I believe that ARM support is working in the MCJIT engine (as of llvm 3.1). If it wasn't working in the legacy JIT engine 10 months ago then it probably still isn't. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rahul Garg Sent: Tuesday, July 31, 2012 1:13 PM To: llvmdev at cs.uiuc.edu Subject: Re:

Thanks. I am not trying to modify convert generic LLVM IR and know the requirements (such as specifying address spaces etc.). I guess I just need to ensure that I am sticking to LLVM 3.2 and the SPIR specified subset+ metadata annotations etc. Anyway, I was confused partly because there are references to a SPIR backend in LLVM code (eg: include/llvm/ADT/Triple.h lists spir and spir64 as possible

Hi. I am looking into generating SPIR from within a JIT compiler for a high level language using LLVM C++ API. The first step is to of course build LLVM with SPIR backend support and I am currently using LLVM 3.3. For reference, the host system is a x86-64 Linux. I first tried building LLVM 3.3 without specifying any targets, and it built many targets including aarch64, arm, x86, x86_64, nvptx

For those of you who want to get their exception handling code (NON SJLJ), working with the new 3.0 exception infrastructure, the core developers have created a handy function in AutoUpgrade (#include "llvm/AutoUpgrade.h") called: UpgradeExceptionHandling(...). This function will convert all the functions in a module using the pre 3.0 exception intrinsics into use of the new 3.0

Is there a native linker in the roadmap so that there isn't a dependency on binutils? Is it considered out of scope? It seems to me that I saw mention of someone starting such a project a while ago. Did it ever get anywhere? Was there a particular reason why it wasn't folded into llvm as an official project? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi all, Is it too soon to start porting EH code to the new C++ API? Are there sample implementations? llvm.org/demo still uses the old EH gizmos. should we wait for 3.0 release? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/3bc09ea9/attachment.html>

Hi, With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting. For the motivations, see Jakob’s proposal (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html>) and for the proposal, see the slides (Keynote:

Here is my formal proposal i have submitted in gsoc. Comments invited. About me: I am a final semester Dual Degree( B.Tech. M.Tech.) student from Indian Institute of Technology, Kanpur. I was looking forward to participate in this year's GSoC 2009.Starting Fall 2009 i shall be pursuing a Phd in compilers. I am having a good background in compilers. My current masters thesis is aimed at

Hi Daniel, I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out. Indeed, my take away is: "It is always a no-op cast because no bits change with this conversion." In other words, deleting all bitcast instructions should be fine. My understanding of the quote you’ve highlighted is that it tells C programmers that this

Registration for the 2011 LLVM Developer Meeting is now open: qcsurvey.qualcomm.com/survey.asp?pub=y&survey_id=7125 The attendance limit has been increased to 225 this year, but with the growing interest in LLVM, registration will likely still fill up quickly; we encourage you to register early. The 2011 meeting will be held on Friday, November 18, 2011 at San Jose Marriott 301 South

Hi Hans, There was a presentation at last year's DevMeeting.  See http://www.llvm.org/devmtg/2010-11/ and look for the presentation on Object Files by Michael Spencer.  As for the news, we haven't heard much here either. --Sam >________________________________ >From: Hans Stimer <hans.stimer at gmail.com> >To: LLVMdev at cs.uiuc.edu >Sent: Saturday, September 24, 2011

Hi, > I found this thinking quite difficult to explain. Does it make sense? It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts Cheers, James On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I haven't found much time to

On Apr 3, 2009, at 12:52 AM, Kshitiz Garg wrote: > Here is my formal proposal i have submitted in gsoc. Comments invited. > This sounds like a very interesting proposal. Many compilers clone loops and use dynamic checks to enforce invariants in one copy of the loop. Is this intended to be similar to that style of approach? -Chris > > About me: > > I am a final

Hi Daniel, Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned. I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required. Is there anyone that could chime in on that? However, it seems SelectionDAG sticks to the load/store semantic: "BITCAST - This operator converts between integer,

What happens when you cascade bitcast? Are these sequences all equivalent at the IR level (i.e. do they reference the same byte from the original i128)? i128 => <16 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <8 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <2 x i32> => GEP 0 => <4 x i8> => GEP 0 —

All, Attached below are the patches that make up the Apple ARM64 compiler backend (in addition to compiler_rt, libc++ and lldb support), and we'd like to start the process of integrating them into mainline LLVM. We and ARM have discussed a general approach to integrating them into mainline and look forward to working through this with the community at large. First a bit of context to help

HI All, Can any anyone please help me with attached screenshot. Actually i am not able to lauch puppet dashboard and when i have tried to running below command ,getting error. puppet resource service puppet ensure=running enable=true -- Thanks and Regards, Mamta Garg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe

Hi All, The 2020 Virtual LLVM Developer's Meeting is coming up the week after next. I'll be hosting a JIT Birds-of-a-Feather session on Thursday the 8th at 10:55am PDT (See http://llvm.org/devmtg/2020-09/schedule/). I'm planning to run this more like a Round Table: Minimal introduction, plenty of time for discussion. Does anyone have any LLVM JIT related topics that they would

Hi All, I'm back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review! As described in my last email, this commit breaks the OrcJIT library