I'm targeting a custom instruction set that supports predication for all vector operations, but uses general purpose scalar registers to store predicate values (vector comparisons results are also stored as a bit mask in a scalar register). I've currently specified that scalar registers can be either of type v16i1 (for predicates; vectors have 16 elements) or i32, which would allow them to work in either context: def ScalarReg : RegisterClass<"VP", [i32, v16i1… I soon realized this has an onerous side effect. Since vector comparison results (of type v16i1) can be used in arithmetic, most instructions that deal with scalar registers need to have a patterns for every permutation of v16i1 and i32 parameters. It's not as simple as using a multiclass to manage that, because many of these instructions already have a bunch of different addressing modes. I've come to the conclusion that v16i1 shouldn't really be a legal type for this architecture. But here's the rub: there's no way during type legalization (that I can tell) to convert v16i1 into i32. It wants to widen it into v16i32, which doesn't work at all. So I'm thinking of adding a new LegalizeTypeAction, say 'TypeConcatenateVector' that would do what I've described. However, I'd rather not have to make changes to the type legalizer, since that will make it more of a pain to continue merging mainline back into my fork, and it also feels like the wrong thing to do. While what I'm doing is, as far as I can tell, different than any existing architectures, it certainly isn't exotic or especially weird, so it's odd that I'd need to make such deep changes to the target independent framework to support it. I'm hoping someone can point out a simpler way to handle this or something obvious I've overlooked.