codegen: ensure i1 bool is widened to i8 before storing

[vtjnash]

Teach value_to_pointer to convert primitive types to their stored representation first, to avoid exposing undef bits later (via memcpy).

Take this opportunity to also generalizes the support for zext Bool to anywhere inside any struct for changing any bitwidth to a multiple of 8 bytes. This would change a vector like <2 x i4> from occupying i8 to i16 (c.f. LLVM's LangRef), if such an operation were expressible in Julia today. And take this opportunity to do a bit of code cleanup, now that codegen is better and using helpers from LLVM.

Fixes #52127

For backporting this fix to older versions, the minimal diff to use is:

diff --git a/src/codegen.cpp b/src/codegen.cpp
index 5ad4eb4e6e..b89a9f5ca6 100644
--- a/src/codegen.cpp
+++ b/src/codegen.cpp
@@ -1935,6 +1935,8 @@ static bool valid_as_globalinit(const Value *v) {
 static inline jl_cgval_t value_to_pointer(jl_codectx_t &ctx, Value *v, jl_value_t *typ, Value *tindex)
 {
     Value *loc;
+    if (v->getType()->isIntegerTy(1))
+        v = ctx.builder.CreateZExt(v, IntegerType::get(v->getContext(), 8));
     if (valid_as_globalinit(v)) { // llvm can't handle all the things that could be inside a ConstantExpr
         assert(jl_is_concrete_type(typ)); // not legal to have an unboxed abstract type
         loc = get_pointer_to_constant(ctx.emission_context, cast<Constant>(v), Align(julia_alignment(typ)), "_j_const", *jl_Module);

[vtjnash]

CI is good. @JeffBezanson is this good to merge?

[wsmoses]

@vtjnash could this code be exported rather than static. We have this implemented in Enzyme.jl already and it would be nice to not need to duplicate it: https://github.com/EnzymeAD/Enzyme.jl/blob/4329953f6f707982f841c6ed6bc164dd5ae65094/src/compiler.jl#L2095

[vtjnash]

@wsmoses It looks like you already have a version of it. It shouldn't be that necessary to use, as we use it just before we fully initialize the struct with actual content. I just prefer avoiding letting LLVM see any non-integral UndefValue and taking too many licenses with that (since we could attempt to observe them later on in gc-lowering), even though that is unlikely (and I think we would ignore / correct that later anyways)