search for: __mulsi3

...to lower correctly on AVR but the problem is, unfortunately, not just coming from the AVR Target code and I am not sure it can be cleanly fixed just there. (But I would be very happy to be proved wrong as I'm very new to this.) The above code is taken by the legalizer and turned into a call to __mulsi3, but turns the 16 bit parameters into 32 bit parameters by adding 16 bits of 0 to the top 16 bits of each. Unfortunately, to do this, it changes the code to be a call to __mulsi3 with four 16 bit parameters instead of two 32 bit parameters. It orders these parameters based on the endianness of the...

...SP430 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 correspond...

I'm building tool-chain for processor without integer MUL. So, I've defined __mulsi3 for integer multiplication (int32). Now I've got a problem with int64 multiplication which is implemented in libgcc2.c. Segfualt due to infinite recursion in i64 soft multiplication (libgcc2, __muldi3). LLVM-GCC (for my target) misoptimizes code if -O2 is passed. It promotes i32 multiplicatio...

...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" to be 32 bits; clang is just following the C standar...

> 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 msp4...

On Wed, Mar 17, 2010 at 1:32 PM, Sergey Yakoushkin <sergey.yakoushkin at gmail.com> wrote: > I'm building tool-chain for processor without integer MUL. > So, I've defined __mulsi3 for integer multiplication (int32). > > Now I've got a problem with int64 multiplication which is implemented > in libgcc2.c. > Segfualt due to infinite recursion in i64 soft multiplication > (libgcc2, __muldi3). See http://llvm.org/bugs/show_bug.cgi?id=3101 which is essentially...

...workarounds which > use custom lowering to vector instructions. > > My case is different. > > Deeply embedded processors have optional multiplier unit (e.g. > disabled at design time). Thus, efficient and compact MUL > implementation is not available, i32 mul is implemented as __mulsi3 in > libgcc. > > Seems retargetable back-end requires additional efforts in this case: > either to rewrite __muldi3 source code to avoid mul promotion or to > custom lower i64 mul. > > Am I missing someting? > > Does this problem affects existing back-ends like PIC16? &gt...

> This shouldn't be necessary, IMO. If you were going to implement it, > then the correct thing to do would be to have generic selection dag > lowering of large multiplies, which renders the library mostly > useless. In fact, I would prefer to avoid custom lowering for operations on large types. i64 will be rare in my case (embedded) and their performance is not an issue. I need

On Wed, Mar 17, 2010 at 4:57 PM, Sergey Yakoushkin <sergey.yakoushkin at gmail.com> wrote: > Thanks, yes, I'm facing the same issue. > > Hm... seems there are no simple fixes. > I have to do one more i64 mul implementation to workaround aggressive > optimizations. > Is that correct? Is this the only way? This shouldn't be necessary, IMO. If you were going to

On Wed, Mar 17, 2010 at 3:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Mar 17, 2010 at 1:32 PM, Sergey Yakoushkin > <sergey.yakoushkin at gmail.com> wrote: >> I'm building tool-chain for processor without integer MUL. >> So, I've defined __mulsi3 for integer multiplication (int32). >> >> Now I've got a problem with int64 multiplication which is implemented >> in libgcc2.c. >> Segfualt due to infinite recursion in i64 soft multiplication >> (libgcc2, __muldi3). > > See http://llvm.org/bugs/show_bug.cgi...

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>