similar to: [LLVMdev] Problems with custom calling convention on Mac OS X

David Terei wrote: > Hi all, > > I'm working on using LLVM as a back-end for the Haskell GHC compiler. As > part of that work I have modified LLVM to include a new custom calling > convention for performance reasons as outlined previously in a > conversation on this mailing list: > > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > This

Charles Davis wrote: > Just today I added support for a new 'alignstack' function attribute. > With it, you can force the stack to be 16-byte aligned (or n-byte > aligned, if you so desire) in your functions. This way, you can make > calls to dylibs on Mac OS X without triggering the misaligned stack error. I finally got around to properly playing around with

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

Hi Duncan, Karel, On 14 October 2011 08:22, Duncan Sands <baldrick at free.fr> wrote: > Hi Karel, > >>>> > const unsigned* >>>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >>>> const { >>>> > + bool ghcCall = false; >>>> > + >>>> > + if (MF) { >>>> > + const

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

On 15 October 2011 00:31, Duncan Sands <baldrick at free.fr> wrote: > Hi David, > >> The code above is needed as the GHC calling convention redefines what >> registers are considered callee save. No one else rummages in to the >> original function as all the other calling conventions use the same >> set of callee and caller save registers, so GHC is the only one

Hello, today is the last day[1] when someone might ask for feature merge into the LLVM 3.0 release. I'd like to ask you to merge attached patch. This is implementation of GHC calling convention on ARM platform which is made by Stephen Blackheath with few additions by me. I hope that although the patch does not contain any test case, it still will be merged. The reason for this is that

Hi David, > The code above is needed as the GHC calling convention redefines what > registers are considered callee save. No one else rummages in to the > original function as all the other calling conventions use the same > set of callee and caller save registers, so GHC is the only one that > needs to differentiate. shouldn't the caller also know what registers are callee

Hello. I found that the X86CompilationCallback_SSE wrapper for X86CompilationCallback2 is not setting up properly for the PIC invocation. Before you can correctly invoke a function via the Procedure Linkage Table (plt), the ABI mandates that ebx is pointing to the GOT (Global Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) Dump of assembler code for function

For the given test: class A1 { int x; int y; public: A1(int a, int b) { x=a; y=b; } A1 operator+(const A1&); }; A1 A1::operator+(const A1& second) { A1 sum(0,0); sum.x = x + second.x; sum.y = y + second.y; return (sum); } int main (void) { A1 one(2,3); A1 two(4,5); return 0; } when the exectable of this code is debugged in gdb for i386, we dont get the

Hello all, In r223757 I've committed a patch that performs, for the 32-bit x86 calling convention, the transformation of MOV instructions that push function arguments onto the stack into actual PUSH instructions. For example, it will transform this: subl $16, %esp movl $4, 12(%esp) movl $3, 8(%esp) movl $2, 4(%esp) movl $1, (%esp) calll _func addl $16, %esp

I found a something that I quite not understand when compiling a common piece of code using the -Os flags. I found it while testing my own backend but then I got deeper and found that at least the x86 is affected as well. This is the referred code: char pp[3]; char *scscx = pp; int tst( char i, char j, char k ) { scscx[0] = i; scscx[1] = j; scscx[2] = k; return 0; } The above gets

Problem seems not only with operator overloading, It occurs with struct value returning also. gdb while debugging expects the return value in eax, gcc does returns in eax, But Clang returns in edx(it can be checked in gdb by printing the contents of edx). Code(sample code) struct A1 { int x; int y; }; A1 sum(const A1 one, const A1 two) { A1 plus = {0,0}; plus.x = one.x + two.x; plus.y

This showed up in RISKS and no one has mentioned it here yet, so.. OpenSSH contains lots of code like: char *password = read_passphrase(prompt, 0); [do stuff] memset(password, 0, strlen(password));

All, I would like to submit the attached patch, which allows the GHC (Glasgow Haskell Compiler) calling convention to work on ARM targets. Could some nice person please review this code, so I can move towards getting it committed? I have thoroughly tested this patch again GHC on a Debian-ARM (armel) system. Unfortunately my understanding of LLVM is limited, so it's likely I'm not

I don't know how to file a PR, but I have a patch (see below), that should work regardless of abi differences, since it relies on the compiler to do the though job. void X86CompilationCallback_SSE(void) { char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned asm volatile ( "movl %%eax,(%0)\n" "movl %%edx,4(%0)\n" // Save EAX/EDX/ECX

Hi, Structures are passed by pointer, so the return value is not actually in eax. That code gets transformed into something like: void sum(A1 *out, const A1 one, const A1 two) { out->x = one.x + two.x out->y = one.y + two.y } So actually the function ends up returning void and operating on a hidden parameter, so %eax is dead at the end of the function and should not be being relied

Hi Steve, I'm not an LLVM developer but am the author/maintainer of the LLVM backend in GHC. The patch looks mostly good to me (although I am not that familiar with ARM so could easily have missed something). My main concern is why are you avoiding using the R0 - R3 registers? Also, could you please update me on the status of this work. I assume you are getting GHC running in registerised