Store bools as i8 in scalar pairs

[cuviper]

Rust bool mostly uses the LLVM i1 type for immediate values, and
i8 for memory storage, including most aggregates. Scalar pairs were
an exception, also using i1, but this can cause problems when it is
accessed through a pointer to the pair. This patch changes to use the
memory type for scalar pairs too.

Function argument pairs (PassMode::Pair) pass their pieces like
distinct direct arguments, so for this case we explicitly convert bool
to an immediate i1 type again. This way the function can still
optimize knowing the valid 0..2 range of bool values.

Previously, bool-like enum tags were excluded from scalar pairs,
because the i1 didn't optimize well. Now that we're using i8,
optimization seems fine with this, at least for the repeat-trusted-len
test that was reportedly problematic before.

Fixes #50516.
r? @eddyb

[cuviper]

cc @nox - this is taking a different direction than you had in #50277.

[eddyb]

So this already is more complicated than what I did, but if LLVM is still bad at it... might as well.

However, this is still not enough: OperandValue::ScalarPair should contain i1 because it's in "immediate" mode, and only zext/trunct when packing/unpacking into/from the LLVM aggregate type.
One of the original purposes of ScalarPair was to generate optimal IR for checked arithmetic, so handling bools as immediates is essential.
(also, there are some intrinsics that should maybe be simplified a bit)

This should thankfully be easier nowadays, I believe part of why I didn't do it was the pre-miri LLVM constant creation.

[nox]

I wonder how hard it would be to teach SROA about i1 instead.

[cuviper]

@eddyb - Can you be more specific about what changes you'd like to see here? I'm not sure how to represent the difference you state between the sort-of "immediate" mode and the LLVM aggregate type.

@nox Sure, upstream LLVM improvements would be great, but for a while at least we have to worry about some older LLVM too. (It might be about time to consider raising from 3.9 though -- maybe 5?)

FWIW, that particular aarch64 GlobalIsel bug in #50516 was filed as LLVM bug 37393 and appears to be fixed in trunk, but I'm told that this would not be straightforward to backport.

[eddyb]

@cuviper OperandValue::ScalarPair should contain two "immediates" (more specifically, only scalars), with the same rules followed for the value inside OperandValue::Immediate.
immediate_or_packed_pair should zext, while from_immediate_or_packed_pair should trunc, each component of the scalar pair, e.g. converting between ScalarPair(i1 0, i1 1) and { i8 0, i8 1}.

[cuviper]

OK, thanks, I'll see if I can figure that out.

[pietroalbini]

Marked as blocked on #51583.