search for: yyc1992

It's out of date. We're using MCJIT on ARM to implement an OpenCL on CPU implementation. It works! On Tue, Nov 25, 2014 at 3:46 PM, Yichao Yu <yyc1992 at gmail.com> wrote: > On Tue, Nov 25, 2014 at 4:22 PM, Yichao Yu <yyc1992 at gmail.com> wrote: >> Hi, >> >> I am sorry if this question have been brought up too many times but >> the document does seems a little bit confusing on this. >> >> According...

On 26 November 2014 at 00:14, Yichao Yu <yyc1992 at gmail.com> wrote: >> We're using MCJIT on ARM to implement an OpenCL on CPU implementation. It works! > > Thanks. Great to hear that!!! > > Maybe could someone please update that page.... It's really confusing. Hi Yichao, So, MCJIT works well for x86 and PPC, and i...

Hi, I am sorry if this question have been brought up too many times but the document does seems a little bit confusing on this. According to the official feature page[1] ARM is not a supported target (for JIT at least...). However, according to this email[2] on the list and this related bug report[3] from earlier this year, it seems that the JIT engine is working well on ARM. Is the feature

On Oct 31, 2017, at 3:50 PM, Anna Thomas via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Oct 31, 2017, at 12:17 PM, Yichao Yu <yyc1992 at gmail.com<mailto:yyc1992 at gmail.com>> wrote: We at Azul have been using invariant.start for marking objects as immutable after a certain point. Also, upstream changes to teach relevant optimizations about invariant.start and end were added last year. With respect to store to load fo...

> We at Azul have been using invariant.start for marking objects as immutable after a certain point. > Also, upstream changes to teach relevant optimizations about invariant.start and end were added > last year. > > With respect to store to load forwarding, this is handled in GVN. I think the test cases in test/Transforms/GVN/invariant.start.ll > handle what you’re looking for.

...NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging support MCJIT has is provided by the RuntimeDyld utility, > > which ORC shares. I would expect anything in that document to apply to > ORC > > as well, though I haven't tested it personally. > > I'm pretty sure that'...

> Just to clarify: If g can modify %a in some way, the front end needs to > identify it and avoid adding > invariant.start. OK cool, that's what I thought too. > > Once the invariant.start has been added by the front end,this is a perfectly > legal transform to do > based on the LLVM spec. > > In fact we should be implementing this in LLVM, patches welcome :)

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it personally.