On Sun, Apr 3, 2011 at 2:58 AM, David Terei <davidterei at gmail.com> wrote:> Hi Yiannis, > > As has been said GHC had this problem (I'm the author of GHC's LLVM > backend). GHC uses 4 pinned registers on x86-32 and 16 on x86-64. The > solution is to use a custom calling convention. I would argue that > this is a better solution then having the registers completely > reserved as in the middle of a function llvm can spill those registers > to free them up for temporary use. Also, if when generating code you > know that one of the pinned registers doesn't actually store anything > useful for this function then you can avoid passing it on to the next > function so that the register will be free to use during the function. > > Here is a link to the original discussion about this problem and the > solution: > > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > You should also check out the GHC calling convention as there is a > good chance you could use it to get what you want and not have to > modify llvm at all. The calling conventions for X86 are defined in > 'lib/Target/X86/X86CallingConv.td' in a very easy to read format. > > On X86-64 the arguments are passed in R13, RBP, R12, RBX, R14, RSI, > RDI, R8, R9, R15, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, in that order. > > So lets say the compiler you are trying to work with currently stores > a Sp and a Hp in %R13 and %R12 respectively. You could define your > functions like so: > > function cc 10 void f (Sp, tmp1, Hp) { > [...] > tail call g (Sp', undef, Hp'); > ret void; > } > > Cheers, > David > > Hey people,It has been some time since the last email on this topic. Since then i have successfully used your advice and implemented a custom calling convention for my backend that adheres to the runtime system's ABI. To summarize what i do: i have three virtual registers (HP, P, NSP) pinned to some physical registers by defining it in the custom calling convention. I have also defined a custom return cc in order to guarantee that the physical registers also have the correct values on exit of the function. In that way i am sure that the registers are updated both on entrance and exit and that is exactly what i want. The problem with that is the case of an 'invoke' call. According to the semantics of the invoke instruction the return value is not available when a stack unwind happens. From the Language Reference Manual: "For the purposes of the SSA form, the definition of the value returned by the 'invoke' instruction is deemed to occur on the edge from the current block to the "normal" label. If the callee unwinds then no return value is available." In that case, how can i get the values of the pinned registers, i.e. HP, P and NSP, needed in the Fail code block? Cheers, Yiannis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110708/06edb62c/attachment.html>
On 8 July 2011 21:10, Yiannis Tsiouris <yiannis.tsiouris at gmail.com> wrote:> The problem with that is the case of an 'invoke' call. According to the > semantics of the invoke instruction the return value is not available when > a stack unwind happens. From the Language Reference Manual: > "For the purposes of the SSA form, the definition of the value returned by > the 'invoke' instruction is deemed to occur on the edge from the current > block to the "normal" label. If the callee unwinds then no return value is > available." > > In that case, how can i get the values of the pinned registers, i.e. HP, P > and NSP, needed in the Fail code block?You could store them in the exception, assuming your compiler is the one generating the code that throws it...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/08/2011 10:30 PM, Frits van Bommel wrote:> On 8 July 2011 21:10, Yiannis Tsiouris <yiannis.tsiouris at gmail.com> wrote: >> The problem with that is the case of an 'invoke' call. According to the >> semantics of the invoke instruction the return value is not available when >> a stack unwind happens. From the Language Reference Manual: >> "For the purposes of the SSA form, the definition of the value returned by >> the 'invoke' instruction is deemed to occur on the edge from the current >> block to the "normal" label. If the callee unwinds then no return value is >> available." >> >> In that case, how can i get the values of the pinned registers, i.e. HP, P >> and NSP, needed in the Fail code block? > > You could store them in the exception, assuming your compiler is the > one generating the code that throws it...Hi Frits and thanks for your quick response, Can you elaborate more on this idea? How could i do that? Let me explain quickly how i handle the 'register pinning' and what is the problem in case it was not clear in the beginning (in llvm pseudocode): {i64, i64, i64, i64} @main(i64 %in_hp, i64 %in_p, i64 %in_sp) { ;; In the entry block: %hp = alloca i64 store %in_hp -> %hp %p = alloca i64 store %in_p -> %p %sp = alloca i64 store %in_sp -> %sp ...... ;; before normal call %hp1 = load %hp %p1 = load %p %sp1 = load %sp {%hp2, %p2, %nsp2, %val} = call @foo(%hp1, %p1, %sp1, arg1, arg2) ;; in normal continuation store %hp2 -> %hp store %p2 -> %p store %sp2 -> %sp ....... ....... ;; before invoke call %hp3 = load %hp %p3 = load %p %sp3 = load %sp {%hp4, %p4, %nsp4, %val} = invoke @bar(%hp3, %p3, %sp3, ...) to label %Continue unwind label %Cleanup ;; %Continue label (normal return) store %hp4 -> %hp store %p4 -> %p store %sp5 -> %sp ..... %Cleanup: ;; In this block i *cannot* access %hp4, %p4, %sp4 ..... ;; Return of main %hp5 = load %hp %p5 = load %p %sp5 = load %sp ret {%hp5, %p5, %sp5, 0} } The problem is that in the %Cleanup block i cannot perform the usual store as the virtual registers %hp4, %p4, %sp4, are not available (due to the semantics of the 'invoke' statement). Sincerely, Yiannis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJOGG/UAAoJEGQmXQvMOEBcfnAIAJeRunEO39RuGIeYCfKIseb5 O+FFdCPIi1A5+FHezQNKb3w8OX6eyD5LgFas9xy6iuYmSDAJLt557oAhJEXB5HzW zJUEJnCjwC8FZ0/s/sk7uFDsfs9Dy61MTm8OWtJf4hTc4dH3NFrn8810K6i0H48f PLyBxB3Ek4JIFzZudr9W8Jj0Bxs9s23+hwDaXMPekXS/0mv24xMKhh0wqDwo971x NzOc5knbIC5SG1Ib1Rr8y6wZcS0UUmBlkZEi3/cK4sMoMCAU7hCYXvhFGlA7Ljio VOlTEtvwwz6YCMl2ayxdYvY6UA0N1ranMCwVotenCUijgOUcNYHfhlw1DtcKMKw=boD8 -----END PGP SIGNATURE-----