search for: yichao

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. >> &gt...

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

..., it seems that the JIT engine is working well on ARM. Is the feature page just out-of-date? If yes, which version has ARM jit support? I am developing a system running on Linux on Zynq from Xilinx and it would be really nice if I can use LLVM to improve our performance and flexibility. Cheers, Yichao Yu [1] http://llvm.org/Features.html [2] http://comments.gmane.org/gmane.comp.compilers.llvm.devel/74937 [3] http://llvm.org/bugs/show_bug.cgi?id=20329

Hi, I just got my git account joining into LLVM. When I tried a test push, I got git push origin HEAD:master --dry-run Username for 'https://github.com': stephan-yichao-zhao Password for 'https://stephan-yichao-zhao at github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/llvm/llvm-project.git/' The page says "Your first commit to a repository may require the autogenerated email to be approved...

...The issue linked is marked as resolved-later and mentioned that it "probably have to be redesigned before they work out right". What has to be redesigned to make it work and is there a better way that works currently to mark an object as immutable after a certain point/in certain region? Yichao Yu [1] https://bugs.llvm.org/show_bug.cgi?id=5441

...well without LLVM knowning anything about such a function. Of course the store to load forwarding still need to be handled separately but it seems that this can avoid some of the special cases on this intrinsics. > > > Hope this helps, > Anna > >> On Oct 29, 2017, at 9:01 PM, Yichao Yu via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> From LangRef, these intrinsics seems really useful for letting LLVM >> know about certain higher level immutability guarantee, e.g. for >> objects that are not allowed to be mutated after c...

...tion. The particular case I'm interested in is vectorized loop with reduction like in pseudo C code `s += a[i] * b[i]`. Our front end will recognize this and mark the `+` as `fast` to enable vectorization. It'll be great if this can enable the reduction to be done with `fma` instructions. Yichao Yu

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

HI Yichao, RTDyldObjectLinkingLayer has a 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,...

> We do not implement that restricted semantics correctly either -- see > https://bugs.llvm.org/show_bug.cgi?id=27190 Haha, I wondered for a minute whether I should bring up that bug... We've seen pretty nasty crashes due to it and had to work around it..... One of my recent work has also uncovered another (I believe) invalid handling of returns_twice functions....

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.

This release fixes a regression introduced by the security patches in 1.6.10. See https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/116 for details. Alan Coopersmith (1): libX11 1.6.11 Yichao Yu (1): Fix size calculation in `_XimAttributeToValue`. git tag: libX11-1.6.11 https://xorg.freedesktop.org/archive/individual/lib/libX11-1.6.11.tar.bz2 SHA256: b1cc4b802058be7e3fb438ee2490f66fcc52ac3b2a14f47a22cbf77638e33606 libX11-1.6.11.tar.bz2 SHA512: 2cb4e215c1e3ccb327e02586844f8c4260...

> 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 :)

On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: > > Hello, > > I am not sure about the semantic (if any) of returns_twice and noreturn > attributes. > > int fork() __attribute__((returns_twice)); > void join(int) __attribute__((noreturn)); > > int f(int n) { > int

Hi, I wanted to get the linked result in LLVM bitcode format. With LTO, this can be done by -flto -Wl,-plugin-opt,emit-llvm. Instead of generating native executables, it outputs a file with bitcode format. Does this still work with -flto=thin? -flto=thin -Wl,-plugin-opt,emit-llvm outputs a bitcode file, but its file size is too small, and does not contain all contents. What is the correct way

On 11/03/2017 07:57 PM, Yichao Yu wrote: > On Fri, Nov 3, 2017 at 8:54 PM, Alexandre Isoard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: >>> &g...