search for: prolog_label

...restore them only for llvm.eh.return() but this will not compile. viz unwind-dw2.c will report: BB#0: derived from LLVM BB %entry Live Ins: %R0 %R0 %R1 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %LR %R0 %R1 ENTSP_lu6 120, %SP<imp-def>, %SP<imp-use>, %LR<imp-use,kill> PROLOG_LABEL <MCSym=.Ltmp68> PROLOG_LABEL <MCSym=.Ltmp69> STWSP_lru6 %R0<kill>, 119, %SP<imp-use> PROLOG_LABEL <MCSym=.Ltmp59> STWSP_lru6 %R1<kill>, 118, %SP<imp-use> PROLOG_LABEL <MCSym=.Ltmp60> STWSP_lru6 %R4<ki...

...Create(STy, Function::InternalLinkage, "" ... Here is the log of machine instructions before and after emitEpilogue for this function: * PEI::insertPrologEpilogCode: === >> before emitEpilogue - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> - insn: PROLOG_LABEL <MCSym=.Ltmp2> - insn: %RBP<def> = MOV64rr %RSP - insn: PROLOG_LABEL <MCSym=.Ltmp3> - insn: %RDI<def> = MOV64ri64i32 60910096 - insn: %RAX<def> = MOV64ri <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> - insn: TCRETURNri64 %RAX<kill>, 0, %RDI...

I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: _main: pushq %rbp Ltmp18: movq %rsp, %rbp Ltmp19: subq $320, %rsp Ltmp20: movl %ecx, -276(%rbp) I've tracked them back to emitPrologue in X86RegisterInfo.cpp. I'm wonder what's their purpose? They're filling up my symbol table... Cameron Esfahani

On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: > > _main: > pushq %rbp > Ltmp18: > movq %rsp, %rbp > Ltmp19: > subq $320, %rsp > Ltmp20: > movl %ecx, -276(%rbp) > > I've tracked them back to emitPrologue in

On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: >> >> _main: >> pushq %rbp >> Ltmp18: >> movq %rsp, %rbp >> Ltmp19: >> subq $320, %rsp >>

I don't see any references to them, that's why I brought it up... On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: >> >> _main: >> pushq %rbp >> Ltmp18:

On Aug 3, 2010, at 3:19 PM, Cameron Esfahani wrote: > I don't see any references to them, that's why I brought it up... Interesting. Is this COFF? We may not emit the final debug info, but leave the ranges in. If they're filling up your symbol table then we likely need another type of assembler label for "COFF internal". -eric

Is there any reason why we couldn't skip emitting temporary labels in the COFF writer? I tried that and everything looks okay... On Aug 3, 2010, at 3:21 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:19 PM, Cameron Esfahani wrote: > >> I don't see any references to them, that's why I brought it up... > > Interesting. Is this COFF? We may not emit the

On Aug 26, 2010, at 12:59 PMPDT, Eric Christopher wrote: > On Aug 26, 2010, at 12:25 PM, Yuri wrote: >> On 08/26/2010 11:53, Eric Christopher wrote: >>> Could you get it to print out the instruction when it happens? >>> (just change the line above the error message to print it out to >>> errs()). >>> >>> It basically means that a pseudo

...rnalLinkage, "" ... > > Here is the log of machine instructions before and after > emitEpilogue for this function: > * PEI::insertPrologEpilogCode: === >> before emitEpilogue > - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> > - insn: PROLOG_LABEL <MCSym=.Ltmp2> > - insn: %RBP<def> = MOV64rr %RSP > - insn: PROLOG_LABEL <MCSym=.Ltmp3> > - insn: %RDI<def> = MOV64ri64i32 60910096 > - insn: %RAX<def> = MOV64ri > <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> > - insn: TCRETURNri64 %RAX...

..."" ... >> >> Here is the log of machine instructions before and after emitEpilogue for this function: >> * PEI::insertPrologEpilogCode: === >> before emitEpilogue >> - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> >> - insn: PROLOG_LABEL <MCSym=.Ltmp2> >> - insn: %RBP<def> = MOV64rr %RSP >> - insn: PROLOG_LABEL <MCSym=.Ltmp3> >> - insn: %RDI<def> = MOV64ri64i32 60910096 >> - insn: %RAX<def> = MOV64ri <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> >> - insn: TCRETURNr...

...ver the instructions has to explicitly check for them to make sure they don't affect optimization. We already have to do that for debug_value instructions, and it's really unpleasant and error prone. How many passes are there this late in chain ? In any case, they all know how to deal with PROLOG_LABEL anyway. Personally, I'd like to make dwarf writer free of MachineModuleInfo. - Devang

...1] %LR<def> = LD %SP, 44; mem:LD4[FixedStack0] (LR is the Return address register) the whole code of print-machineinstrs are: # After PrologEpilogCodeInserter: # Machine code for function L_mpy_ls: Post SSA BB#0: derived from LLVM BB %0 Live Ins: %LR %S1 %S0 %SP<def> = ADDI %SP, -48 PROLOG_LABEL <MCSym=_tmp0> ST %LR<kill>, %SP, 44; mem:ST4[FixedStack0] ST %S1<kill>, %SP, 40; mem:ST4[FixedStack1] ST %S0<kill>, %SP, 36; mem:ST4[FixedStack2] PROLOG_LABEL <MCSym=_tmp1> %S0<def> = LD %SP, 48; mem:LD4[FixedStack-1](align=8) ST %S0, %SP, 0; mem:ST4[FixedStack-4...

