similar to: [LLVMdev] CDECL Calling Convention

I'm trying to understand the LLVM calling conventions. Coming from a Windows C++ background, I'm familiar with three calling conventions: cdecl, stdcall, and fastcall. It looks like cdecl corresponds to ccc in LLVM, but I'm not sure about the other two. Best Regards, Jon

On Mar 2, 2010, at 5:33 PM, David Terei wrote: > Hi all, > > As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Nice, > The GHC developers would love to get this included in LLVM so that we don't need to

OK, new patch attached. Hopefully in time for 2.7. Chris Lattner wrote: > 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold. No its intended to be supported on any platforms that GHC is supported on, which is just x86 and SPARC at the moment. At the moment I've just done X86, will

Hi all, As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Breakdown: 1) Need actual calling convention Touches: - include/llvm/CallingConv.h - lib/Target/X86/X86CallingConv.td 2) Handling new calling

Hi, I'm trying to load a dynamic link library and it seems to work (is.loaded -> TRUE). When I run the function, which calls the .Fortran subroutine, R crashes! I'v tried the same in S-Plus 2000 and it worked. Therefore I suppose that the dll has been compiled with the stdcall calling convention (and not cdecl). But the problem is that I don't have access to the source code,

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.

What is the correct procedure for translating a function signature from a high-order language to LLVM? It looks like I replace each struct/array parameter with a 'byval' pointer parameter, and I replace a result struct/array with an 'sret' pointer parameter. The reason I ask is that each calling convention has subtle variations for each architecture and platform. For

Hi Duncan, > const unsigned* > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) const { > + bool ghcCall = false; > + > + if (MF) { > + const Function *F = MF->getFunction(); > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); > + } > This bit looks dubious. Why do you need to do it? What exactly? We need

Hello > I don't know. I feel reluctant to generate different IRs for Win32 and > for Win64. Unfortunately, you should. Think about differences and between _Complex type and struct {double, double}. >From LLVM's point of view these are same types, however many ABIs have special rules for passing / returning _Complex, this is possible to handle in frontend only. > Since the C

Hi Duncan, On 10/14/11 03:56 PM, Duncan Sands wrote: > Hi Karel, > >> > const unsigned* >> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >> const { >> > + bool ghcCall = false; >> > + >> > + if (MF) { >> > + const Function *F = MF->getFunction(); >> > + ghcCall = (F ? F->getCallingConv() ==

Hi Karel, >>> > const unsigned* >>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >>> const { >>> > + bool ghcCall = false; >>> > + >>> > + if (MF) { >>> > + const Function *F = MF->getFunction(); >>> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false);

Hi Karel, > > const unsigned* > > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) const { > > + bool ghcCall = false; > > + > > + if (MF) { > > + const Function *F = MF->getFunction(); > > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); > > + } > > > This bit looks dubious. Why do you

This patch (and the others that will follow) are rebased on svn r155440: "AVX2: The BLENDPW instruction selects between vectors of v16i16 using an i8 immediate. We can't use it here because the shuffle code does not check that the lower part of the word is identical to the upper part" Patch 1/3: The attached commits add a new calling convention to support the LLVM backend for

On Mon, Sep 15, 2008 at 4:51 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > With my backend code gen I want to assign calling parameters to a list of > registers, but since I'm targeting a virtual instruction set. I don't want > to be limited by the number of registers. Is there a way using TableGen to > specify just a starting register to assign to for the

Hi Jon, > What is the correct procedure for translating a function signature from > a high-order language to LLVM? you have to do it carefully so that LLVM will end up producing object code that conforms to the platform ABI. For example, suppose you are using cdecl with a small struct (a pair of ints, say). Then your function should get two integer parameters, which LLVM will assign to

With my backend code gen I want to assign calling parameters to a list of registers, but since I'm targeting a virtual instruction set. I don't want to be limited by the number of registers. Is there a way using TableGen to specify just a starting register to assign to for the CallingConv class and then have it just use sequential registers? Micah Villmow Systems Engineer Advanced

On 04/24/12 17:10, Yiannis Tsiouris wrote: > This patch (and the others that will follow) are rebased on svn r155440: > > "AVX2: The BLENDPW instruction selects between vectors of v16i16 using an i8 > immediate. We can't use it here because the shuffle code does not check that > the lower part of the word is identical to the upper part" > > Patch 1/3: >

On Tue, Jun 21, 2016 at 12:31 AM, Matthias Braun <matze at braunis.de> wrote: > I just discussed this with vivek on IRC (and I think we agreed on this): > > Let me first state the motivation clearly to ease later discussions: > As far as the motivation for this change goes: Changing the calling > convention allows us to choose whether a register is saved by the callee or >

Hi Kostis, Just to check, did you send the patch originally to llvmdev or llvm-commits? The latter is where all commit review takes place. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kostis Sagonas Sent: 02 May 2012 13:16 To: llvmdev at cs.uiuc.edu Cc: erllvm at softlab.ntua.gr Subject: Re: [LLVMdev] RFC: