search for: mul_i32

...ckend. As the hardware multiplier in most of the MSP430 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...

...are multiplier in most of the MSP430 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? (I'm assuming you're getting C code from clang.) You can't, assuming your platform defines "int"...

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>