search for: mulsi

> At -O0, you don't. __mulsi3 is the obvious lowering, and you're doing > something wrong if your tools don't provide it. MSP430 is 16 bit target, so mulsi is a bit expensive there, mulhi / mulqi can be implemented via hardware multiplier. There are several problems wrt 16 bit support inside LLVM in general and msp...

...8 and > i16 operands, with i16 and i32 result, I am lowering MUL_i8 and MUL_I16. > However, the front-end promotes the i8 argument to i32, executes 32-bit > multiplier and truncates to 16-bit, so I never lower MUL_I8 nor MUL_I16 > but MUL_I32, wchich is lowered to an external libcall (__mulsi3) that I > don´t have. > > What should I do in order to prevent the front-end from promote to > 32-bit multiplier? (I'm assuming you're getting C code from clang.) You can't, assuming your platform defines "int" to be 32 bits; clang is just following the C standa...

...430 devices is for i8 and i16 operands, with i16 and i32 result, I am lowering MUL_i8 and MUL_I16. However, the front-end promotes the i8 argument to i32, executes 32-bit multiplier and truncates to 16-bit, so I never lower MUL_I8 nor MUL_I16 but MUL_I32, wchich is lowered to an external libcall (__mulsi3) that I don´t have. What should I do in order to prevent the front-end from promote to 32-bit multiplier? If that is not possible, how can I detect when lowering that it is actually a MUL_I8 or MUL_I16 in order to do the correct lowering? Thanks in advance, Pedro P.S: I add C code and correspon...