There could be a need for deopt bundle operand's stack slots to be N byte aligned.
This patch introduces an option -promote-slot-bits-in-selection-dag that specifies minimum bit size for such slots.
Any reason why do you specify alignment in bits instead of bytes?
Is there any (supported by LLVM) CPU architecture with bit-addressing of memory?
(That really look strange to me, given byte size is hardcoded to 8 bits)
I don't think a command line argument is the right way to describe this. I strongly suspect that this number is a property of the calling convention of the call (or maybe a combination of the callers calling convention and the calls calling convention.) If so, I would suggest reframing it in that manner.
For calling conventions which don't explicitly override it to something wider, using the abi alignment (e.g. the same we'd use for argument passing) seems like a reasonable default. That should also give you way to write tests without upstreaming the custom calling convention motivating this.
Style: Please use early return.
If you split the promote function into one which produced the promoted type, and one which did the actual promotion, I think you can simplify this code, make it easier to keep in sync, and probably simplify some of your asserts.
In particular, previous suggestion should greatly simplify this block of code.