similar to: [LLVMdev] llvm and flushing instruction cache

On Sat, Mar 6, 2010 at 10:34 PM, Shasank Chavan <shanko_chavano at hotmail.com> wrote: > Hi.  I have a very quick question.  Is the instruction cache flushed by the > llvm jit before code in memory is written to or executed?  I'm assuming so, > but I can't find where in the source code this is happening.  In particular > I searched for clflush, invd, and wbinvd

Hi Jim. Thanks for your speedy response. I'm not entirely sure if a JIT is what I'm looking for. I'm basically looking for a dll with an interface that takes a C program as input and compiles and optimizes it to native x86 instructions in an in-memory buffer. I don't want the dll the execute it, and I don't particularly want to translate our expressions into LLVM bitcode

Hi Reid. Thanks for your response. We will be running this code in different processes across different nodes. Basically we have thousands of "executor" processes that are solely responsible for executing this code generated at compile-time across partitioned data. Rather than each one of these processes invoking the jit and compiling with full opts and all of that, we believe it may

This can be done. Last year I took clang (v. 2.5) and hacked the compiler driver into a library which would JIT C source to memory. I then created a Zend extension which utilized the library. No external frameworks were used in these hacks, and were fairly simple to implement once one knew how to use the Clang/LLVM libraries. I cannot speak to your dll requirement, as the work was done for Linux.

On Tue, Feb 2, 2010 at 7:39 PM, Shasank Chavan <shanko_chavano at hotmail.com> wrote: > Hi Jim.  Thanks for your speedy response.  I'm not entirely sure if a JIT is > what I'm looking for.  I'm basically looking for a dll with an interface > that takes a C program as input and compiles and optimizes it to native x86 > instructions in an in-memory buffer.  I don't

If you distribute the .bc to a new machine and JIT it there, you wouldn't need to apply any relocations to call instructions, since the JIT will get all the offsets right when it does code generation on the node. I would strongly recommend the shared library approach over this one, because JIT compile time is dominated by code generation, not optimization. If you distribute the .bcs, then

If you really trying to avoid linking everything into a shared library (easiest choice), consider splitting up the compilation into a few more steps: 1) Compile and optimize once as part of your build, target LLVM bitcode instead of machine code 2) Ship .bc files out to each node 3) Fix-up call instructions in a BasicBlockPass, run JIT without any/many additional IR optimizations enabled This

Hi. I have more questions regarding llvm and using it as a jit for our purposes. Also, let me confess that I haven't actually used llvm yet (I'm still prototyping using gnu's libjit). Some of the issues that have come up from that work so far leads to me these questions: 1) We intend to use llvm as a jit in our expression compiler at compile-time only. At runtime, the x86 code

Hi. I'm very new to LLVM, and have read some of the documentation online. Before I invest too much time, however, in learning about LLVM, I'd like to know if it can be used for my purpose. We currently have a critical runtime component that evaluates expressions via interpretation. The bytecode that we generate goes through various optimization phases similarly to that of optimizing

On Tue, Mar 23, 2010 at 4:44 PM, Shasank Chavan <shanko_chavano at hotmail.com> wrote: > Hi.  I have more questions regarding llvm and using it as a jit for our > purposes.  Also, let me confess that I haven't actually used llvm yet (I'm > still prototyping using gnu's libjit).  Some of the issues that have come up > from that work so far leads to me these questions:

On Feb 2, 2010, at 3:05 PM, Shasank Chavan wrote: > Hi. I'm very new to LLVM, and have read some of the documentation online. Before I invest too much time, however, in learning about LLVM, I'd like to know if it can be used for my purpose. We currently have a critical runtime component that evaluates expressions via interpretation. The bytecode that we generate goes through

Hello, My name is Janek van Oirschot, currently student premaster embedded systems at the Technical University of Eindhoven and interested in participating in GSoC and contributing to LLVM. I have some experience with development for the GNU Assembler in which I looked into assembly-time relaxation. I have looked at the open projects page, found some interesting projects but still have some

Thanks Reid. What you wrote makes a lot of sense. The more I learn about the LLVM, the more I'll be able to determine how easy it would be to translate our IR into it. If it proves too difficult, I'll do what you suggested. Thanks again everyone for your responses... - Shasank > From: rnk at mit.edu > Date: Tue, 2 Feb 2010 22:11:50 -0500 > Subject: Re: [LLVMdev] Using

> On Feb 11, 2020, at 5:53 AM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?From: Tom Lendacky <thomas.lendacky at amd.com> > > Implement a handler for #VC exceptions caused by INVD instructions. Uh, what? Surely the #VC code can have a catch-all OOPS path for things like this. Linux should never ever do INVD.

From 159251a04afcdcd8ca08e9f2bdfae279b2aa5471 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Thu, 31 Oct 2013 06:38:15 +0800 Subject: [PATCH 4/4] XSA-60 security hole: flush cache when vmentry back to UC guest This patch flush cache when vmentry back to UC guest, to prevent cache polluted by hypervisor access guest memory during UC mode. The elegant way to do this

Master definition of VMI interface, including calls, constants, and interface version. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/paravirtualInterface.h =================================================================== --- linux-2.6.16-rc5.orig/include/asm-i386/mach-vmi/paravirtualInterface.h 2006-03-08 10:08:45.000000000 -0800 +++

Hi Daniel, To my knowledge, there is no other implementation available for Steensgaard AA except poolalloc. I have tried Steensgaard AA under LLVM 2.7 poolalloc, but there are lots of bugs which need to be fixed. It will be a good idea to use previous implementation, but you will have to modify (a lot) it with respect to the latest version of LLVM poolalloc. Thanks, -Yogesh -------------- next

Master definition of VMI interface, including calls, constants, and interface version. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/paravirtualInterface.h =================================================================== --- linux-2.6.16-rc5.orig/include/asm-i386/mach-vmi/paravirtualInterface.h 2006-03-08 10:08:45.000000000 -0800 +++

From e2d47e2f75bac6876b7c2eaecfe946966bf27516 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Tue, 26 Nov 2013 04:53:17 +0800 Subject: [PATCH] VMX: wbinvd when vmentry under UC This patch flush cache when vmentry back to UC guest, to prevent cache polluted by hypervisor access guest memory during UC mode. However, wbinvd is a _very_ time consuming operation, so 1.

Hi, I am new to citrix xen server. I have sucesfully installed citrix xen server 5.6.1 Fp1(free version) on my system. and through xencenter I have connected citrix xenserver and created vm (centos 5.5 32 bit), Installed Xen-tools in centos. My xenserver and xen vm ip details are below Xenserver Ip address - 192.168.1.5 Netmask - 255.255.255.0 Gateway - 192.168.1.1 which is my xencenter