similar to: [LLVMdev] Custom allocation orders

On Oct 15, 2008, at 5:29 AM, sanjiv gupta wrote: > On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: >> You need to specify sub-register == super-register, idx relationship. >> See X86RegisterInfo.td: >> >> def x86_subreg_8bit : PatLeaf<(i32 1)>; >> def x86_subreg_16bit : PatLeaf<(i32 2)>; >> def x86_subreg_32bit : PatLeaf<(i32

On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: > You need to specify sub-register == super-register, idx relationship. > See X86RegisterInfo.td: > > def x86_subreg_8bit : PatLeaf<(i32 1)>; > def x86_subreg_16bit : PatLeaf<(i32 2)>; > def x86_subreg_32bit : PatLeaf<(i32 3)>; > > def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, >

On Wed, 2008-10-15 at 10:08 -0700, Evan Cheng wrote: > On Oct 15, 2008, at 5:29 AM, sanjiv gupta wrote: > > > On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: > >> You need to specify sub-register == super-register, idx relationship. > >> See X86RegisterInfo.td: > >> > >> def x86_subreg_8bit : PatLeaf<(i32 1)>; > >> def

You need to specify sub-register == super-register, idx relationship. See X86RegisterInfo.td: def x86_subreg_8bit : PatLeaf<(i32 1)>; def x86_subreg_16bit : PatLeaf<(i32 2)>; def x86_subreg_32bit : PatLeaf<(i32 3)>; def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], [AL, CL,

On Sat, Jun 25, 2016 at 11:03 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > Hello LLVM Community, > > To improve Interprocedural Register Allocation (IPRA) we are trying to > force caller > saved registers for local functions (which has likage type local). To > achive it > I have modified TargetFrameLowering::determineCalleeSaves() to return > early for >

Hello LLVM Community, To improve Interprocedural Register Allocation (IPRA) we are trying to force caller saved registers for local functions (which has likage type local). To achive it I have modified TargetFrameLowering::determineCalleeSaves() to return early for function which satisfies if (F->hasLocalLinkage() && !F->hasAddressTaken()) and also reflecting the fact that for local

On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > Hello , > > To solve this bug locally I have given preference to tail call > optimization over local function related optimization in IPRA. I have added > following method to achieve this: > >

Sent from my iPhone > On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > >> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >>> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: >>> >>> Hello , >>> >>> To solve

> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > Hello , > > To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: > > bool isEligibleForTailCallOptimization(Function *F) { > CallingConv::ID CC =

Hello , To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: bool isEligibleForTailCallOptimization(Function *F) { CallingConv::ID CC = F->getCallingConv(); if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) return true; return false;

According to this http://llvm.org/docs/CodeGenerator.html#tail-call-section, it seems that adding a new CC for the purpose of local function optimization seems a good idea because tail call optimization only takes place when both caller and callee have fastcc or GHC or HiPE calling convention. -Vivek On Sun, Jun 26, 2016 at 1:26 AM, vivek pandya <vivekvpandya at gmail.com> wrote: >

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

I'm looking at an issue where we want a particular pseudo-instruction to choose from a set of registers that is not included in the existing set of RegisterClass definitions. More concretely, there is a RegisterClass in ARMRegisterInfo.td defined as def rGPR : RegisterClass<"ARM", [i32], 32, (sub GPR, SP, PC)> { let AltOrders = [(add LR, rGPR), (trunc rGPR, 8)]; let

You are right about your interpretation of "dead". The case here is that RSP is a reserved register and so its liveness isn't really tracked. The "implicit-def dead" is an idiom used to mean that the register (reserved or not) is clobbered. The other implicit uses/defs can come from instruction definitions to indicate that this instruction uses and/or modifies a given

While migrating my codebase from llvm-2.6 to llvm-2.7, I found a different behaviour in the register allocation. I have been able to reproduce it using the msp430 backend, with the 2.7 release as well as the svn head. For the msp430, the first four parameters of a function are passed thru registers. What I observe is that if those parameters are not used inside the function, those registers can

On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote: > > On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote: > > > What’s the value produced by an INSERT_SUBREG node? Is it a chain? > > > No, insert_subreg returns a value: > > > v1 = insert_subreg v2, v3, idx > > > v1 and v2 will have the same type, e.g. i16, and v3 must have a >

Ah, I see -- the registers left out of the mask are considered clobbered. Got it! At a high level, I'm interested in finding the locations of all values that are live at a given call site. You can think of it like a debugger, e.g. gdb -- I'd like to be able to unwind the stack, frame by frame, and locate all the live values for each function invocation (i.e., where they are in a

I have a question: In the pattern below from X86 def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), "inc{b}\tdst", [(set GR8:$dst, (add GR8:$src, 1))]>; Since we are emitting only "inc $dst", What makes sure that the $src and $dst are same register? - Sanjiv

sanjiv gupta wrote: > I have a question: > In the pattern below from X86 > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > "inc{b}\tdst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Since we are emitting only "inc $dst", > What makes sure that the $src and $dst are same register? > > - Sanjiv It's enclosed

I am working the AVR backend. It is still in the early stage. I got the following error:[ 86%] Building CXX object lib/Target/AVR/CMakeFiles/LLVMAVRCodeGen.dir/AVRISelDAGToDAG.cpp.obj AVRISelDAGToDAG.cpp C:\llvm-build\lib\Target\AVR\AVRGenDAGISel.inc(596) : error C2664: 'llvm::SDNode *llvm::SelectionDAG::SelectNodeTo(llvm::SDNode *,unsigned int,llvm::MVT,llvm::MVT,llvm::MVT,const llvm::SDValue