similar to: [LLVMdev] review: gcc4 patches for cell-spu

It's official: Aerospace has given me permission to release the code, such as it is. I will be checking in pieces as I fix 80-col violations and performing general cleanups. PLEASE NOTE: I intended to check the code into the LLVM SVN repository when the backend could generate a clean compile of llvm- gcc-4.2, but due to a bug, I'm going to have to check in __broken__ code. That

Chris Lattner skrev: > On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote: >> currently the SPU backend does not handle big stack frames (>16*511 >> bytes) nicely. llc asserts on malformed machine instructions. >> (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first >> operand is not immediate") > > Sounds fine

Hello > Would it be possible to conditionally enable the register scavenger only if > the function has a big stack? It now gets unconditionally enabled in >  SPURegisterInfo::requiresRegisterScavenging(const MachineFunction &MF). > Just checking MF.getFrameInfo()->getStackSize() here doesn't seem to be the > solution... Well, I think no. regscavenger should work well

Hi, On 12/11/06, Scott Michel <scottm at rushg.aero.org> wrote: > Here's where my issue about DTRT with llvm-gcc (or whatever your prefix > to llvm tools happens to be) resurfaces. I'm keenly aware that Chris > thinks that one really ought to be careful with having llvm-gcc emit > bytecode. But frankly, if that's the case, what's the point of emitting > byte

Hello everyone, Stopped by Best Buy last night and picked up a Rio Karma. Since from-the-trenches reviews seem scarce, I thought I might post some thoughts. The short story: I'm probably returning it, will be buying a different portable player. The software doesn't work, and I don't think I wanna screw with it. The long story: It looks cool, is tiny,

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

On Mar 29, 2010, at 6:50 AM, Kalle Raiskila wrote: > attached is a second try for the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions: > -in vararg handling, registers are marked to be live, to not confuse the register scavenger Looks good. You can try running with -verify-machineinstrs to detect

I compiled the following code with llvm-gcc (4.2.1) and llc (2.3svn) for spu of Cell broadband engine processor. > cat add.c float add (float a, float b) { return a + b; } > llvm-gcc add.c --emit-llvm -c -o add.bc > llc -march=cellspu add.bc Cannot yet select: 0x867c700: v4f32 = SPUISD::INSERT_MASK 0x8670800 Abort (core dumped) But llc returned the above error. If I

Hi, On SPU, variables in the .bss section that are allocated with the .lcomm directive are not aligned on 16 byte boundaries. This causes misaligned loads, as the generated assembly assumes this "default" alignment. A patch to disable .lcomm in favour of '.local .comm' is attached. kalle P.s. As an example, the following function returns '3', when '5' is

Hello, I noticed that the SPU assembly printer prints just ".bss", when gas requires ".section .bss". Now the gas prints out: Assembler messages: Error: expected symbol name Attached is a test case and a patch to fix this. (This time 'make check' passes also ;) kalle -------------- next part -------------- A non-text attachment was scrubbed... Name: spu_bss.patch

hi, either function call in this code makes llc (targeting SPU) assert: declare i8 @return_i8() declare i16 @return_i16() define void @testfunc() { %rv1 = call i8 @return_i8() %rv2 = call i16 @return_i16() ret void } Attached is a patch to fix it, and remove some related redundant code. Does this rather trivial fix warrant a test case? kalle -------------- next part -------------- A

Hi, attached is a second try for the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions: -in vararg handling, registers are marked to be live, to not confuse the register scavenger -function prologue and epilogue are not emitted, if the stack size is 16. 16 means it is empty - there is only the

On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote: > Hello all, > > currently the SPU backend does not handle big stack frames (>16*511 > bytes) nicely. llc asserts on malformed machine instructions. > (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first > operand is not immediate") Sounds fine to me in general. Please write a

Hello all, currently the SPU backend does not handle big stack frames (>16*511 bytes) nicely. llc asserts on malformed machine instructions. (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first operand is not immediate") E.g. the function: define i32 @foo() nounwind { entry: %retval = alloca i32 %big_data = alloca [1000 x i32] store i32 3840, i32*

/Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp: In function 'bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)': /Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp:141: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from

I know that Al Stone has compiled llvm-gcc4 successfully and I can report the same. The problem I consistently run into is that llvm-gcc ends up producing native format output; it does not produce bytecode, nor does it invoke gccas or gccld. I'm using the latest svn, and my configure args are: --prefix=/work/scottm/llvm-cfrontend/obj/../i686-pc-linux-gnu \

I don't think llvm-gcc4 uses gccas or gccld, but it can emit bytecode if you give it the --emit-llvm option: llvm-gcc --emit-llvm -c -o foo.bc foo.c On 8/14/06, Scott Michel <scottm at rushg.aero.org> wrote: > I know that Al Stone has compiled llvm-gcc4 successfully and I can > report the same. The problem I consistently run into is that llvm-gcc > ends up producing native

The Karma Hall Of Fame is now available at: http://bugs.digium.com/karma_halloffame.php Users with negative karma aren't named'n'shamed.. YET.. but congrats to all the users with positive karma on the current list! The list shows all users holding the top 10 karma scores in the system. Right now you need a 12 or above to feature on the list, and there's a boat load of people just

Hello, I'm running a samba 3.0.14a server in production on a fedora core 3 (kernel 2.6.9-1.667smp) with a least 250 clients (XP Pro SP2) (up to 400 sometimes). A few days ago, a problem appeared with a soft that we are using for a long time. (Petit Robert, a french dictionnary). When someone launch the dictionnary, many clients are freezed when they try to access to the "start