Legalizing types: when do operands get updated?

Project Infrastructure LLVM Dev List Archives
#1

The example code:

; ModuleID = ‘struct_2.bc’
target datalayout = “E-p:32:32:128-f64:64:128-f32:32:128-i64:32:128-i32:32:128-i16:16:128-i8:8:128-i1:8:128-a0:0:128-v128:128:128-s0:128:128”
target triple = “spu”

@boolvar = internal global i1 false

define void @set_boolvar() nounwind {
entry:
store i1 true, i1* @boolvar, align 16
ret void
}

This gets legalized to:

=== set_boolvar
Initial selection DAG:
SelectionDAG has 7 nodes:
0xe00711c: i32 = Constant <0>
0xcc056f0: ch = EntryToken
0xe00700c: i1 = Constant <-1>
0xe007094: i32 = GlobalAddress <i1* @boolvar> 0
0xe0071a4: i32 = undef
0xe00722c: ch = store 0xcc056f0, 0xe00700c, 0xe007094, 0xe0071a4 <0xcc02bbc:0> alignment=16
0xe0072b4: ch = ret 0xe00722c

Optimized lowered selection DAG:
SelectionDAG has 6 nodes:
0xcc056f0: ch = EntryToken
0xe00700c: i1 = Constant <-1>
0xe007094: i32 = GlobalAddress <i1* @boolvar> 0
0xe0071a4: i32 = undef
0xe00722c: ch = store 0xcc056f0, 0xe00700c, 0xe007094, 0xe0071a4 <0xcc02bbc:0> alignment=16
0xe0072b4: ch = ret 0xe00722c

Legally typed node: 0xe0071a4: i32 = undef
Legally typed node: 0xe007094: i32 = GlobalAddress <i1* @boolvar> 0
Promote integer result: 0xe00700c: i1 = Constant <-1>
Legally typed node: 0xe00711c: i8 = Constant <1>
Legally typed node: 0xcc056f0: ch = EntryToken
Promote integer operand: 0xe00722c: ch = store 0xcc056f0, 0xe00700c, 0xe007094, 0xe0071a4 <0xcc02bbc:0> alignment=16
[–Crash occurs here–]

The crash occurs because the second operand to store is still an i1; it doesn’t appear to have been updated to the i8 that was previously legalized. Stores for CellSPU are custom lowered. Is it my responsibility to promote the second operand or should I expect that the store’s operands be updated after they have been type-legalized?

-scooter

#2

Hi,

Promote integer operand: 0xe00722c: ch = store 0xcc056f0, 0xe00700c,
0xe007094, 0xe0071a4 <0xcc02bbc:0> alignment=16
[--Crash occurs here--]

on my machine it does not crash here. Instead, CellSPU tries to custom
lower the i1 store and produces a v128i1 vector (craziness!) and eventually
a custom node v128i1 = SPUISD::SHUFB 0x29eb798, 0x29eb398, 0x29eb698 with
an illegal type. At that point it crashes because this is not allowed.
So maybe you have some local patches applied?

The crash occurs because the second operand to store is still an i1; it
doesn't appear to have been updated to the i8 that was previously legalized.

It's hard to comment without being able to reproduce the problem. It works
on other platforms, so presumably there is something CellSPU specific going
on...

Stores for CellSPU are custom lowered.

You shouldn't try to custom lower stores of i1 (or other illegal types)
however. I see that CellSPU currently does though: it sets the operation
action for store of i1 to Custom. I think this is a mistake.

Is it my responsibility to promote
the second operand or should I expect that the store's operands be updated
after they have been type-legalized?

The result of type legalization should be a truncstore of i8 to i1. However
this will not be the case if the target custom lowers the i1 store to something
else.

Ciao,

Duncan.

#3

This seems to fix it:

Index: llvm/lib/Target/CellSPU/SPUISelLowering.cpp