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

[Bob Wilson]

On Aug 10, 2010, at 3:53 AM, Kalle.Raiskila at nokia.com wrote:

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

The types of return values and function parameters are also legalized.  If you pass an argument with a non-legal type, it should be promoted or expanded to make it legal.

For example, if i32 is legal but v2i32 is not, you may have v2i32 argument and return types in the LLVM IR, but then legalize those to pairs of i32 values for codegen.

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

I don't understand either of those questions, possibly because I don't know much about SPU.  The legal types for your target should correspond to the values that can be held in a register and that can be handled directly by the instruction set.  I would assume that i32 and f32 are treated separately as legal types because you have registers to hold those values.  If not, i.e., if SPU only has vector registers, then perhaps you should make v4i32, v4f32, etc. legal and try to promote scalar values to vector types.  If simple scalar types are not legal, you may have some problems, for example, as you mention with argument passing.  But, if your target doesn't have any scalar 32-bit registers, passing i32 arguments is going to be a pretty "interesting" regardless....

> 
> 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...
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits