[test] Enable cfg_optimization in all tests

[xumingkuan]

Related issue = #1905

All the tests passed on my end. I'm not sure in which way will the control-flow graph optimizations incompatible with the new type system?

BTW, in compile_to_offloads.cpp, this part may be redundant and may not perform the check it intends to:

taichi/taichi/transforms/compile_to_offloads.cpp

Lines 105 to 109 in e251ca7

	if (config.cfg_optimization) {
	irpass::cfg_optimization(ir, false);
	print("Optimized by CFG");
	irpass::analysis::verify(ir);
	}

-- this is because cfg_optimization is already called in full_simplify without checking compile config here:

taichi/taichi/transforms/simplify.cpp

Lines 616 to 618 in e251ca7

	if ((first_iteration || modified) &&
	cfg_optimization(root, after_lower_access))
	modified = true;

[Click here for the format server]

---

[yuanming-hu]

Interesting... Thanks for investigating this :-) Maybe a recent change somewhere in the type system fixes the CFG optimizations. Btw, could you add a check of CompileConfig::cfg_optimization in full_simplify, to fix the behavior of that boolean flag? Feel free to merge after the flag is fixed.

[Hanke98]

Great! It seems that skipping cfg_optimization pass is not necessary now. I added this flag when I was not very familiar with Taichi compilation system. At that time, I tried to set and verify data in one single kernel like:

cit = ti.type_factory_.get_custom_int_type(16, True)
x = ti.field(dtype=cit)
ti.root._bit_struct(32).place(x)

@ti.kernel
def test_custom_int_type(data: ti.i32):
      x = data
      assert x == data

And I found that after the pass of cfg_optimization, the assignment statement would always be skipped. So, to make sure the assignment could be executed, I turn off this optimization. Now, almost all of our test cases do the setting and verifying in two separate kernels, which is a better way, so it is not necessary to keep cfg_optimization flag false.

Thank you so much for investigating this!

[xumingkuan]

Great! It seems that skipping cfg_optimization pass is not necessary now. I added this flag when I was not very familiar with Taichi compilation system. At that time, I tried to set and verify data in one single kernel like:

cit = ti.type_factory_.get_custom_int_type(16, True)
x = ti.field(dtype=cit)
ti.root._bit_struct(32).place(x)

@ti.kernel
def test_custom_int_type(data: ti.i32):
      x = data
      assert x == data

And I found that after the pass of cfg_optimization, the assignment statement would always be skipped. So, to make sure the assignment could be executed, I turn off this optimization. Now, almost all of our test cases do the setting and verifying in two separate kernels, which is a better way, so it is not necessary to keep cfg_optimization flag false.

Thank you so much for investigating this!

I see! For this kernel

@ti.kernel
def test_custom_int_type(data: ti.i32):
    x[None] = data
    assert x[None] == data

, the IR is

    <i32> $1 = arg[0]
    <*gen> $2 = get root
    <i32> $3 = const [0]
    <*gen> $4 = [S0root][root]::lookup($2, $3) activate = false
    <*bs(ci16@0)> $5 = get child [S0root->S1bit_struct<bs(ci16@0)>] $4
    <*gen> $6 = [S1bit_struct<bs(ci16@0)>][bit_struct]::lookup($5, $3) activate = false
    <^ci16> $7 = get child [S1bit_struct<bs(ci16@0)>->S2place<ci16><bit>] $6
    $8 : global store [$7 <- $1]
    <i32> $9 = const [1]
    <i32> $10 = cmp_eq $1 $1 # (we can further optimize this in alg_simp)
    <i32> $11 = bit_and $10 $9
    12 : assert $11, "(x[None] == data)"

. When cfg_optimization=False, the IR becomes

    <i32> $1 = arg[0]
    <*gen> $2 = get root
    <i32> $3 = const [0]
    <*gen> $4 = [S0root][root]::lookup($2, $3) activate = false
    <*bs(ci16@0)> $5 = get child [S0root->S1bit_struct<bs(ci16@0)>] $4
    <*gen> $6 = [S1bit_struct<bs(ci16@0)>][bit_struct]::lookup($5, $3) activate = false
    <^ci16> $7 = get child [S1bit_struct<bs(ci16@0)>->S2place<ci16><bit>] $6
    $8 : global store [$7 <- $1]
    <i32> $9 = const [1]
    <i32> $10 = global load $7
    <i32> $11 = cmp_eq $10 $1 # <------ not optimized!
    <i32> $12 = bit_and $11 $9
    13 : assert $12, "(x[None] == data)"

So IIUC cfg_optimization would not make anything go wrong, just make it harder to test?

[Hanke98]

So IIUC cfg_optimization would not make anything go wrong, just make it harder to test?

Yes you are right, that is the exact reason why I turn this optimization pass off. Thanks for the very detailed IR analysis!