similar to: [LLVMdev] Patch - Big stacks on SPU, take 2

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

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

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*

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, 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

Kalle: Your patch is similar to what I'd coded (and am testing, which means a couple of hours before I consider committing). Other than cosmetic changes and changing 'NULL' to '0' (it's an integer list, after all). This patch now causes new problems in the CellSPU backend (more stqd's and lqd's), so I have to investigate those before committing the patch.

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

Scott Michel skrev: > No, I wasn't having a management lobotomy moment. If the target's registers have > no subregisters, SubUsed is false and the assert gets tripped. > > Ok, back to the original question: What was the original intent in this code > (lines 186-193 in lib/CodeGen/RegisterScavenging.cpp)? You beat me to it :). A simple bypass (patch attached) does at

No, I wasn't having a management lobotomy moment. If the target's registers have no subregisters, SubUsed is false and the assert gets tripped. Ok, back to the original question: What was the original intent in this code (lines 186-193 in lib/CodeGen/RegisterScavenging.cpp)? -scooter On Thu, Feb 25, 2010 at 7:00 PM, Scott Michel <scooter.phd at gmail.com> wrote: > Ugh.

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

On Jun 4, 2010, at 1:57 AM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: >> If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. >> > Tried it, and it seems to break quite a big chunk of our tests on SPU :)

On Jan 5, 2011, at 1:47 PM, Erik de Castro Lopo wrote: > Kalle Raiskila wrote: > >> And I probably should file a bug. Is ppc32 still maintained? > > I have no concrete knowledge of this, but llvm compiles > and passes all tests on ppc32, so it seems to be maintained. > About once a week I grab the latest SVN head and check this. It is run by one of the automatic

dalej skrev: > On Jan 5, 2011, at 1:47 PM, Erik de Castro Lopo wrote: > >> Kalle Raiskila wrote: >> >>> And I probably should file a bug. Is ppc32 still maintained? >> I have no concrete knowledge of this, but llvm compiles >> and passes all tests on ppc32, so it seems to be maintained. >> About once a week I grab the latest SVN head and check this.

On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: > If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. > Tried it, and it seems to break quite a big chunk of our tests on SPU :) Before r103488 ("Mostly rewrite RegAllocFast") there was no problem. But with r103488, I get a:

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

As Andy Pinski pointed out, there were some really good reasons why Cell SPU support never made it into gcc 4.2. I've attached the patches from the 4.1.1 compiler, and I've applied+compiled them in my local tree. I suggested creating a branch, but since they appear to be relatively disjoint, the need for a branch doesn't seem necessary. Sorry for the large patch file -- I didn't

Hello LLVMDev, I've encountered what looks like a bug in LLVM 2.9, it doesn't appear to be fixed in 3.0 either. The problem occurs in function ARMFrameLowering.cpp:processFunctionBeforeCalleeSavedScan. There's a circular dependency in setting the variable BigStack and AFI->setHashStackFrame(true). The expression which initializes BigStack calls estimateRSSStackSizeLimit which in

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