Hello, I've been working on a llvm backend for an architecture that is predominantly 16-bit but has 32-bit registers exclusively for load/store operations (in addrspace 1), but I'm having issues with code generation when the 32-bit registers are enabled. Without enabling the 32-bit registers (i.e. with addRegisterClass in ArchTargetLowering constructor) the backend generates valid code for 16-bit pointers, but with 32-bit pointers legalization fails because the compiler doesn't know how to expand the result of my i32 TargetGlobalAddress nodes. Adding my 32-bit register class in the constructor, code is now generated for loading memory from these addresses, but instructions are no longer selectable for the vast majority of 16-bit data operations. I have noticed that common to most of these selection errors is that Constants are i32, they are copied to a virtual i32 register and a top level operation (e.g. i32 xor) is where the fatal error is reported. To check whether the constants are the source of the problem, I changed ArchTargetLowering to custom lower i32 ISD::Constants, replacing them with i16 equivalents (naive manual truncating of values, suitable only for checking if constants are the problem, for instance I can see soft floating point issues arising here). This made some trivial examples disappear, but backend errors still appear and of a similar form where an instruction can't be selected, one node is a i32 CopyFromReg and where 32-bit registers have been chosen to store things needlessly. Has anyone had any experience with something similar, forcing LLVM to not use a particular size register for anything other than for storing addresses for loading/storing that might have ideas on how to solve the issues I'm seeing? Many Thanks, Simon