search for: __ppc__

> ----- 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__) || defined(__powerpc__) ...) >&...

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 >>>> __ppc__. I was wondering if this justifies using simpler macros >>>> like >>>> >>>> #define LLVM...

----- 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 wondering if this justifies using simpler macros > >> like > >> > >> #define LLVM_PPC (defined(__pp...

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__) || defin...

----- 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__) || defined(__powerpc__) ...) > #define LLVM_PPC64...

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!

...ction stubs on > > Macintosh, but not for other platforms and not for JITted code > > generally. > > Applied, thanks! Thanks :) > I tweaked it to work on non-ppc systems too. I had to revert the change you made there -- my system doesn't seem to have any of __POWERPC__, __ppc__ or _POWER power defined... > > 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 > > anyone help? > > Can you elaborate on what the problem is? The attached patch generalizes it (aKor helpe...

...r all generated code. Can anyone help? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- --- lib/Target/PowerPC/PPCJITInfo.cpp.orig 2008-06-11 07:12:39 +++ lib/Target/PowerPC/PPCJITInfo.cpp 2008-06-16 08:42:25 @@ -336,6 +336,20 @@ #if (defined(__POWERPC__) || defined (__ppc__) || defined(_POWER)) && \ defined(__APPLE__) sys_icache_invalidate(Addr, len); +#elif defined(__GNUC__) + const size_t LineSize = 32; + + const intptr_t Mask = ~(LineSize - 1); + const intptr_t StartLine = ((intptr_t) Addr) & Mask; + const intptr_t EndLine = ((intptr_t) Addr +...

...Info.cpp =================================================================== --- lib/Target/PowerPC/PPCJITInfo.cpp (revision 51432) +++ lib/Target/PowerPC/PPCJITInfo.cpp (working copy) @@ -72,7 +72,7 @@ extern "C" void PPC64CompilationCallback(); #if (defined(__POWERPC__) || defined (__ppc__) || defined(_POWER)) && \ - !defined(__ppc64__) + !(defined(__ppc64__) || defined(__FreeBSD__)) // CompilationCallback stub - We can't use a C function with inline assembly in // it, because we the prolog/epilog inserted by GCC won't work for us. Instead, // write...

...ry for Mac OS X has the following .../lib/R/include/Rconfig.h. What step am I missing that causes this file to be generated? Thanks, Kjell /* This is an automatically generated universal stub for architecture-dependent headers. */ #ifdef __i386__ #include "i386/Rconfig.h" #elif defined __ppc__ #include "ppc/Rconfig.h" #elif defined __ppc64__ #include "ppc64/Rconfig.h" #elif defined __x86_64__ #include "x86_64/Rconfig.h" #elif defined __arm__ #include "arm/Rconfig.h" #else #error "Unsupported architecture." #endif

...I have a fast_math.[hc] in vorbis/lib and have a _fast_sqrt() inline in fast_math.h. If anyone else wants to try it out, it follows. I can currently encode my test file (the first 15 seconds of Supervixen by Garbage) in about 11.1 seconds. Faster than real time, at least :) -tim #if defined(__ppc__) // Vanilla PPC code, but since PPC has a reciprocal square root estimate instruction, // runs *much* faster than calling sqrt(). We'll use two Newton-Raphson // refinement steps to get bunch more precision in the 1/sqrt() value for very little cost. // We'll then invert using the PPC reci...

...enerate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. LLVM IR contains a target-information line but is otherwise target independent. This does *not* mean that you can convert C to LLVM IR in a target independent way. C code may contain "#ifdef __ppc__". Now what? Or how about "switch (x) { case sizeof(int): ... }". This question is a FAQ: http://llvm.org/docs/FAQ.html#platformindependent LLVM IR is portable in the sense that it will run the same on any platform. C is portable in the sense that you can detect things about the...

...p on how to insert the creqv instruction in the calling sequence. After this is implemented, I will be able to send a patch for linux/ppc support. I also need to know what is your preference for a linux/ppc target implementation? I can either 1) Use macros (#ifdef __MACH__ for darwin or #ifdef __PPC__ for linux) 2) Test the target in the code when needed if (os == linux && ppc32) then... else if (os == linux && ppc64) then ... else if (os == darwin && ppc32) then ... else if (os == darwin && ppc64) then ... 3) Create a new subtarget (but does it worth...

I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. -Timo -----Ursprüngliche Nachricht----- Von: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

...ated-as it assembles as expected. I was able to get it to work without the integrated assembler with this change: # # extern int unw_getcontext(unw_context_t* thread_state) # # Just trap for the time being. DEFINE_LIBUNWIND_FUNCTION(unw_getcontext) .set mips32r2 teq $0, $0 #elif defined(__ppc__) telling the assembler to allow r2 instructions. Should the integrated assembler be enabled by default for the Mips? It looks as if the stock clang does not use the integrated assembler yet. -Rich

...r this is implemented, I will be able to send a patch for linux/ppc > support. Nice. This will also resolve http://llvm.org/PR1064 > I also need to know what is your preference for a linux/ppc target > implementation? I can either > 1) Use macros (#ifdef __MACH__ for darwin or #ifdef __PPC__ for linux) This won't work for cross compiles. > 2) Test the target in the code when needed > if (os == linux && ppc32) then... > else if (os == linux && ppc64) then ... > else if (os == darwin && ppc32) then ... > else if (os == darwin &&amp...

...enerate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. LLVM IR contains a target-information line but is otherwise target independent. This does *not* mean that you can convert C to LLVM IR in a target independent way. C code may contain "#ifdef __ppc__". Now what? Or how about "switch (x) { case sizeof(int): ... }". This question is a FAQ: http://llvm.org/docs/FAQ.html#platformindependent LLVM IR is portable in the sense that it will run the same on any platform. C is portable in the sense that you can detect things about the...

...write it. Are you using Clang as the frontend? If so, my recommendation would be to start by creating a header file that implements the NEON intrinsics in terms of generic functionality and the Altivec ones. The header file would need to look kind of like this: #if defined(__powerpc__) || defined(__ppc__) #define neon_intrinsic1 ppc_neon_intrinsic1 static __inline__ vec_type __attribute__((__always_inline__, __nodebug__)) ppc_neon_intrinsic1(vec_type a1, vec_type a2) { ... } ... #endif If you look in tools/clang/lib/Headers you'll see lots of example intrinsics header files, and if you lo...

On 2 October 2013 12:17, Renato Golin <renato.golin at linaro.org> wrote: > On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > >> How does this make any sense? >> > > I have to agree with you that this doesn't make much sense, but there is a > case where you would want something like that: when the original source > uses NEON

On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > How does this make any sense? > I have to agree with you that this doesn't make much sense, but there is a case where you would want something like that: when the original source uses NEON intrinsics, and there is no alternative in AltiVec, AVX or even plain C. We encourage people to use NEON intrinsics,