similar to: [LLVMdev] llvm register reload/spilling around calls

On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > So I saw that the code is doing lots of register spilling/reloading. Now > I understand that due to calling conventions, there's not really a way > to avoid this - I tried using coldcc but apparently the backend doesn't > implement it and hence this is ignored. Yes, unfortunately the list of call-clobbered registers is

Thanks for giving it a look! On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > >> So I saw that the code is doing lots of register >> spilling/reloading. Now I understand that due to calling >> conventions, there's not really a way to avoid this - I tried using >> coldcc but apparently the backend

On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > Thanks for giving it a look! > > On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >> >>> So I saw that the code is doing lots of register >>> spilling/reloading. Now I understand that due to calling >>> conventions, there's not

On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > >> Thanks for giving it a look! >> >> On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >>> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >>> >>>> So I saw that the code is doing lots of register >>>>

(repost with right sender address) On 20.10.2010 18:13, Jakob Stoklund Olesen wrote: > On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > >> On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >>> Look in X86InstrControl.td. The call instructions are all prefixed >>> by: >>> >>> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1,

On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >> Look in X86InstrControl.td. The call instructions are all prefixed >> by: >> >> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >> XMM0, XMM1, XMM2, XMM3,

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

Hi Matthias, No. I want the register allocator to spill the super-register (the large one e.g., 64-bit) and not just the sub-register (e.g., the 32-bit that is a piece of of the 64-bit register) because the stack loads/store width is 64-bit in this example. RegClass1 (sub-registers): sub_registers (32-bit) --> can be natively used in arithmetic operations but no stack

Hi Quentin, Let me clarify if I understood this correctly. If the accesses (writes and reads) to sub-registers are expressed always as sub-registers of the super-register register class (e.g., SuperReg.sub1;), then the spilling decision is for the super register. But, if the accesses are in terms of the register class of the sub-registers directly (SubReg;), then the spilling decision will

Hi Ahmed, If you access your values with sub-registers indices, IIRC the inline spiller will spill the super register. If you access your values directly (via sub-regclass), then the spiller uses this class. Basically what I am saying is the spiller spills the value that contains the accesses. E.g., = v; will spill v = v.sub1; will spill v too, but v is a super register in that case. Cheers,

Right Matthias, I am aware that an implementation for storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these functions receive the physical register that need to be spilled, they might receive the sub-register. In this case, using the super-register naively is unsafe (e.g., one might overwrite parts of it). Thus, I think the register allocator/spillar need to be aware of the

I still think my answer applies that you have to modify storeRegToStackSlot()/loadRegFromStackSlot(). They decide how registers are spilled and reloaded. Nobody is stopping you from using super registers spills/reloads to implement spilling/reloading smaller registers there. - Matthias > On Jan 30, 2018, at 10:21 AM, ahmede <ahmede at ece.ubc.ca> wrote: > > Hi Quentin, > >

To make my point clear, I believe an implementation of storeRegToStackSlot()/loadRegFromStackSlot() is not sufficient (as it received the physical register already). Does this make sense? On 2018-01-30 13:33, ahmede wrote: > Right Matthias, I am aware that an implementation for > storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these > functions receive the physical

On Oct 20, 2010, at 11:53 AM, Dan Gohman wrote: > > On Oct 19, 2010, at 8:00 PM, Jakob Stoklund Olesen wrote: >> >> >> One problem is that calling conventions are handled while building the selection DAG, and the DAG doesn't really know to represent clobbered registers. >> >> Perhaps X86TargetLowering::LowerCall() could decorate the X86ISD::CALL node

> The simplest way would probably be to add separate X86ISD opcodes for > each desired set of call-clobbered registers. Sounds really gross... Maybe it will be better just to teach codegen to query single place for the set of call-clobbered registers? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Fernando, --- Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to > having register to reload spilled values. Ok. That I can follow. > Once a register is spilled, its live range is split into smaller > pieces. These pieces most be contained into registers, and

Ok, thanks. Except the question was meant slightly different. Less w.r.t. organizing the register classes, and more w.r.t. implementation. I've noticed for instance that when trying to model this straight forwardly by writing a vreg from spills and reading this from fills (not further elaborated here), that the spiller can't handle vreg def-use pairs: there are assertions making sure a

On Oct 19, 2010, at 8:00 PM, Jakob Stoklund Olesen wrote: > > > One problem is that calling conventions are handled while building the selection DAG, and the DAG doesn't really know to represent clobbered registers. > > Perhaps X86TargetLowering::LowerCall() could decorate the X86ISD::CALL node with the calling convention somehow? > > Dan, do you have any thoughts on

Hi Evan, I have a few questions about current implementation of live intervals spilling, which is required for the implementation of Extended Linear Scan algorithm. --- Evan Cheng <evan.cheng at apple.com> wrote: > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > >>> Evan, > >>> >