similar to: [LLVMdev] Patch - SPU assembly printer to print ".section .bss"

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

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

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

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

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.

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

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

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:

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

Kalle Raiskila <kalle.raiskila at nokia.com> writes: > Looks like a bug to me. xshw (extend signed half-word(16bits) to > word(32bits)) takes a v8i16 and produces a v4i32. This has likely gone > unnoticed as there is only one type of vector register class (i.e. > VECREG) that is used for all vectors. > > Nice catch :) Are there more of these? I don't know. I stopped

On Feb 28, 2010, at 11:49 PM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > Jakob Stoklund Olesen skrev: >> On Feb 26, 2010, at 10:09 AM, Scott Michel wrote: >>> 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. >

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 ons, 2011-01-05 at 15:23 +0800, ext 陳韋任 wrote: > Hi, folks > > I am "stll" trying to build LLVM-GCC 4.2 on a Linux/PS3 machine, which > has a 64-bit OS. Don't know if it helps, but clang at least builds nicely. Unfortunately I have a 32bit runtime installed and this seems to cause problems somewhere - clang defaults to 64bit assembly (if I understood the output

David Greene wrote: > class XSHWVecInst<ValueType in_vectype, ValueType out_vectype>: > def v4i32: XSHWVecInst<v4i32, v8i16>; > Is this pattern as intended, or did I find a real problem? Looks like a bug to me. xshw (extend signed half-word(16bits) to word(32bits)) takes a v8i16 and produces a v4i32. This has likely gone unnoticed as there is only one type of vector

On Fri, 2010-06-04 at 20:05 +0200, Jakob Stoklund Olesen wrote: > You should fix SPUTargetLowering::LowerCall to make sure there is an unbroken chain of flag ties between CopyFromReg and BRASL. At least ARM, MBlaze, and Blackfin are doing this, if you need example code. > Thanks for the tip. This got fixed in 105601. And with that, half of the problematic tests appearing with

I'm trying the following code on X86: define <3 x i32> @retThree( ) { ret <3 x i32> <i32 1, i32 2, i32 3 > } expecting it to load the three first lanes of %xmm0. (If returning a vector of four, %xmm0 is used). But the generated assembly seems to be using the method of return by hidden pointer. This despite that the generated assembly seems to have allocated the vector