similar to: [LLVMdev] Clarification about callee saved regs and MachineRegisterInfo::isPhyRegUsed

Hi llvmdev, I'm trying to figure how llvm remembers stack slots allotted to callee saved registers on x86. In particular, llvm pushes registers in decreasing order of FrameIdxs [1], so the offsets they get (as returned by MFI->getObjectOffset) don't directly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF

On my (out-of-tree) target I have 16 128-bit registers. Unaligned load/store are illegal. (must 16-bytes aligned) 8 of those registers are defined as callee-saved and 8 caller-saved. The default stack size is 4 bytes. The target implements dynamic stack realign to make sure the stack will always be aligned correctly when necessary. Yet I am still getting unaligned load/store when running this

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:26:30 PM > Subject: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > > > On my (out-of-tree) target I have 16 128-bit registers. >

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Francois Pichet" <pichet2000 at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:45:53 PM > Subject: Re: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > ----- Original

On 31.5.2014 2:04, Pasi Parviainen wrote: > On 28.5.2014 2:57, Sanjoy Das wrote: >> Hi llvmdev, >> >> I'm trying to figure how llvm remembers stack slots allotted to callee >> saved registers on x86. In particular, llvm pushes registers in >> decreasing order of FrameIdxs [1], so the offsets they get (as >> returned by MFI->getObjectOffset) don't

BTW I managed to get around this problem by flagging all the 128-bit registers as caller saved only. On my system, vector registers are more likely to be used on leaf functions anyway. On Thu, Nov 21, 2013 at 3:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Hal Finkel" <hfinkel at anl.gov> > > To: "Francois

> That is irrelevant. The PEI code needs to know how much stack space is > required for each call to allocate and align the stack frame properly. It > gets this info from the ADJCALLSTACK instructions. I see. Looking at PEI::calculateCalleeSavedRegisters shows that the ADJCALLSTACK instructions is used to set up MaxCallFrameSize. Adding debug prints also show that in the example code

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chad Rosier" <mcrosier at codeaurora.org>, "Jakob Stoklund Olesen" <jolesen at apple.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, November

Hi Evan, Thanks for your feedback! 2009/1/7 Evan Cheng <evan.cheng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > > > As you can see, PrologEpilogInserter has inserted at the beginning > of the function some code for manipulation of the frame pointer and > this inserted code uses the LR register. > As far as I understand,

Hi, I'm working on the iterated register coalescing graph coloring allocator and try to test it with all backends available currently in LLVM. Initial tests with most of the backends are successful. It turned out that my allocator triggers a specific assertion in the RegScavenger and only for the ARM target. It looks like the LR register is used for frame pointer related things, but it is

This looks like a bar in ARMInstrInfo.td: BX_RET should be marked with Uses = [LR] since it uses LR. However, this won't work if there is a call BL before the BX_RET. BL is marked as if it implicitly define LR. So we'll end up with this (hello world example): Live Ins: %LR %R7 %SP<def> = SUBri %SP<kill>, 8, 14, %reg0, %reg0 STR %LR<kill>, %SP,

On Jan 9, 2009, at 11:37 AMPST, Evan Cheng wrote: > This looks like a bar in ARMInstrInfo.td: > > BX_RET should be marked with Uses = [LR] since it uses LR. However, > this won't work if there is a call BL before the BX_RET. BL is marked > as if it implicitly define LR. So we'll end up with this (hello world > example): PPC has the call (BL) marked with Defs=LR and the

2009/1/13 Evan Cheng <echeng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0]

Hello, I think I've found a bug in the calling convention support for X86-64/ Win64. It doesn't correctly save and restore the XMM registers in the function prolog/epilog. (The problem only exists on Win64, since Linux and Mac OS use calling convention in which these registers are volatile and not callee-saved.) X86RegisterInfo::getCalleeSavedRegs() when called for a Win64

On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > > > As you can see, PrologEpilogInserter has inserted at the beginning > of the function some code for manipulation of the frame pointer and > this inserted code uses the LR register. > As far as I understand, ARMRegisterInfo.td should exclude the LR > register from the set of allocatable registers for functions that

On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: > Predecessors according to CFG: 0x8fdac90 (#0) > %R0<def> = MOVi 0, 14, %reg0, %reg0 > *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) > [0x8fc2d68 + 0] > %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 >

Hi again, 2009/1/13 Evan Cheng <evan.cheng at apple.com>: > > > On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com> > wrote: > >> 2009/1/13 Evan Cheng <echeng at apple.com>: >>> >>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >>> >>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:

First, thanks very much for your comments! On Sat, Feb 28, 2009 at 8:05 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 26, 2009, at 2:02 PM, John Mosby wrote: > > It is limited to X86 presently since that is the only target I have > > access to at the moment. > > What part of this is target dependent? Is this due to emitPrologue / > emitEpilogue being

On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com > wrote: > 2009/1/13 Evan Cheng <echeng at apple.com>: >> >> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >> >>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>> Predecessors according to CFG: 0x8fdac90 (#0) >>> %R0<def> = MOVi 0, 14, %reg0,

Hi (Adding the list back in). On 1 August 2013 08:44, Liu Xin <navy.xliu at gmail.com> wrote: > i know where to calculate CSRs. the additional stack space is calculated in > PEI::calculateCalleeSavedRegisters. the real instructions are inserted in > insertCSRSpillsAndRestores. > my point is why llvm code honor 'naked' but does not 'noreturn' for CSR. And to me