similar to: [LLVMdev] Global register variables/custom calling conventions

Hello > I'm implementing an LLVM backend for qemu-arm (by creating an ARM frontend > for LLVM - from what I understand a slightly different approach than the > original llvm-qemu project) I don't see the difference so far. Could you please explain? > and I've got to the point where I have to deal with Qemu's use of global register variables. Why? The whole point of

Anton Korobeynikov wrote: > Hello > >> I'm implementing an LLVM backend for qemu-arm (by creating an ARM frontend >> for LLVM - from what I understand a slightly different approach than the >> original llvm-qemu project) > I don't see the difference so far. Could you please explain? Again, from what I understand, llvm-qemu worked by emitting LLVM IR from QEMU

Hello > Again, from what I understand, llvm-qemu worked by emitting LLVM IR from > QEMU IR API calls. This project goes straight from ARM to LLVM IR, bypassing > QEMU's IR, (partially) in the hope that more information about the original > intent of the code is retained. Ok, what's left from QEMU then? :) > generating reasonable code - this approach keeps it in place while

> At the moment I'm not explicitly specifying a calling convention for the > functions, but LLVM seems to consistently put the ARM CPU state struct > pointer (parameter) into %rdi. That's correct - please consider reading x86-64 ABI document. > As a hack-around (since posting the original > message to the list) I'm injecting a couple of MOV instructions to move the >

Hi Andrew, On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery <andrew at aj.id.au> wrote: > TCG seperates the guest (ARM) code into blocks - my front end translates > these to LLVM IR for LLVM to translate to x86.  The assumption is that LLVM > will produce a better translation than TCG*. At some future point the > TCG-generated native block is replaced by the LLVM's, and as

On 25/09/09 18:05, Tilmann Scheller wrote: > Hi Andrew, > > On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery<andrew at aj.id.au> wrote: >> TCG seperates the guest (ARM) code into blocks - my front end translates >> these to LLVM IR for LLVM to translate to x86. The assumption is that LLVM >> will produce a better translation than TCG*. At some future point the

Anton Korobeynikov wrote: > Ok, what's left from QEMU then? :) The hardware emulation (interrupts, condition flags, register file etc) and execution framework (block selection and execution) from qemu are still used - translating the ARM to the native architecture is only part of the story :) > >> generating reasonable code - this approach keeps it in place while we do

Ralph Corderoy wrote: > Hi Tilmann, > > >> Nevertheless, it is unlikely that llvm-qemu will ever be much faster >> than regular qemu (by replacing its code generator completely, which >> it currently does), which is due to the fact that regular qemu has a >> very lightweight code generator (it basically only copies blocks of >> memory and performs some

Hi Tilmann, > Nevertheless, it is unlikely that llvm-qemu will ever be much faster > than regular qemu (by replacing its code generator completely, which > it currently does), which is due to the fact that regular qemu has a > very lightweight code generator (it basically only copies blocks of > memory and performs some patching to them and only does static > register

I downloaded the "QEMU 0.8.2 CVS20070120 + patches snapshot January 20th 2007" and it was compiled ok for "ppc-softmmu" but failed in the "sparc-softmmu" with the message: ../dyngen -o op.h op.o dyngen: ret; restore; not found at end of op_ldstub_kernel can someone tell me what to do or where can I find a QEMU software running on solaris/sparc to lunch linux

> > > Are there particular reasons why you want to translate to LLVM IR? > (E.g. the authors of the paper wanted to be able to use KLEE with > machine code) > > Hi Tilmann I want to do the same. Using KLEE with machine code. With such a framework, I could try to do the same that what is explained here :

On 12 February 2010 14:01, Charles Davis <cdavis at mymail.mines.edu> wrote: > Something I'm doing right now may be of interest to you. > > Just today I added support for a new 'alignstack' function attribute. > With it, you can force the stack to be 16-byte aligned (or n-byte > aligned, if you so desire) in your functions. This way, you can make > calls to

Charles Davis wrote: > Just today I added support for a new 'alignstack' function attribute. > With it, you can force the stack to be 16-byte aligned (or n-byte > aligned, if you so desire) in your functions. This way, you can make > calls to dylibs on Mac OS X without triggering the misaligned stack error. I finally got around to properly playing around with

On Wed, 20 Feb 2008, Raja Mukherji wrote: > Hi all, > I was wondering what the best way of adding a custom calling convention in llvm? It is quite easy to add custom calling conventions. Check out how the various x86 fastcall, stdcall, etc things are handled. > In particular, for the x86 platform, I want: > > on entry > > esi = size of argument block > edi = address of

Hi all, I was wondering what the best way of adding a custom calling convention in llvm? In particular, for the x86 platform, I want: on entry esi = size of argument block edi = address of argument block ecx = callee object and on return eax = status code ebx = possible one-shot continuation ecx = returned value edx = returned reference I only want it to work in a JIT fashion so no

On 20/02/2008, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Feb 2008, Raja Mukherji wrote: > > Hi all, > > I was wondering what the best way of adding a custom calling convention in llvm? > > It is quite easy to add custom calling conventions. Check out how the > various x86 fastcall, stdcall, etc things are handled. Am I correct in thinking that it's

David Terei wrote: > Hi all, > > I'm working on using LLVM as a back-end for the Haskell GHC compiler. As > part of that work I have modified LLVM to include a new custom calling > convention for performance reasons as outlined previously in a > conversation on this mailing list: > > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > This

Dears, My railsapp run using ''/layout/application.rhtml'' and under some conditions ( Authenticated user, url parameter) I like to switch globally to another layout, let''s say custom.rhtml Like : class AppController < ApplicationController before_filter :context_layout def index end end # application.rb def context_layout if <context_condition>

I was wondering if global variables can be candidates for register allocation. My use case is a global variable that is used in every function in my program. I'm wondering if it's better to pass it in, or let it stay as a global. Passing it in will require a bit of work.

Hi all, I'm working on using LLVM as a back-end for the Haskell GHC compiler. As part of that work I have modified LLVM to include a new custom calling convention for performance reasons as outlined previously in a conversation on this mailing list: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt This custom calling convention on x86-32 needs to handle just 4 parameters,