similar to: [LLVMdev] Fixed-point arithmetic

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

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

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 all, Is there any ongoing work in LLVM/Clang to support fixed-point arithmetic as described in ISO/IEC TR 18037 ? It seems that gcc has support for it since 2007 and it would be useful for us to add such support. Just to get an idea if we decide to work on this, how long would it take to get it implemented ? Regards, Ivan

On Wed, Feb 8, 2012 at 3:39 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi all, > > Is there any ongoing work in LLVM/Clang to support fixed-point > arithmetic as described in ISO/IEC TR 18037 ? No. > It seems that gcc has support for it since 2007 and it would be useful > for us to add such support. > Just to get an idea if we decide to work on this, how long

Hi Michele, Are you considering nested address spaces? Apart from OpenCL, named address spaces have been proposed in scope of "Embedded C" draft N1275 (2007). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf --> Section 5.2: Named address spaces and named-register storage classes Summarizing, address spaces may overlap in a nested fashion. Typically their names are

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

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

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

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

On 21 Apr 2016, at 17:44, Sergey Yakoushkin <sergey.yakoushkin at gmail.com<mailto:sergey.yakoushkin at gmail.com>> wrote: Hi Kristof, The way we use LNT, we would run different configuration (e.g. -O3 vs -Os) as different "machines" in LNT's model. O2/O3 is indeed bad example. We're also using different machines for Os/O3 - such parameters apply to all

Hi, Are there any plans (ongoing works) to implement hazards recognizers for in-order x86 processors (e.g. Atom)? Regards, Sergey Yakoushkin

Hi David, I'm working on source to source transformations and instrumentation. A flag to disable 'va_arg' lowering in LLVM FEs will be very useful. Have you sent your modifications upstream to LLVM? If not, could you please share link to your public repository. Thanks, Sergey Yakoushkin On Mon, Jul 19, 2010 at 11:18 PM, David Meyer <pdox at google.com> wrote: > Neal, >

On 2010-02-21 23:36, Sergey Yakoushkin wrote: > Hi, Rafael > > Inlined asm markup inside functions and on the top level is used to > split asm prologue/epilogue parts in very fine-grained manner. > So, splitting source c won't give the same result. You could have 2 files: - 1 which contains the function, and a marker where prolog ends (beginning of file is implicit marker of

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 22 Apr 2016, at 11:14, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: On Apr 22, 2016, at 12:45 AM, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 21 Apr 2016, at 17:44, Sergey Yakoushkin <sergey.yakoushkin at gmail.com<mailto:sergey.yakoushkin at gmail.com>> wrote: Hi

Hi all, I'm new to Clang and LLVM and I'd like to use them on Win 8 with Code::Blocks. I'm having problems in running cmake. I did the following: * Installed cmake * installed Code::Blocks * Installed python (cmake was complaining if it was not installed) * Dowloaded sources fron svn (LLVM, clang, compilre-rt and test-suite. When I run cmake I got The following error: