similar to: [LLVMdev] LLVM ERROR: Cannot select error in simple i128 math?

On Fri, Aug 19, 2011 at 1:59 PM, Craig Smith <craig at ni.com> wrote: > In both LLVM 2.9 and the current svn head, I get the following error when running llc > > % llc < fxp2.ll > LLVM ERROR: Cannot select: 0xa5302b0: glue = carry_false [ID=7] > > on this code: > > target triple = "i386-pc-linux-gnu" > > define i32 @fxpadd(i32 %cl) { > entry:

Hi, Would like to run the software to monitor the quality of the bandwidth. Suggestions welcome? Thank you. Shaun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081211/85bd0069/attachment.htm

Did cvsup on a machine that does just mail processing (well, a lot of spam scanning) and it crashed not too much later. This kernel does not include MFC src/sys/kern/sys_process.c revisions 1.111 and 1.112: Use kmem_alloc_nofault() rather than kmem_alloc_pageable() in procfs_rwmem(). Use vm_page_hold() in place of vm_page_wire() since the page can be freed. Don't hold extra

Adam Jackson (3): Death to RCS tags. Fix distcheck i128 1.3.0 Alan Coopersmith (2): Replace references to XFree86/XF86Config in man page renamed: .cvsignore -> .gitignore Brice Goglin (1): Define I128_*_VERSION* using PACKAGE_VERSION_* Dave Airlie (3): i128: pciaccess conversion i128: drop ansi C wrapper i128: fixup typo Matthieu Herrb

Last-minute fix for 7.4. Adam Jackson (1): Don't store pScrn->monitor->DDC manually, let xf86SetDDCproperties do it. Julien Cristau (1): Bump to 1.3.1 Paulo Cesar Pereira de Andrade (2): Compile warning fixes. Replace calls to xf86usleep with calls to usleep and include unistd.h. git tag: xf86-video-i128-1.3.1

Hi, I have a set of new registers for x86 which I defined in X86RegisterInfo.td to be: def POI0: X86Reg<"poi0", 0>; def POI1: X86Reg<"poi1", 1>; def POI2: X86Reg<"poi2", 2>; def POI3: X86Reg<"poi3", 3>; def POI4: X86Reg<"poi4", 4>; def POI5: X86Reg<"poi5", 5>; def POI6: X86Reg<"poi6",

Hello, Dan > Does anyone know of any precedent for handling i128 in the > calling convention on x86-32? Never seen this 'in wild' (pure integer case). > I'm trying to write a testcase that returns an i128 value, > and LLVM currently has only two 32-bit GPRs designated for > returning integer values on x86-32. Can XMM registers be used for such things? -- With best

> See ix86_return_in_memory. (In 4.3 this is renamed to > return_in_memory_32.) > i128==TImode. But TImode should be used for __m128 stuff only there, not for integers. I'm looking into gfortran now. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

> Anton mentioned that Fortran uses i128 on 32-bit systems, Anton do you > know if they can be returned, and if so what ABI they use? Looks like, that warning is generated during emission of decl of __sync_fetch_and_add_16. I don't have any gcc 4.2.x+ here, so if somebody have it available on 32-bit machine - please check the stuff. -- With best regards, Anton Korobeynikov. Faculty

Hello, Andrew > Is the backend the best place to do this or should I attempt to make > llvm-gcc not generate i128 in the first place? It depends whether i128 is a native type for alpha, or not. If it's not - frontend should not generate it. If it's native type then it might be useful just to declare new regclass with virtual 'wide' registers consist of register pairs and

Hi all, I currently use LLVM 3.0 clang to compile my source code to bitcode (on a X86-64 machine) before it is later processed by a pass, like this: $ clang -m32 -O3 -S foo.c -emit-llvm -o foo.ll However, for some reason the the resulting module contains 128-bit instructions, e.g.: %6 = load i8* %arrayidx.1.i, align 1, !tbaa !0 %7 = zext i8 %6 to i128 %8 = shl nuw nsw i128 %7, 8 which the

This is a maintenance release of Number Nine Imagine 128 DDX. There was one patch that has been languishing over at Patchwork X.org website (https://patchwork.freedesktop.org/patch/122831/) for more than 2 years, so I decided to apply it, and release a new version. With that patch applied and one more small patch I authored, the DDX compiles cleanly without compilation warnings. Kevin Brace

This is the Xorg driver for Number Nine Imagine 128 (I128) video cards, which were sold in the mid-to-late 1990's for PCI & AGP bus systems. Alan Coopersmith (8): Build xz tarballs instead of bzip2 Fix spelling/wording issues gitlab CI: add a basic build test gitlab CI: stop requiring Signed-off-by in commits Handle -Wunused-const-variable warnings

I think it's returned in 4 registers: eax, edx, esi, edi. Can someone confirm? Evan On Feb 27, 2008, at 8:33 AM, gohman at apple.com wrote: > Hello, > > Does anyone know of any precedent for handling i128 in the > calling convention on x86-32? I'm trying to write a testcase > that returns an i128 value, and LLVM currently has only two > 32-bit GPRs designated for

I am seeing i128 from llvm-gcc on Alpha.  I know the calling convention for them, they are split into two registers, but I don't know if that should be handled in the frontend or the backend.  I would just as soon do it in the backend, but I didn't see any support in the new calling convention work for automatically splitting an argument into multiple registers. Is the backend the best

Hi everyone! Here, I have a question and am curious about i128. I want to know how the LLVM handle i128, because many compiler backend doesn't support i128 directly. So I am very curious and want to how the llvm handle this situation? Besides i128, such as i256, i512, even i24? Thanks. Best Regards Wu Zhao -------------- next part -------------- An HTML attachment was scrubbed...

Hello, Does anyone know of any precedent for handling i128 in the calling convention on x86-32? I'm trying to write a testcase that returns an i128 value, and LLVM currently has only two 32-bit GPRs designated for returning integer values on x86-32. Dan

For 64-bit X86 code we have had good success with using up-to 128-bit integers (this includes say 36-bit or even 2-bit integers). On Mon, Feb 2, 2015 at 4:03 PM, Alejandro Velasco <gollumdelperdiguero at gmail.com> wrote: > I asked a similar question last year here. Operations on types iN with no > direct translation into one assembly instruction seem to be translated into >

Hi, SystemZ supports @llvm.ctlz.i64() natively with a single instruction (FLOGR), and lesser bitwidth versions of the intrinsic are promoted to i64. For some reason, this leads to unfolded additions of constants as shown below: This function: define i16 @fun(i16 %arg) {   %1 = tail call i16 @llvm.ctlz.i16(i16 %arg, i1 false)   ret i16 %1 } ,gives this optimized DAG as input to instruction

Hi all, I've been working on a backend of our architecture and noticed llvm performs following combining although one of operands is FrameIndex. Combining: t114: i64 = add FrameIndex:i64<0>, Constant:i64<56> Creating new node: t121: i64 = or FrameIndex:i64<0>, Constant:i64<56> ... into: t121: i64 = or FrameIndex:i64<0>, Constant:i64<56> This