[LLVMdev] Legalizing types: when do operands get updated?

[Scott Michel]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081119/e782308f/attachment.html>