similar to: [LLVMdev] [PATCH] fix for FreeBSD/powerpc build breakage

Chris Lattner wrote: > On Mon, 16 Jun 2008, Gary Benson wrote: > > When you genetate code on PowerPC you need to explicitly > > invalidate the instruction cache to force the processor to reread > > it. In LLVM there is code to do this for function stubs on > > Macintosh, but not for other platforms and not for JITted code > > generally. > > Applied, thanks!

Hi, > ----- Original Message ----- >>> ----- Original Message ----- >>>> Hi all, >>>> My recent commit r187027 fixed a simple oversight of forgetting >>>> to >>>> check for __ppc__ (only checking __powerpc__), which broke my >>>> powerpc-apple-darwin8 stage1 tests, since the system gcc only >>>> provided

----- Original Message ----- > > ----- Original Message ----- > >> Hi all, > >> My recent commit r187027 fixed a simple oversight of forgetting > >> to > >> check for __ppc__ (only checking __powerpc__), which broke my > >> powerpc-apple-darwin8 stage1 tests, since the system gcc only > >> provided > >> __ppc__. I was

> ----- Original Message ----- >> Hi all, >> My recent commit r187027 fixed a simple oversight of forgetting to >> check for __ppc__ (only checking __powerpc__), which broke my >> powerpc-apple-darwin8 stage1 tests, since the system gcc only >> provided >> __ppc__. I was wondering if this justifies using simpler macros like >> >> #define

----- Original Message ----- > Hi all, > My recent commit r187027 fixed a simple oversight of forgetting to > check for __ppc__ (only checking __powerpc__), which broke my > powerpc-apple-darwin8 stage1 tests, since the system gcc only > provided > __ppc__. I was wondering if this justifies using simpler macros like > > #define LLVM_PPC (defined(__ppc__) ||

Hi all, My recent commit r187027 fixed a simple oversight of forgetting to check for __ppc__ (only checking __powerpc__), which broke my powerpc-apple-darwin8 stage1 tests, since the system gcc only provided __ppc__. I was wondering if this justifies using simpler macros like #define LLVM_PPC (defined(__ppc__) || defined(__powerpc__) ...) #define LLVM_PPC64 (defined(__ppc64__) ||

Hi all, When you genetate code on PowerPC you need to explicitly invalidate the instruction cache to force the processor to reread it. In LLVM there is code to do this for function stubs on Macintosh, but not for other platforms and not for JITted code generally. The attached patch adds support for GNU platforms, but I can't figure out a nice way to call it for all generated code. Can

On Mon, 16 Jun 2008, Gary Benson wrote: > When you genetate code on PowerPC you need to explicitly invalidate > the instruction cache to force the processor to reread it. In LLVM > there is code to do this for function stubs on Macintosh, but not > for other platforms and not for JITted code generally. Applied, thanks!

Hi, I am trying to generate LLVM code that calls a "native" function in the parent program (the program hosting the JIT). I think that I have figured out how to do this, but I get the following assertion failure when the LLVM code is executed: ../llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23)

2009/10/30 Török Edwin <edwintorok at gmail.com>: > On 2009-10-29 23:55, Jeffrey Yasskin wrote: >> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >> <nicolas.geoffray at lip6.fr> wrote: >> >>> Hi Jeffrey, >>> >>> Jeffrey Yasskin wrote: >>> >>>> Cool, I'll start implementing it. >>>> >>>>

Hi, This is a follow up to my previous email since I have now found out a bit more about what goes wrong. I am generating JIT code that calls a native function, but I get the following assertion telling me that the PC relative jump is too long: /llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) &&

AIX 7.1 & Power5 I have downloaded the llvm source and ran the following steps: 1. ./configure --enable-targets=powerpc 2. gmake Apart from it, i had to make a few changes. i. dladdr code has been commented for the time being and using the default constructor code for that method ii. In Makefile.config, 2 changes were done. +153 # Linker flags. +154 LDFLAGS+=-Wl,-G,-bexpfull +211

Hi, > I know nothing about this, but the failed assertion suggests the PPC > code generator can't cope with a constant that's bigger than > expected at > that point. Have you taken a look at PPCJITInfo.cpp:382? It may shed > some light. It's inside PPCJITInfo::relocate but unfortunately I could not figure out anything from the source. It looks like it's

Hi Jan, > Calling printf works at least on OS X (I'm waiting for a reply > whether this works on linux). If I call my native function it fails > with PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && > ResultPtr < (1 << 23) && "Relocation out of range!"' I know nothing about this, but the failed assertion suggests the

On 2009-10-29 23:55, Jeffrey Yasskin wrote: > On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray > <nicolas.geoffray at lip6.fr> wrote: > >> Hi Jeffrey, >> >> Jeffrey Yasskin wrote: >> >>> Cool, I'll start implementing it. >>> >>> >> Great! Thanks. >> >> Just to clarify things: on my end, it

Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. Ciao, Duncan. > I am currently working with PPC64 JIT support for LLVM. So far I could make function calls > work by adding function

Hello, I am currently working with PPC64 JIT support for LLVM. So far I could make function calls work by adding function descriptors in 'lib/Target/PowerPC/PPCJITInfo.h' and adding a virtual method at 'LLVM::TargetJITInfo' that is called within 'JITEmitter::finishFunction' just after 'sys::Memory::InvalidateInstructionCache' to update the Global Mapping with

Hi Andreas, > /llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion > `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out > of range!"' > ... > So how is this supposed to work? Is it wrong that the memory block for > the JIT code is allocated too far off or should a non PC relative jump > be generated

This is the JITCodeEmitter patch, this is to facilitate cordening off the JIT code from the future direct object emission code (i) supporting the upcoming ObjectCodeEmitter class, on the X86, ARM, Alpha, and PowerPC platforms. This involves generic parameterization of backend code emitters to allow code emission to allotted class types, JITCodeEmitter and ObjectCodeEmitter.

> Are you able make calls to well known external functions such as > printf? As far as I known, this capability is well tested on x86 / > Linux. Calling printf works at least on OS X (I'm waiting for a reply whether this works on linux). If I call my native function it fails with PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1