search for: stackpoint

...from my gc.safepoint_poll definition, I tried adding these lines: declare void @runtime_safepoint_poll(i64) declare i64 @llvm.read_register.i64(metadata) #1 !0 = !{!"rsp\00"} ; Read the stack pointer and pass it to our polling function (assumes x64) define void @gc.safepoint_poll() { %stackpointer = call i64 @llvm.read_register.i64(metadata !0) call void @runtime_safepoint_poll(i64 %stackpointer) ret void } attributes #1 = { "gc-leaf-function" nounwind readnone } Note that the target triple is x86_64-pc-windows-msvc. When I test this, the values that come from reading RSP...

...from my gc.safepoint_poll definition, I tried adding these lines: declare void @runtime_safepoint_poll(i64) declare i64 @llvm.read_register.i64(metadata) #1 !0 = !{!"rsp\00"} ; Read the stack pointer and pass it to our polling function (assumes x64) define void @gc.safepoint_poll() { %stackpointer = call i64 @llvm.read_register.i64(metadata !0) call void @runtime_safepoint_poll(i64 %stackpointer) ret void } attributes #1 = { "gc-leaf-function" nounwind readnone } Note that the target triple is x86_64-pc-windows-msvc. When I test this, the values that come from reading RSP...

...asm("mov %%esp, %0" : "=r"(esp)); \ esp; \ }) This works for both gcc and clang, but often adds in 3 extra instructions since you need to copy the stack pointer to another register, but first that register needs to be saved to the stack and then restored after the stackpointer has been used; inefficient. Another way would be to introduce a new builtin in parallel to others like __builtin_return_address(). Essentially adding a __builtin_stack_pointer() which does what the above code does. The idea would be to get something like this added to both clang and gcc in order...

...t; : "=r"(esp)); \ > esp; \ > }) > > This works for both gcc and clang, but often adds in 3 extra > instructions since you need to copy the stack pointer to another > register, but first that register needs to be saved to the stack and > then restored after the stackpointer has been used; inefficient. #define current_stack_pointer ({ \ register unsigned long esp asm("esp"); \ asm("" : "=r"(esp)); \ esp; \ }) /jakob

...>        esp; \ >>  }) >> >>  This works for both gcc and clang, but often adds in 3 extra >>  instructions since you need to copy the stack pointer to another >>  register, but first that register needs to be saved to the stack and >>  then restored after the stackpointer has been used; inefficient. > > #define current_stack_pointer ({ \ >         register unsigned long esp asm("esp"); \ >         asm("" : "=r"(esp)); \ >         esp; \ >     }) And #ifdef it for each arch? Builtin would be much more handy. -- Reg...

...emoved if they are close to a ret instruction. I suppose the idea is that the function epilogue will restore the stack pointer anyway, so the llvm.stackrestore can be safely removed. However, in my target, the stack restoration in the epilogue is currently done by adding the used stacksize to the stackpointer, so I do indeed need the call to the stackrestore intrinsic to be left. Am I breaking some design rule by reading the stackpointer in the epilogue or how is this supposed to work?

...\ >> esp; \ >> }) >> >> This works for both gcc and clang, but often adds in 3 extra >> instructions since you need to copy the stack pointer to another >> register, but first that register needs to be saved to the stack and >> then restored after the stackpointer has been used; inefficient. > #define current_stack_pointer ({ \ > register unsigned long esp asm("esp"); \ > asm("" : "=r"(esp)); \ > esp; \ > }) > > /jakob That seems to work! Though I'm still testing it in all our situations for LLV...

...gt;>> >>>> This works for both gcc and clang, but often adds in 3 extra >>>> instructions since you need to copy the stack pointer to another >>>> register, but first that register needs to be saved to the stack and >>>> then restored after the stackpointer has been used; inefficient. >>> #define current_stack_pointer ({ \ >>> register unsigned long esp asm("esp"); \ >>> asm("" : "=r"(esp)); \ >>> esp; \ >>> }) >> And #ifdef it for each arch? Bui...

...gt;> }) >>> >>> This works for both gcc and clang, but often adds in 3 extra >>> instructions since you need to copy the stack pointer to another >>> register, but first that register needs to be saved to the stack and >>> then restored after the stackpointer has been used; inefficient. >> #define current_stack_pointer ({ \ >> register unsigned long esp asm("esp"); \ >> asm("" : "=r"(esp)); \ >> esp; \ >> }) > And #ifdef it for each arch? Builtin would be much m...

...>>> }) >>> >>> This works for both gcc and clang, but often adds in 3 extra >>> instructions since you need to copy the stack pointer to another >>> register, but first that register needs to be saved to the stack and >>> then restored after the stackpointer has been used; inefficient. >> #define current_stack_pointer ({ \ >> register unsigned long esp asm("esp"); \ >> asm("" : "=r"(esp)); \ >> esp; \ >> }) >> >> /jakob > That seems to work! Though I'm still testing...

