similar to: [LLVMdev] PR 5723

On Tuesday 08 December 2009 14:00, David Greene wrote: > I just filed PR 5723. This is a rather serious bug for us, > causing all sorts of problems in creating dynamically-linked > C++ programs due to the C++ runtime containing lots of leaf-like > routines that use thread-local storage. > > I can imagine a number of hackish workarounds, but I think probably > the right way to

On Tuesday 08 December 2009 14:43, David Greene wrote: > On Tuesday 08 December 2009 14:00, David Greene wrote: > > I just filed PR 5723. This is a rather serious bug for us, > > causing all sorts of problems in creating dynamically-linked > > C++ programs due to the C++ runtime containing lots of leaf-like > > routines that use thread-local storage. > > > >

Hello, David > For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or > ADJCALLSTACKDOWN64 in this case.  So is CALLSEQ_START expected > to appear only once (at the top of the function)?  The comments > are rather confusing.  It seems like CALLSEQ_START is supposed > to appear before every call, but surely there's only one stack > adjustment in the final code. Right.

On Tuesday 08 December 2009 15:53, Anton Korobeynikov wrote: > Hello, David > > > For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or > > ADJCALLSTACKDOWN64 in this case.  So is CALLSEQ_START expected > > to appear only once (at the top of the function)?  The comments > > are rather confusing.  It seems like CALLSEQ_START is supposed > > to appear before

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

Hello, I am trying to add an instruction before each function call to add/ subtract the stack pointer by a value specified at the command line. I wonder if I can do that during lowering. For example, in X86TargetLowering::LowerCALL. I appreciate it if you give me some hints how and where I can do that. Thank you, Babak

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

Hello, David > Ah, ok. I think I know what I have to do. I'll put callseq_start/end nodes > around the TLS addressing. Don't do that (tm) I'm testing the fix. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

Hi, During isel lowering, the backend insertes CALLSEQ_START / CALLSEQ_END target independent nodes to the DAG. These are then selected to X86 specific instructions ADJCALLSTACKDOWN / ADJCALLSTACKUP. At these point, they have a constant arguments which corresponds to the fixed frame size for argument passing. But the size of the stack frame isn't finalized until frame layout has

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof

On Wednesday 09 December 2009 10:21, David Greene wrote: > > You might want to look into TLS lowering code inside > > X86ISelLowering.cpp to introduce yourself into this this. > > I looked at that but it's not very helpful. It just creates some generic > instructions that get emitted as a code sequence. It doesn't say anything > about the stack frame. Ah, ok. I

On Wednesday 09 December 2009 12:30, Anton Korobeynikov wrote: > Hello, David > > > Ah, ok. I think I know what I have to do. I'll put callseq_start/end > > nodes around the TLS addressing. > > Don't do that (tm) Why not? > I'm testing the fix. Ok, I'll try to "mark noredzone" thing and see if that works.

Consider this example: --- ex.ll --- declare void @bar() ; Function Attrs: nounwind optsize define void @main() { entry: %hin = alloca [256 x i32], align 4 %xin = alloca [256 x i32], align 4 call void @bar() ret void } ------------- Freshly built llc: llc -O2 -march=x86 < ex.ll -print-before-all # *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***: #

Sure, I've attached it to the bug report. Direct link is here: https://llvm.org/bugs/attachment.cgi?id=16840 - Elliot "llvm-dev" <llvm-dev-bounces at lists.llvm.org> wrote on 2016/07/29 03:46:41 PM: > From: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Date: 2016/07/29 03:46 PM > Subject: Re: [llvm-dev]

Hi, I am working on a new target, and would like to save the caller-saved regs at the call-site. I have used the ADJCALLSTACKDOWN / UP pseudo-instructions, and my idea was to eliminate these, and in doing this using the RegScavenger to find the caller-saved live regs, and the push / pop these. I find that there are no such regs actually live there. It seems that these registers are somehow

The code has changed a lot over the years. Looks like at some point of time the assumption was broken. calculateCallsInformation() may have eliminated the pseudo set up instructions already. // If call frames are not being included as part of the stack frame, and

Thanks, I'll look into that. Still, the case where the function does not call anything remains---in such a situation there are no ADJCALLSTACK pseudos, so regardless of what that function you pointed at does, there won't be any target-independent information about the SP adjustment by the time the frame index elimination runs. Would it make sense to have ADJCALLSTACK pseudos every

Hi, My understanding of a "dead" register is a def that is never used. However, when I dump the MI after reg alloc on a simple program I see the following sequence: ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp CALL64pcrel32 @foo, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx %r12 %r13 %r14