Return int8Ty instead of i1 when function defined return type `bool`

[llvm]

Return int8Ty instead of i1 when function defined return type `bool`

[lanza]

This is actually a bit uglier than I thought. Clang shoehorns the bool to an i8 when it needs it and an i1 otherwise. So our representation has to keep track of what clang decided to do since this is effectively clang-codegen-ABI and we have to agree exactly with the ABI at the LLVMIR level if we want to be able to module link with CodeGen emitted IR files.

[lanza]

For x86_64-unknown-linux-gnu Clang emits function type usages of bool to LLVM as an i1 but within the function emits i8s. So for example

bool foo(bool a) {
    return a;
}

yields:

define dso_local noundef zeroext i1 @_Z3foob(i1 noundef zeroext %a) #0 {
entry:
  %a.addr = alloca i8, align 1
  %frombool = zext i1 %a to i8
  store i8 %frombool, ptr %a.addr, align 1
  %0 = load i8, ptr %a.addr, align 1
  %tobool = trunc i8 %0 to i1
  ret i1 %tobool
}

So converting cir.bool to i8 is correct within the function but the functiontype is wrong. So it's not as straightforward as just changing the typeconverter to emit an i1. I don't recall off the top of my head how to fix it at the moment, though.

If you're motivated to take a look at this, one warning is that the constraint around the cir.bool -> i8 is very strongly constrained by numerous usages such as cir.if. I had to pepper a number of extra truncs and zexts to get everything in agreement with what clang does within a function. So I suggest looking specifically at the function type converter. That'll be my plan when I get around to looking at this.

[redbopo]

Thanks for suggestion.
There is some difference between the examples we represent.

bool foo(bool a) {
    return a;
}

Using the bool variable a, will try to allocate an int8 type instruction.
If we change to unsigned or other type, it won't occur.

bool foo(unsigned a) {
    return a;
}

// ./bin/clang++ foo.cpp -S -emit-llvm -o -

define dso_local noundef zeroext i1 @_Z3fooj(i32 noundef %a) #0 {
entry:
  %a.addr = alloca i32, align 4
  store i32 %a, ptr %a.addr, align 4
  %0 = load i32, ptr %a.addr, align 4
  %tobool = icmp ne i32 %0, 0
  ret i1 %tobool
}

And the Clang CodeGen procedure of ConvertTypeForMem() which handles the formmer

clangir/clang/lib/CodeGen/CodeGenTypes.cpp

Lines 85 to 96 in 6f182fd

	}
	/// ConvertTypeForMem - Convert type T into a llvm::Type. This differs from
	/// ConvertType in that it is used to convert to the memory representation for
	/// a type. For example, the scalar representation for _Bool is i1, but the
	/// memory representation is usually i8 or i32, depending on the target.
	llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) {
	if (T->isConstantMatrixType()) {
	const Type *Ty = Context.getCanonicalType(T).getTypePtr();
	const ConstantMatrixType *MT = cast<ConstantMatrixType>(Ty);
	return llvm::ArrayType::get(ConvertType(MT->getElementType()),
	MT->getNumRows() * MT->getNumColumns());

So I don't think using the i8 within the function is a correct method.

Meanwhile, here are two allocate instructiones in CIR while LLVM IR only one, seems like redundant in some where.

[lanza]

Using the bool variable a, will try to allocate an int8 type instruction.

Yup, that we know is wrong. And you seemed to have found out why by looking at CodeGenTypes::ConvertTypeForMem! I clearly missed the the (!T->isBitIntType() && R->isIntegerTy(1))) when adding this initially.

Thank you for pointing this out!

Meanwhile, here are two allocate instructiones in CIR while LLVM IR only one, seems like redundant in some where.

We explicitly always alloc the __retval. Clang seems to elide it in certain situations.

cir.func @_Z3foob(%arg0: !cir.bool) -> !cir.bool {
    %0 = cir.alloca !cir.bool, cir.ptr <!cir.bool>, ["a", init] {alignment = 1 : i64}
    %1 = cir.alloca !cir.bool, cir.ptr <!cir.bool>, ["__retval"] {alignment = 1 : i64}
    cir.store %arg0, %0 : !cir.bool, cir.ptr <!cir.bool>
    %2 = cir.load %0 : cir.ptr <!cir.bool>, !cir.bool
    cir.store %2, %1 : !cir.bool, cir.ptr <!cir.bool>
    %3 = cir.load %1 : cir.ptr <!cir.bool>, !cir.bool
    cir.return %3 : !cir.bool
  }

I'm not worried about this since it's clearly super trivial for an optimizer to know it can be removed.