similar to: [LLVMdev] RFC: Tail call optimization X86

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

Begin forwarded message: > From: Evan Cheng <evan.cheng at apple.com> > Date: 11 September 2007 19:26:39 GMT+02:00 > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Tail call optimization X86 > Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > > Hi Arnold, > > Thanks for the patch. Some questions

On 24 Sep 2007, at 09:18, Evan Cheng wrote: > +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- > output-file - | grep asm-printer | grep 9 > +; change preceeding line form ... | grep 8 to ..| grep 9 since > +; with new fastcc has std call semantics causing a stack adjustment > +; after the function call > > Not sure if I understand this. Can you illustrate

The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>

Hi Arnold, This is a very good first step! Thanks! Comments below. Evan Index: test/CodeGen/X86/constant-pool-remat-0.ll =================================================================== --- test/CodeGen/X86/constant-pool-remat-0.ll (revision 42247) +++ test/CodeGen/X86/constant-pool-remat-0.ll (working copy) @@ -1,8 +1,10 @@ ; RUN: llvm-as < %s | llc -march=x86-64 | grep LCPI | count 3 ;

Okay so i implemented an(other :) initial version for X86-32 backend, this time based on TOT: It is not very generic at the moment. Only functions with callingconv::fastcc and the tail call attribute will be optimized. Maybe the next step should be to integrate the code into the other calling convention lowering. Here is what i have at the moment: If callingconv::fastcc is used the

Hello, Arnold. Only quick comments, I'll try to make a full review a little bit later. > 0.)a fast calling convention (maybe use the current > CallingConv::Fast, or create a CallingConv::TailCall) > 1.) lowering of formal arguments > like for example x86_LowerCCCArguments in stdcall mode > we need to make sure that later mentioned CALL_CLOBBERED_REG is >

On Sep 24, 2007, at 2:25 AM, Arnold Schwaighofer wrote: > > On 24 Sep 2007, at 09:18, Evan Cheng wrote: >> +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- >> output-file - | grep asm-printer | grep 9 >> +; change preceeding line form ... | grep 8 to ..| grep 9 since >> +; with new fastcc has std call semantics causing a stack adjustment >>

Hi Arnold and Anton, Sorry I have been ignoring your emails on this topic. It's an important task and I really need sometime to think about it (and talk to Chris about it!) But this has been an especially hectic week. I am also going to vacation soon so I am not sure when I would get around to it. If Chris has time, I am sure he has lots to say on this topic. :-) Otherwise, please

> > FastCC use to be caller pops arguments so there was no stack > > adjustment after the > > call to qux. Now FastCC has callee pops arguments on return semantics > > so the > > x86 backend inserts a stack adjustment after the call. > > > > _array: > > subl $12, %esp > > movss LCPI1_0, %xmm0 > > mulss

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:

Cool, that worked. New patch attached... Cheers, Gary Evan Cheng wrote: > Just cast both values to const TargetRegisterClass*. > > Evan > > On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > > Evan Cheng wrote: > > > How about? > > > > > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > > > &PPC:G8RCRegClass; >

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

I needed to be able to update stub pointers for hot functions that get recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do this I added a method that allows pointers to be updated but does not expose any of the other internals of the COD layer. Does anyone have a cleaner way to do this? Has something to facilitate this already been added? Would it be possible to merge this