Erroneous expression propagation in the presence of type casts

[maximumspatium]

I noticed that expression propagation doesn't work correctly in the case the instruction destination contains a type cast. Consider the following test case:

# Expression propagation state should be properly updated
# even in the presence of type casts.
10   $a1 = 0xFFF
11   $a2 = data_0x20F000
12   (u32)$a2 = *(u32*)$a2 & $a1
13   if ($a2 == 0) goto exit
14   $a3 = data_0x20F004
15   *(u32*)$a3 = 0
15 exit:
16   return

Expected C-output:

void .ENTRY()
{
  if ((*(u32*)data_0x20F000 & 0xfff) != 0) {
    *(u32*)data_0x20F004 = 0;
  }
}

SABl produces the following C-output instead:

void .ENTRY()
{
  (u32)$a2 = *(u32*)data_0x20F000 & 0xfff;
  if (data_0x20F000 != 0) {
    *(u32*)data_0x20F004 = 0;
  }
}

That's why the type cast of the instruction destination in the line 12 isn't removed before updating the state in xform/bblock_propagation(). This leads to the following two state entries after processing the instruction nr. 12:

$a2 : data_0x20F000
...
(u32)$a2 : *(u32*)data_0x20F000 & 0xfff

Subsequent propagation will therefore pick up $a2 and not (u32)$a2.

[pfalcon]

Need a PR with a (currently broken) testcase ;-).

[maximumspatium]

Need a PR with a (currently broken) testcase ;-).

Sure, PR sent.

[pfalcon]

Ok, by resolving that would require to get rid of the typecasts on l-values. For example, (u32) would be just dropped. (i32) would be dropped to (re: https://github.com/pfalcon/ScratchABlock/issues/8). The rest will be converted to mask/or.

[maximumspatium]

Ok, by resolving that would require to get rid of the typecasts on l-values.

Yes, those should be further completely removed by type analysis.

[pfalcon]

Ok, a pass to rewrite destinations is implemented in https://github.com/pfalcon/ScratchABlock/commit/f3756c3637a68a6f44a19f2405a2b6bb8b29f315.

[pfalcon]

Fixed, tests added.