...ALTAILCALL use its operands to emit a TC_RETURN node holding stacksize, tailcallee the tc_return node would again be a pseudoop *else lower normal return When generating the epilog the two operands of the the tc_return machine instruction are used to emit code that adjust the stackpointer and jumps to the tailcallee (either label or register). Like it is done for EH_RETURN. in X86RegisterInfo.cpp we would then have TargetRegisterInfo::emitEpilogue() { ... if (RetOpcode== X86::TC_RETURN){ if (isDynamicCallee(RetOpCode)) add esp {stack adjustment from tc_return...

...;>>>> This works for both gcc and clang, but often adds in 3 extra >>>>> instructions since you need to copy the stack pointer to another >>>>> register, but first that register needs to be saved to the stack and >>>>> then restored after the stackpointer has been used; inefficient. >>>> #define current_stack_pointer ({ \ >>>> register unsigned long esp asm("esp"); \ >>>> asm("" : "=r"(esp)); \ >>>> esp; \ >>>> }) >>> And #ifd...

...a > ret instruction. I suppose the idea is that the function epilogue will > restore the stack pointer anyway, so the llvm.stackrestore can be safely > removed. > > However, in my target, the stack restoration in the epilogue is > currently done by adding the used stacksize to the stackpointer, so I do > indeed need the call to the stackrestore intrinsic to be left. > > Am I breaking some design rule by reading the stackpointer in the > epilogue or how is this supposed to work?

...>>> >>>> This works for both gcc and clang, but often adds in 3 extra >>>> instructions since you need to copy the stack pointer to another >>>> register, but first that register needs to be saved to the stack and >>>> then restored after the stackpointer has been used; inefficient. >>> #define current_stack_pointer ({ \ >>> register unsigned long esp asm("esp"); \ >>> asm("" : "=r"(esp)); \ >>> esp; \ >>> }) >>> >>> /jakob >> That seems to wo...

...have described in preceeding emails: There is new code for lowering fastcc calls: LowerX86_32FastCCCallTo LowerX86_32FastCCArguments There is some code checking whether a TAIL CALL really is eligible for tail call optimization. I modified: LowerRET to create a TC_RETURN node. (used for adjusting stackpointer and jumping to function in epilogue, similar to EH_RETURN) There is a new calling convention: CC_X86_32_TailCall which is ~ CC_X86_32_C minus ECX. There are some modifications in X86InstrInfo.td There are new X86 DAG nodes: TRUETAILCALL TC_RETURN There is some voodoo in X86RegisterInfo.cpp...

...s / disadvantages of -tail- > call-opt-align-stack? When you do tail call optimization just before calling/jmping to the callee you sometimes have to adjust the stack pointer. e.g int calller(int arg1, int arg2) { return callee(arg2, arg1, 2*arg3; } conceptually before jumping to callee the stackpointer has to be adjusted (by -4 bytes in the example). Now this can cause the stack to be misaligned (according to the target abi. In order to prevent this when calculating the argument size (and when tail-call-opt-align-stack is enabled) i make the resulting argument size a multiple of the target alig...

...+ alignment >>> NumGPRs = 3 registers >>> VARegSaveSize = 16 (after considering 8 byte alignment ) >>> >>> When the offset(#76) for the instruction, "ldr r1, [r11, #76] ; 0x4c" is calculated, 4 bytes alignment is considered. >>> In prologue stackpointer calculation 8 byte alignment is considered. >>> Due to this mimatch of alignment, If try to access any parameter after byval which results wrong value. >>> >>> Issue(or offset of 4 bytes) wont occur if even number of register used for byval spilling. >>> ex:...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/5b2a15e3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306181656803_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/5b2a15e3/attachment.gif>

Hi All, TLDR: Allow calling conventions to be defined on-the-fly for functions in LLVM-IR, comments are requested on the mechanism and syntax. Summary ======= This is a proposal for adding a mechanism by which LLVM can be used to generate code fragments adhering to an arbitrary calling convention. Intended use cases are: generating code intended to be called from the shadow of a stackmap or

...is new code for lowering fastcc calls: > LowerX86_32FastCCCallTo > LowerX86_32FastCCArguments > > There is some code checking whether a TAIL CALL really is > eligible for tail call optimization. > > I modified: > LowerRET > to create a TC_RETURN node. (used for adjusting stackpointer and > jumping to function in epilogue, similar to EH_RETURN) > > There is a new calling convention: > CC_X86_32_TailCall > which is ~ CC_X86_32_C minus ECX. > > There are some modifications in > X86InstrInfo.td > > There are new X86 DAG nodes: > TRUETAILCALL >...