search for: raiskila

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

...uses new problems in the CellSPU backend (more stqd's and lqd's), so I have to investigate those before committing the patch. 'make test' is our friend. 'make test' is our friend. 'make test' is our friend. :-) -scooter On Thu, Feb 25, 2010 at 11:25 PM, <Kalle.Raiskila at nokia.com> wrote: > > 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...

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

...this issue. Attached is a patch to fix this. It -fixes a few small errors in function prologue and epilogue insertion -enables register scavenging for frame index elimination and - implements the frame index elimination for big stacks. Patch is made against latest svn head. best regards, Kalle Raiskila -------------- next part -------------- A non-text attachment was scrubbed... Name: spu_stackframes.patch Type: text/x-patch Size: 5333 bytes Desc: spu_stackframes.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100222/018d292f/attachment.bin>

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

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

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

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

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

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

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 working on enhancing TableGen's type checking and it triggered with a problem in CellSPU's specification: XSHWv4i32: (set VECREG:v8i16:$rDest, (sext:v8i16 VECREG:v4i32:$rSrc)) It's complaining that v4i32 is not smaller than v8i16, which is true in the sense of vector bit size, and true in the sense of vector element size. To me, a sign extension from i32 to i16 makes no

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 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 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 Friday 12 March 2010 08:13:05 Kalle Raiskila wrote: > David Greene wrote: > > Here's a rework using PassManager as Chris suggested. Comments? > > Tried this second patch with the svn version 97812 (the one the patch is > made against), but it doesn't compile: > "llvm/include/llvm/Pass.h:127: Error: expected...

David Greene wrote: > Here's a rework using PassManager as Chris suggested. Comments? Tried this second patch with the svn version 97812 (the one the patch is made against), but it doesn't compile: "llvm/include/llvm/Pass.h:127: Error: expected unqualified-id before "&" token" Seems raw_ostream is forward declared but not defined (adding a missing #include

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