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

[Chris Lattner]

On Aug 10, 2010, at 3:53 AM, Kalle.Raiskila at nokia.com wrote:
> 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.

Right, that makes sense.

> The reason it is legal
> (currently, in the SPU backend) is that
> a) it was like that when I found it :)

I think that this is the root of the issue, and stems back to when legalize was much less mature.  I think that fixing this bug is really the best path forward.  It's in the target's best interest to be honest to legalize about what is and is not valid.  Claiming v2i32 (and other 64-bit vectors) are legal will cause a lot of pain throughout the target and a ton of code duplication.

Can you look into what would be required to remove this?

> b) to the best of my understanding, v2i32 has to be legal if it is to be
> used in return values and function parameters.

Beyond Bob's post of "it should work", this is something that can easily be handled by the frontend (by having the frontend lower v2i32 arg/ret values into v4i32 values with shufflevector to extract). This is how the X86-64 backend handles its often-crazy ABI constraints.

-Chris