Excessive LLVM time in egal codegen of large struct

[Keno]

This is similar to #44998, in that LLVM's SLPVectorizer is involved, but I think it's easier to solve by tweaking the codegen for egal:

struct DefaultOr{T}
   x::T
   default::Bool
end

@eval struct Torture
    $((Expr(:(::), Symbol("x$i"), DefaultOr{Float64}) for i = 1:897)...)
end

egal_any(x::Torture, y::Any) = x === y

julia> @time code_llvm(egal_any, Tuple{Torture, Any})
 22.034327 seconds (5.48 M allocations: 206.847 MiB, 0.40% gc time, 88.69% compilation time: <1% of which was recompilation)

[vtjnash]

I think Oscar was proposing making this code more branch-y, which should help defeat the vectorizer. All those undef padding bits otherwise get in the way of doing simple loops over the bits

[gbaraldi]

Does the padding stop us from emmiting a memcpy?

[Keno]

Yes, the padding is forcing us to emit this unrolled. I think a reasonable implementation here would be to RLE the padding bit pattern and then emit the compare as a sequence of loops with an early out between each block. That should allow the loop vectorizer to emit the correct target-specific comparison sequence for each bit pattern as well as giving it license to early out the loop, without forcing that semantically.

[gbaraldi]

We should probably vendor the expand memcmp code llvm has. Not sure if there is anything that we can annotate the loop to say, hey we don't care if you early/late exit this