similar to: [LLVMdev] how to lower MUL i64 for soft int arithmetic?

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

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 multiplication 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

Hi, Is there anyone else interested in fixed-point arithmetic support in clang/llvm? Regards, Sergey On Sat, Aug 3, 2013 at 12:14 AM, Sergey Yakoushkin < sergey.yakoushkin at gmail.com> wrote: > Hi all, > > Were there any further discussion or progress with the fixed point support > (ISO/IEC TR 18037) in the meantime? >

I am. Giorgio Il 10/08/2013 12.12, Sergey Yakoushkin ha scritto: > Hi, > > Is there anyone else interested in fixed-point arithmetic support in > clang/llvm? > > Regards, > Sergey > >

I would also be interested in fixed-point arithmetic support in clang/llvm? Is there any movement on this direction since August? Regards, Pedro Malagon -- Pedro Malagon Dpt. Electrical Engineering - Technical University of Madrid Assistant Professor Office B-113 Avda. Complutense s/n, 28040 Madrid Tel. (+34) 915495700 ext. 4220 @:malagon at die.upm.es On 08/10/2013 09:24 PM, Giorgio

FYI, we are also interested. (But our limited staff are currently busy just getting our LLVM backend out of the door (in-house only). I hope we will have time to look at this in a year or so.) Regards, Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Pedro Malagon Sent: den 3 december 2013 14:30 To: llvmdev at

Hi, I've developed editor prototype for TableGen files (td). It is Eclipse plugin based on IMP project (The IDE Meta-Tooling Platform). Editor has outline, folding, coloring, go to definition, etc. As any prototype, editor has some limitations (e.g. no cross-file indexing). If there is any interest to such tool I will improve it a bit and then publish. Also considering llvm asm (ll) editing

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

Hello Sergey, I'd be interested in such a plugin. At one time somebody else started a plugin to cause Eclipse to compile with LLVM-GCC but I hadn't heard anything else from them. I've been just modifying the commands manually for that. I have definitely not heard of a .td or .ll syntax highlighter plugin. --Sam ----- Original Message ---- > From: Sergey Yakoushkin

I tried llc with -mcpu=help and it dosn't list Sparc. Thanks. --Gang On Tue, Mar 16, 2010 at 12:43 PM, Sergey Yakoushkin < sergey.yakoushkin at gmail.com> wrote: > Hi, > > Target architecture for llc can be specified using -march, -mcpu, > -mattr options. > > Is it possible to override target CPU attributes when using llvm-gcc > compiler? > > Regards, >

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 =

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

Hi, llvm doesn't support -fno-toplevel-reorder option which affects glibc/eglibc for some targets. http://www.llvm.org/bugs/show_bug.cgi?id=6364 >From conversations with gcc and eglibc maintainers, seems option is highly expected and is not going to deprecate. >> 2010/2/23 Ian Lance Taylor <iant at google.com>: >> If option is going to deprecate in gcc in near future as

On 19 February 2011 02:42, Sergey Yakoushkin <sergey.yakoushkin at gmail.com> wrote: > I'm working on source to source transformations and instrumentation. > A flag to disable 'va_arg' lowering in LLVM FEs will be very useful. Hi, For the sake of simplicity, if types are simple, we emit va_arg directly, otherwise we do like Clang and lower it in the front-end. Would be