| Message ID | 20151129171444.GA21399@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 11/29/2015 06:14 PM, H.J. Lu wrote: > Is this safe for stage 3? Is there a reason to do it now? This doesn't include a testcase. > * function.c (assign_parm_setup_stack): Force source into a > register if needed. > * target.def (function_incoming_arg): Update documentation to > allow arbitrary address computation based on hard register. > * doc/tm.texi: Regenerated. Bernd
On 11/30/2015 03:35 AM, Bernd Schmidt wrote: > On 11/29/2015 06:14 PM, H.J. Lu wrote: >> Is this safe for stage 3? > > Is there a reason to do it now? This doesn't include a testcase. Handling the proposed attribute requires extensions to the current function_arg capabilities. I need to go back to the discussion between HJ, rth, Uros, myself and probably others to get the full details. I recall two extensions to the current set of return values from function_arg. One was to allow the target to return an address. That address will be forced by the generic code into a pseudo. I thought we agreed to one other extension to support the interrupt mechanism, but again, I'll have to dig through the archives to remember the full details. These extensions were necessary to avoid some horrid hacks in the x86 backend which Uros, quite reasonably, rejected. We agreed to return to this after stage1 opened. jeff
On Thu, Apr 28, 2016 at 8:25 AM, Jeff Law <law@redhat.com> wrote: > On 11/30/2015 03:35 AM, Bernd Schmidt wrote: >> >> On 11/29/2015 06:14 PM, H.J. Lu wrote: >>> >>> Is this safe for stage 3? >> >> >> Is there a reason to do it now? This doesn't include a testcase. > > Handling the proposed attribute requires extensions to the current > function_arg capabilities. > > I need to go back to the discussion between HJ, rth, Uros, myself and > probably others to get the full details. I recall two extensions to the > current set of return values from function_arg. One was to allow the > target to return an address. That address will be forced by the generic > code into a pseudo. > > I thought we agreed to one other extension to support the interrupt > mechanism, but again, I'll have to dig through the archives to remember the > full details. This is the only extension needed to implement x86 interrupt attribute. It should have no impact on other targets which always have arguments either in memory or register. > These extensions were necessary to avoid some horrid hacks in the x86 > backend which Uros, quite reasonably, rejected. We agreed to return to this > after stage1 opened. > That is correct. Thanks.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index bde808b..212993d 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -3949,6 +3949,10 @@ which the caller passes the value, and fashion to tell the function being called where the arguments will arrive. +@code{TARGET_FUNCTION_INCOMING_ARG} can also return arbitrary address +computation using hard register, which can be forced into a register, +so that it can be used to pass special arguments. + If @code{TARGET_FUNCTION_INCOMING_ARG} is not defined, @code{TARGET_FUNCTION_ARG} serves both purposes. @end deftypefn diff --git a/gcc/function.c b/gcc/function.c index 515d7c0..00ec950 100644 --- a/gcc/function.c +++ b/gcc/function.c @@ -3461,7 +3461,11 @@ assign_parm_setup_stack (struct assign_parm_data_all *all, tree parm, BLOCK_OP_NORMAL); } else - emit_move_insn (dest, src); + { + if (!REG_P (src)) + src = force_reg (GET_MODE (src), src); + emit_move_insn (dest, src); + } } if (to_conversion) diff --git a/gcc/target.def b/gcc/target.def index b0ad09e..4f4d337 100644 --- a/gcc/target.def +++ b/gcc/target.def @@ -4472,8 +4472,8 @@ a register.", bool named), default_function_arg) -/* Likewise, but for machines with register windows. Return the - location where the argument will appear to the callee. */ +/* Likewise, but for machines with register windows or special arguments. + Return the location where the argument will appear to the callee. */ DEFHOOK (function_incoming_arg, "Define this hook if the target machine has ``register windows'', so\n\ @@ -4487,6 +4487,10 @@ which the caller passes the value, and\n\ fashion to tell the function being called where the arguments will\n\ arrive.\n\ \n\ +@code{TARGET_FUNCTION_INCOMING_ARG} can also return arbitrary address\n\ +computation using hard register, which can be forced into a register,\n\ +so that it can be used to pass special arguments.\n\ +\n\ If @code{TARGET_FUNCTION_INCOMING_ARG} is not defined,\n\ @code{TARGET_FUNCTION_ARG} serves both purposes.", rtx, (cumulative_args_t ca, machine_mode mode, const_tree type,
On x86, interrupt handlers are only called by processors which push interrupt data onto stack at the address where the normal return address is. Since interrupt handlers must access interrupt data via pointers so that they can update interrupt data, the pointer argument is passed as "argument pointer - word". TARGET_FUNCTION_INCOMING_ARG defines how callee sees its argument. Normally it returns REG, NULL, or CONST_INT. This patch adds arbitrary address computation based on hard register, which can be forced into a register, to the list. When copying an incoming argument onto stack, assign_parm_setup_stack has: if (argument in memory) copy argument in memory to stack else move argument to stack Since an arbitrary address computation may be passed as an argument, we change it to: if (argument in memory) copy argument in memory to stack else { if (argument isn't in register) force argument into a register move argument to stack } Is this safe for stage 3? H.J. --- * function.c (assign_parm_setup_stack): Force source into a register if needed. * target.def (function_incoming_arg): Update documentation to allow arbitrary address computation based on hard register. * doc/tm.texi: Regenerated. --- gcc/doc/tm.texi | 4 ++++ gcc/function.c | 6 +++++- gcc/target.def | 8 ++++++-- 3 files changed, 15 insertions(+), 3 deletions(-)