...for function PointToHPoint: Frame Objects: fi#-1: size=48, align=8, fixed, at location [SP+8] fi#0: size=32, align=8, at location [SP-32] Function Live Ins: %A0 in %vreg0, %A2 in %vreg1, %A3 in %vreg2 BB#0: derived from LLVM BB %entry Live Ins: %A0 %A2 %A3 %SP<def> = ADDiu %SP, -32 PROLOG_LABEL <MCSym=$tmp0> SW %A3<kill>, %SP, 44; mem:ST4[FixedStack-1+4] SW %A2<kill>, %SP, 40; mem:ST4[FixedStack-1](align=8) %D0<def> = LDC1 %SP, 40; mem:LD8[%x2] The frame index operands of the first two stores and the fourth load have been lowered to real addresses. Since the f...

...function main: Post SSA Frame Objects: fi#0: size=1024, align=4, at location [SP-1024] fi#1: size=1024, align=4, at location [SP-2048] BB#0: derived from LLVM BB %entry %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup PROLOG_LABEL <MCSym=.Ltmp0> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead> RET # End machine code for function main. Let's see what happens if we...

...gt; Frame Objects: > fi#0: size=1024, align=4, at location [SP-1024] > fi#1: size=1024, align=4, at location [SP-2048] > > BB#0: derived from LLVM BB %entry > %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup > PROLOG_LABEL <MCSym=.Ltmp0> > CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> > %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead> > RET > > # End machine code for function main. > > >...

...0: size=1024, align=4, at location [SP-1024] >> fi#1: size=1024, align=4, at location [SP-2048] >> >> BB#0: derived from LLVM BB %entry >> %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, >> %EFLAGS<imp-def,dead>; flags: FrameSetup >> PROLOG_LABEL <MCSym=.Ltmp0> >> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> >> %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead> >> RET >> >> # End machine code for function main...

...ects: > fi#-1: size=48, align=8, fixed, at location [SP+8] > fi#0: size=32, align=8, at location [SP-32] > Function Live Ins: %A0 in %vreg0, %A2 in %vreg1, %A3 in %vreg2 > > BB#0: derived from LLVM BB %entry > Live Ins: %A0 %A2 %A3 > %SP<def> = ADDiu %SP, -32 > PROLOG_LABEL <MCSym=$tmp0> > SW %A3<kill>, %SP, 44; mem:ST4[FixedStack-1+4] > SW %A2<kill>, %SP, 40; mem:ST4[FixedStack-1](align=8) > %D0<def> = LDC1 %SP, 40; mem:LD8[%x2] > > > The frame index operands of the first two stores and the fourth load > have been low...

...37 >> > It seems wrong that TCRETURNri64 is created in > X86RegisterInfo::emitPrologue even when RET instruction is already > there. This seems to be a bug. I don't think I believe this; emitPrologue should not be generating a TCRETURN at all, and line 1037 is generating a PROLOG_LABEL. Why do you say it's a TCRETURN? The way this is supposed to work: SelectBasicBlock calls visit on the Call instruction, leading to visitCall: which winds up in X86TargetLowering::LowerCall: which generates the TCRETURN and sets the isTailCall argument to True which causes the loop in S...

...fixed, at location [SP+8] >>  fi#0: size=32, align=8, at location [SP-32] >> Function Live Ins: %A0 in %vreg0, %A2 in %vreg1, %A3 in %vreg2 >> >> BB#0: derived from LLVM BB %entry >>    Live Ins: %A0 %A2 %A3 >>       %SP<def> = ADDiu %SP, -32 >>       PROLOG_LABEL <MCSym=$tmp0> >>       SW %A3<kill>, %SP, 44; mem:ST4[FixedStack-1+4] >>       SW %A2<kill>, %SP, 40; mem:ST4[FixedStack-1](align=8) >>       %D0<def> = LDC1 %SP, 40; mem:LD8[%x2] >> >> >> The frame index operands of the first two stores a...