Taichi: Boolean (u1) type support

[yuanming-hu]

Concisely describe the proposed feature
Currently, binary comparisons return type ti.i32. This is not only counter-intuitive but also inefficient in some cases. Also having native boolean types will allow us to do more compiler optimizations on Taichi IRs.

Boolean types should be implemented as ti.u1, i.e., a single-bit integer.

Note: implementing this feature is harder than it seems to me. You'll have to modify quite a few compiler components. For example, update the type-checker to let comparisons return u1 instead of i32, and the codegens to emit correct types. Fortunately, as we are not running into any urgent need for this, we have plenty of time to implement this.

Related issue: #504

[archibate]

GLSL have bool and bvec2.
Also GLSL isn't happy with:

int tmp1 = 233;
int tmp2 = tmp1 == 0;
int tmp3 = tmp2 ? xxx : yyy;

I had to use int(tmp1 == 0) and tmp2 == 0 ? instead.
Believe this could be saved by making compare result i1, which is bool in GLSL.

[archibate]

Btw, do you think the name u1 is better? Since i1 seems like a signed integer, which means it's highest bit is used as a sign mark. However we only have one bit, and no place for value..

[yuanming-hu]

Agreed. u1 sounds better here. i1 only has values -1 and 0.

[xumingkuan]

bool is interpreted (probably by llvm) as i1 now. Following is a mismatch I just wrote:

[I 03/10/20 23:21:59.532] [llvm_codegen_utils.cpp:taichi::lang::check_func_call_signature@38]   parameter 1 mismatch: required=i1, provided=i32

[yuanming-hu]

Yeah, that was the reason why I initially picked i1. However, we should note that LLVM does not really distinguish unsigned integers from signed ones. I.e., it doesn't have u1. This makes LLVM closer to the hardware. As an IR that works at a higher level, I guess using u1 in Taichi is better.

[github-actions[bot]]

Warning: The issue has been out-of-update for 50 days, marking stale.