Revise usage of const_struct and const_array to enhance codegen parity

[sitio-couto]

clangir/clang/lib/CIR/Lowering/DirectToLLVM/LowerToLLVM.cpp

Lines 694 to 712 in d5f6e2b

	// TODO(cir): constant arrays are currently just pushed into the stack using
	// the store instruction, instead of being stored as global variables and
	// then memcopyied into the stack (as done in Clang).
	else if (auto arrTy = op.getType().dyn_cast<mlir::cir::ArrayType>()) {
	// Fetch operation constant array initializer.
	auto constArr = op.getValue().dyn_cast<mlir::cir::ConstArrayAttr>();
	if (!constArr)
	return op.emitError() << "array does not have a constant initializer";
	// Lower constant array initializer.
	auto denseAttr = lowerConstArrayAttr(constArr, typeConverter);
	if (!denseAttr.has_value()) {
	op.emitError()
	<< "unsupported lowering for #cir.const_array with element type "
	<< arrTy.getEltType();
	return mlir::failure();
	}
	attr = denseAttr.value();
	} else

Note: This is indeed an interesting difference, if we forget about LLVM and think only about CIR for a moment, we're also not being uniform right now (my fault), given that const_struct attrs are used inline within cir.const and others are going through globals, at some point we need to migrate more.

Originally posted by @bcardosolopes in #171 (review)

I wonder if this approach is actually better than what clang does, given the lack of memcopy/globals being involved - OTOH we might be loosing uniquing from unnamed address tagged globals. Any thoughts @htyu ?

Originally posted by @bcardosolopes in #171 (comment)

An explicit assignment better supports later optimization passes than a memcpy does, which always requires an additional step of analysis. However from performance point of view an explicit assignment would be as less efficient as memcpy does, but I guess we can always push the conversion to memcpy to llvm.

Originally posted by @htyu in #171 (comment)