similar to: [LLVMdev] ARM JIT status.

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

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 it works to a degree on ARM. Tom's team has

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

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, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging

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

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

i was just writing this: http://www.gp32x.com/board/index.php?/topic/60228-replicating-the-success-of-the-openpandora-discussion-v20/ when something that just occurred to me, half way through, and i would greatly appreciate some help evaluating whether it's feasible. put these together: http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm

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 construction. However, it doesn't seem to work[1] and a quick code search suggests that there's not a single optimization pass that's currently using it for store to load forwarding, only very few

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

Hi, On LLVM 5.0 (current trunk), fadd/fsub and fmul that are both marked with `contract` or `fast` can be merged to a fma instruction by the backend. I'm wondering about the exact semantic of this new flag as well as `fast` and in particular, would it be valid to do this when only the `fadd`/`fsub` (and not the `fmul`) is marked with `contract` or at least `fast`. The reasoning is that doing

On Sun, Aug 21, 2011 at 12:48 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > The way in which Gallium3D targets LLVM, is that it waits until it receives > the shader program from the application, then compiles that down to LLVM IR. > That's too late to start synthesizing hardware (unless you're planning to > ship an FPGA as the graphics card, in which case reprogramming

Luke Kenneth Casson Leighton wrote: > i was just writing this: > http://www.gp32x.com/board/index.php?/topic/60228-replicating-the-success-of-the-openpandora-discussion-v20/ > > when something that just occurred to me, half way through, and i would > greatly appreciate some help evaluating whether it's feasible. > > put these together: >

On Tue, Oct 27, 2015 at 10:15 PM, Bruno Cornec via Syslinux <syslinux at zytor.com> wrote: > Bruno Cornec via Syslinux said on Wed, Oct 28, 2015 at 01:45:22AM +0100: >> >> Is there a way to increase the debug level of syslinux.efi in order to >> check what it tries to do and diagnose more precisely what happens ? > > > Ok, I tried to modify mk/devel.mk to put:

Luke Kenneth Casson Leighton wrote: > On Sun, Aug 21, 2011 at 12:48 AM, Nick Lewycky<nicholas at mxc.ca> wrote: > >> The way in which Gallium3D targets LLVM, is that it waits until it receives >> the shader program from the application, then compiles that down to LLVM IR. >> That's too late to start synthesizing hardware (unless you're planning to >>

On Wed, Oct 07, 2015 at 05:58:51PM -0500, Clements, James wrote: > James Clement > > Geert Stappers > > > On Wed, Oct 07, 2015 at 05:06:41PM -0500, Clements, James wrote: > > > > The screen displays the following: > > > > > > > > PXE Network Boot using IPv4 > > > > .... > > > > Station IP address is 192.168.205.50

Hi! It's indeed better to open a new thread for this. So, here's my test session: $ qemu -fda extlinux.144 -s -S Then in another terminal: $ gdb extlinux.elf (gdb) set architecture i8086 (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x0000fff0 in ?? () at localboot.inc:68 68 jmp kaboom ; If we returned, oh boy... How does "jmp kaboom" get

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

So far I tested PXELINUX from 4.10-pre12, 4.10-pre9 and 4.10-pre6. The first two take a long time with a TFTP file not found and eventually find my file but error out (presumably to kaboom). The last takes a long time, does a lot of retransmitted packets (didn't watch the first two), then eventually loads the file but continues this behavior for TFTP and HTTP transfers. This is on VMware

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around