similar to: [LLVMdev] i128 backend or frontend lowering

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

Most probably you need to properly specify the calling convention the backend is using for calling the runtime functions. Or implement the stub for udivti3 that performs the necessary argument lifting. I guess there is no standard ABI document describing the intended calling convention here, so I'd just do what mingw64 does here and make everything here compatible. On Thu, Apr 26, 2018 at

On Thu, Apr 26, 2018 at 3:44 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Most probably you need to properly specify the calling convention the > backend is using for calling the runtime functions. Thanks for the tip. Can you be more specific? Are you suggesting there is some config parameter I can set before running TargetMachineEmitToFile? Do you know what

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

I'm trying to use LLVM to create compiler-rt.o on Windows. I use this command from the compiler-rt project: [nix-shell:~/downloads/llvm-project/compiler-rt]$ clang -nostdlib -S -emit-llvm lib/builtins/udivti3.c -g -target x86_64-windows -DCRT_HAS_128BIT The resulting LLVM IR is: ================================================================= ; ModuleID = 'lib/builtins/udivti3.c'

I am needing to return i128 as a shadow return due to abi issues on alpha.  The problem I am running into is the code for doing that with scalars (currently only used for vectors, as far as I can tell) sets the sret on the parameter.  If I just go this path, then I am setting sret on an integer pointer, which verify objects too.  LangRef doesn't say scalars are allowed to have sret set, but

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

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: %0 = zext i32 %cl to i128 %1 = zext i32 %cl to i128 %2 = add i128 %1, %0 br label %L1001510 L1001510:

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

Hi all, Just wanted to report that I've found a second way to achieve data/code layout (the first being the linker script that Eugene mentioned). The key is that gnu as supports a feature called subsections. http://sourceware.org/binutils/docs-2.20/as/Sub_002dSections.html#Sub_002dSections The way this works is that you can put stuff into a section like '.text 2', where 2 is a

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:

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

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

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

On Aug 19, 2010, at 1:38 PM, Andrew Lenharth wrote: > I am needing to return i128 as a shadow return due to abi issues on > alpha. The problem I am running into is the code for doing that with > scalars (currently only used for vectors, as far as I can tell) sets > the sret on the parameter. If I just go this path, then I am setting > sret on an integer pointer, which verify

On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > So let me write it once more. > > I've been working for some time now on a backend for our CPU. However I > couldn't figure out how to implement some stuff. > I'd appreciate your help

On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > The llvm_ostreams, which you take the address of go out of scope very > quickly, and are only stored by address in the bytecode writer, thus > the writers have a pointer to a stack allocated object they are to > write to. This crashes. The attached version leaks :-) It is a work around. If I understand correctly,

Its good to see that a feature of this nature would be useful to a whole range of people, I wasn't aware of that. On 9 June 2010 22:40, Andrew Lenharth <andrewl at lenharth.org> wrote: > My argument amounts to express side tables as side tables in the IR > rather than as an ordering on globals.  I think that would simplify > the backend (a side table is something you discover

I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). --- On Sun, 8/2/09, Andrew Lenharth <andrewl at lenharth.org> wrote: > From: Andrew Lenharth <andrewl at

On Tue, Oct 25, 2011 at 12:20 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 25, 2011, at 9:29 AM, David A. Greene wrote: > >> Dan Gohman <gohman at apple.com> writes: >> >>> I'm removing old targets that no longer appear actively maintained, >>> to reduce the burden for target-independent codegen maintenance. >>>