similar to: [LLVMdev] llvm-gcc promotes i32 mul to i64 inside __muldi3

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

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

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

> 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

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? Can I disable only one particular pass which does this promotion from i32 to i64 using some LLVM-GCC option? Are there other libgcc functions affected by this optimization? Regards, Sergey

Dear, SelectionDAG developers, could you please comment on this issue and clarify internals of MUL lowering? Does my case (processor with soft MUL) supported by current design or such architectures are out of scope? How lowering of large MUL is supposed to work? What kind of minimalistic support should be provided by target back-end? What can be used from current LegalizeDAG? - Thanks, Sergey

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

Thanks Tom. I really appreciate your insight. I'm able to use the customize to get the 64-bit to go to a subroutine and for the 32-bit, I am generate XXXISD::MUL32. I'm not sure then what you mean about "overriding" the ReplaceNodeResults. For ReplaceNodeResults, I'm doing: SDValue Res = LowerOperation(SDValue(N, 0), DAG); for (unsigned I = 0, E =

On Tue, Jul 30, 2013 at 01:14:16PM -0600, Dan wrote: > I'll try to run through the scenario: > > > 64-bit register type target (all registers have 64 bits). > > all 32-bits are getting promoted to 64-bit integers > > Problem: > > MUL on i32 is getting promoted to MUL on i64 > > MUL on i64 is getting expanded to a library call in compiler-rt > >

Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this

I'll try to run through the scenario: 64-bit register type target (all registers have 64 bits). all 32-bits are getting promoted to 64-bit integers Problem: MUL on i32 is getting promoted to MUL on i64 MUL on i64 is getting expanded to a library call in compiler-rt the problem is that MUL32 gets promoted and then converted into a subroutine call because it is now type i64, even though

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

> 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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=us-ascii" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <b>Reid,<br> <br> I followed the steps but got stuck as described

This is an libpath problem. When xgcc runs it wants to dynamically link the libgcc.so. When you run it from the command line it will find your system libgcc.so (which works) and so you don't see the segfault. When you run xgcc from the Makefile, it will have set LD_LIBRARY_PATH to get your <cfebuilddir>/gcc directory which will find the libgcc.so that it just built, which is the one

I've blown a couple of weekends trying to build under MinGW. I can build the llvm tools with only a couple of minor hassles, but can't seem to make any headway with the C Front End Most errors I run into involve not being able to find header files. The most frustrating part is that the error messages report that the file can't be found, and then proceed to give a path to where the

On Mon, Oct 8, 2012 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,

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=utf-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Reid,<br> <br> Here's the backtrace you asked for:<br> <br>

Hi Robert, On Mon, 2006-11-06 at 12:45 -0800, Robert Mykland wrote: > Reid, > > Here's the backtrace you asked for: > > (gdb) bt > #0 0x0862d65c in llvm::LiveVariables::runOnMachineFunction () Hmm, this is a little strange. Your LLVM build is non-debug (there's no line numbers or arguments in any of the llvm related calls). However, your llvm-gcc build seems to have

On Wed, Jul 30, 2008 at 03:06:54PM -0700, Julien Lerouge wrote: > On Wed, Jul 30, 2008 at 11:32:18AM -0700, Bill Wendling wrote: > > On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: > >> ../../../llvm-gcc4.2-src/gcc/libgcc2.c:2095: error: conflicting types > >> for 'VirtualProtect' > >> > >>