I completely agree that the Operand.t datatype is too general. I think it would be illuminating and would improve the backend to work exactly what types of suboperands can appear in arrayOffsets, castInts, contents, etc. I even think it is worth it to express this knowledge explicitly using the ML type system. I don't see any disadvantage to doing so, and it will make (translation to) your IL easier.