search for: mc68k

...s a and b and you do a signed multiply: > c = a *s b > and an unsigned multiply > d = a *u b > then c and d are the same number (exactly the same bits set). At least two architectures I know about have size-extending multiplication, for which your statement is not true: - Motorola MC68K has i16 x 16 -> i32 instructions in signed and unsigned forms - Itanium has signed and unsigned multiplications with i64 x i64 -> i64 where you can take the high or low part of the resulting i128. While xma.lu is a pseudo-op since it's the same as xma.lu, xma.hu and xma.h (unsigned and s...

Hi, my target handles operands of multiplying instructions differently based on signedness. I wonder then how I would do instruction selection based on the operands signs? The mul instruction sets a nsw for signed, but when i try unsigned ops, there is no wrap flag at all. I'm not sure this is enough information to work with, or? Jonas -------------- next part --------------

Hi Jonas, > my target handles operands of multiplying instructions differently based on > signedness. since the result of a multiply doesn't depend on the signedness, I find it strange that your target differentiates between them. What I'm saying is that if you have (say) two i32 numbers a and b and you do a signed multiply: c = a *s b and an unsigned multiply d = a *u b

...multiplication, for which your statement is not true: yup, and that's why LLVM codegen has the SMUL_LOHI/UMUL_LOHI etc nodes. However that's not relevant to ordinary multiplication (codegen MUL node) which is what I understand the question to be about. Ciao, Duncan. > > - Motorola MC68K has i16 x 16 -> i32 instructions in signed and unsigned forms > > - Itanium has signed and unsigned multiplications with i64 x i64 -> i64 where you can take the high or low part of the resulting i128. While xma.lu is a pseudo-op since it's the same as xma.lu, xma.hu and xma.h (uns...