[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 Wed, 2010-08-11 at 02:11 +0200, Chris Lattner wrote:
> On Aug 10, 2010, at 3:53 AM, Kalle.Raiskila at nokia.com wrote:

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

Ok, I'll have a look. Just removing the v2i32 code from the SPU backend
is simple. Getting it to be promoted instead of expanded... lets see...

I wonder if I should have a go at trying to get i32 promoted to v4i32 at
the same time :)

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

Certainly, when strict ABI compliance is required the frontend should do
this lowering. However, not asserting on code that uses LLVM native
types (including v2i32) would be nice. Especially as v2i32 is so easily
mapped to v4i32. 


kalle