If our two inputs have known top-zero bit counts M and N, we trivially know that the output cannot have any bits set in the top (min(M, N)-1) bits, since nothing could carry past that point.
I really can't think of anything without going into x86-specific backend hacks (or other larger-scale changes in the constant optimization bits of the backend) :-/
LLVM tries to aggressively shrink constants in the general case, and unfortunately it hurts here... but I imagine it already hurts in a lot of other cases, this optimization just exposes one more.
I agree, and we should fix this. The code that generates 'andq $-16, %rax' should more-generally match $34359738352 too as -16 by checking that the upper bits of the incoming value are known to be zero.