search for: mul_i8

Hi, I am trying to complete the hardware multiplier option for MSP430 backend. 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 p...

...012 at 2:44 AM, Pedro Malagón <malagon at die.upm.es> wrote: > Hi, > > I am trying to complete the hardware multiplier option for MSP430 backend. > > 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...

> 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 msp430 in particular: 1. In some places LLVM expectes 32 bit or 64