[llvm-commits] [llvm] r110576 - in /llvm/trunk: lib/Target/CellSPU/SPUISelLowering.cpp lib/Target/CellSPU/SPUISelLowering.h lib/Target/CellSPU/SPUInstrInfo.td lib/Target/CellSPU/SPUNodes.td lib/Target/CellSPU/SPURegisterInfo.cpp test/CodeGen/CellSP...

[Kalle.Raiskila at nokia.com]

On Tue, 2010-08-10 at 02:24 +0200, Chris Lattner wrote:
> On Aug 9, 2010, at 9:33 AM, Kalle Raiskila wrote:
> 
> > Author: kraiskil
> > Date: Mon Aug  9 11:33:00 2010
> > New Revision: 110576
> > 
> > URL: http://llvm.org/viewvc/llvm-project?rev=110576&view=rev
> > Log:
> > Have SPU handle halfvec stores aligned by 8 bytes.
> 
> Kalle,
> 
> Again, what's going on here?  Why isn't type legalization doing its job?

Good question. With the 8byte memory accesses I was just copying the
functionality of the 4, 2, and 1 byte accesses. (16 bytes being the
granularity of the memory access). I thought they must be implemented as
they are for a reason.

Experimenting a little shows that promoting v2i32 works rather nicely,
*if* v2i32 is not a "legal" type (i.e. there is no register class added
for v2i32). When it is a legal type, all sorts of asserts trigger when
trying to expand operations on that type. The reason it is legal
(currently, in the SPU backend) is that
a) it was like that when I found it :)
b) to the best of my understanding, v2i32 has to be legal if it is to be
used in return values and function parameters.

So: what is the reason i32 (and f32, and so on) are treated separately,
as if there were separate instructions/registers for that type, as
opposed to just being promoted to v4i32, v4f32 and so on?
And: is there a way of passing illegal types of arguments (such as i32
etc.) to functions? 

If the parameter passing and promotion are possible, I see no reason at
all to separately treat half (quarter) full vectors.


thanks, 
kalle

P.s. sorry for not replying to the previous mail with essentially the
same question: I (hope I) have now removed the relevant bug from my mail
filter...