Re: Allow more PowerPC sibling calls
On Fri, Apr 22, 2011 at 01:29:14PM +0930, Alan Modra wrote: > On Mon, Apr 18, 2011 at 10:29:17AM -0700, Nathan Froyd wrote: > > Could I request that you use FOREACH_FUNCTION_ARGS in these two cases? > > The conversion is trivial, and avoiding more exposed TYPE_ARG_TYPES > > calls is a good thing. > > Committed revision 172855. Oops, I missed the following hunk, which I talked about here > I also fixed a minor problem with CALL_LIBCALL in the call > cookie, which could cause various call insns to match an "n" > constraint rather than a "0" constraint and so give the wrong insn > length. and mentioned in the changelog: > * config/rs6000/rs6000.c (rs6000_function_arg): Remove CALL_LIBCALL > when returning call_cookie. but failed to include in my post. Committed as obvious, revision 172856. Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 172855) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -9007,7 +9007,7 @@ rs6000_function_arg (CUMULATIVE_ARGS *cu : CALL_V4_CLEAR_FP_ARGS)); } - return GEN_INT (cum->call_cookie); + return GEN_INT (cum->call_cookie & ~CALL_LIBCALL); } if (TARGET_MACHO && rs6000_darwin64_struct_check_p (mode, type)) -- Alan Modra Australia Development Lab, IBM
Re: Allow more PowerPC sibling calls
On Mon, Apr 18, 2011 at 10:29:17AM -0700, Nathan Froyd wrote: > Could I request that you use FOREACH_FUNCTION_ARGS in these two cases? > The conversion is trivial, and avoiding more exposed TYPE_ARG_TYPES > calls is a good thing. Committed revision 172855. -- Alan Modra Australia Development Lab, IBM
Re: Allow more PowerPC sibling calls
On Apr 18, 2011, at 10:24 AM, David Edelsohn wrote: >> This patch does affect darwin, not only in removing what are now >> redundant insn patterns, but also (a) and (b) above. Would someone >> please run a bootstrap and regression test on darwin for me? I don't >> have a machine handy to confirm that I didn't break anything there. > It would be nice if someone tested on Darwin, although I am sure we > will hear soon enough if it broke anything. I'm happy if you just want to check it in and then check Geoff's regression tester after 20 hours or whatever its cycle time is currently.
Re: Allow more PowerPC sibling calls
On Sat, Apr 09, 2011 at 12:21:46PM +0930, Alan Modra wrote: > a) Allow sibling calls via function pointer. At the time >rs6000_function_ok_for_sibcall was written, I don't think access to >arg types of function pointer calls was available in the target >hook/macro. > > + /* Functions with vector parameters are required to have a > + prototype, so the argument type info must be available > + here. */ > + for (type = TYPE_ARG_TYPES (fntype); > +type; > +type = TREE_CHAIN (type)) > + if (TREE_CODE (TREE_VALUE (type)) == VECTOR_TYPE > + && (ALTIVEC_VECTOR_MODE (TYPE_MODE (TREE_VALUE (type))) > + || VSX_VECTOR_MODE (TYPE_MODE (TREE_VALUE (type) > + nvreg++; > + > + for (type = TYPE_ARG_TYPES (TREE_TYPE (current_function_decl)); > +type; > +type = TREE_CHAIN (type)) > + if (TREE_CODE (TREE_VALUE (type)) == VECTOR_TYPE > + && (ALTIVEC_VECTOR_MODE (TYPE_MODE (TREE_VALUE (type))) > + || VSX_VECTOR_MODE (TYPE_MODE (TREE_VALUE (type) > + nvreg--; Could I request that you use FOREACH_FUNCTION_ARGS in these two cases? The conversion is trivial, and avoiding more exposed TYPE_ARG_TYPES calls is a good thing. Thanks, -Nathan
Re: Allow more PowerPC sibling calls
On Fri, Apr 8, 2011 at 10:51 PM, Alan Modra wrote: > This patch enables sibling calls for powerpc in a few more cases, and > fixes bugs exposed by that change. We now > a) Allow sibling calls via function pointer. At the time > rs6000_function_ok_for_sibcall was written, I don't think access to > arg types of function pointer calls was available in the target > hook/macro. > b) Allow sibling calls to functions with vector parameters. Contrary > to the previous comment about vector parameters, a problem occurs > with VRSAVE only when the called function has more vector > parameters than the caller (because VRSAVE bits will already be set > for the caller's arguments). Also, the old code did not make any > attempt to determine whether altivec/vsx registers would actually > be used to pass args. Not all vector types fit in these regs. > c) Allow SYSV4 ABI code to make sibling calls to non-local functions > so long as not both flag_pic and TARGET_SECURE_PLT are set. > The PIC -msecure-plt call stubs use r30. > > sibcall_value_nonlocal_sysv was trying to read the call cookie from > the wrong operand, a latent bug since the pattern wasn't used until > now. I also fixed a minor problem with CALL_LIBCALL in the call > cookie, which could cause various call insns to match an "n" > constraint rather than a "0" constraint and so give the wrong insn > length. Bootstrapped and regression tested powerpc64-linux and > powerpc-linux. > > This patch does affect darwin, not only in removing what are now > redundant insn patterns, but also (a) and (b) above. Would someone > please run a bootstrap and regression test on darwin for me? I don't > have a machine handy to confirm that I didn't break anything there. > > I've attached a vector testcase I used to verify some of these > changes. > > gcc/ > * config/rs6000/rs6000.c (rs6000_function_arg): Remove CALL_LIBCALL > when returning call_cookie. > (rs6000_function_ok_for_sibcall): Allow sibcalls via function > pointers, to functions with no more vector args than the current > function, and some non-local calls for ABI_V4. > * config/rs6000/rs6000.md (sibcall_nonlocal_aix32, > sibcall_nonlocal_aix64): Combine to .. > (sibcall_nonlocal_aix): ..this. Handle function pointer calls. > (sibcall_value_nonlocal_aix32, sibcall_value_nonlocal_aix64): Combine.. > (sibcall_value_nonlocal_aix): ..likewise. > (*sibcall_nonlocal_sysv): Handle function pointer calls. > (sibcall_value_nonlocal_sysv): Likewise. Correct call cookie > operand. > * config/rs6000/darwin.md (sibcall_nonlocal_darwin64, > sibcall_value_nonlocal_darwin64, sibcall_symbolic_64, > sibcall_value_symbolic_64): Delete. > gcc/testsuite/ > * gcc.target/powerpc/ppc-pow.c: Allow for tail calls. This is okay. It would be nice if someone tested on Darwin, although I am sure we will hear soon enough if it broke anything. Thanks, David
