I don't know how much sense that makes, as the front-end expects a result
expression of a single bool.
LLVM returns a vector of i1 values, the pair-wise results.
From my experience with SIMD on x86_64, what's mostly needed is a vector
bit mask, as that's what the CPU returns and which is later used to mask
accesses/writes.
Anyway, due to new `Target.isVectorOpSupported()` simply allowing all ops,
(not-)equality comparisons of vectors now land here, and I reduce the
pair-wise results via integer bitcast and an additional integer
comparison.
We only needed that findLvalueExp() thing to 1. skip over casts and 2. to
use a (bin)assign's lhs instead of the (bin)assign's result.
Well, by making sure most (bin)assign expression actually return the lhs
lvalue, we don't have this problem anymore and only need to skip over casts
to get to the nested lvalue.
This gets rid of a hacky workaround and brings our AST traversal order
back to normal again.
