On 04/20/2016 07:48 AM, Koval, Julia wrote:
Sorry, here is the right patch.
-----Original Message-----
From: Koval, Julia
Sent: Wednesday, April 20, 2016 4:42 PM
To: 'gcc-patches@gcc.gnu.org' <gcc-patches@gcc.gnu.org>
Cc: Lu, Hongjiu <hongjiu...@intel.com>; 'vaalfr...@gmail.com' <vaalfr...@gmail.com>;
'ubiz...@gmail.com' <ubiz...@gmail.com>; 'l...@redhat.com' <l...@redhat.com>; Zamyatin, Igor
<igor.zamya...@intel.com>
Subject: [PATCH] x86 interrupt attribute patch [1/2]
Hi,
Here is the new version of interrupt attribute patch. Bootstraped/regtested for
Linux/x86_64. Ok for trunk?
Update TARGET_FUNCTION_INCOMING_ARG documentation
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
}
* 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.
So I think the function.c changes are fine. But I think we need to do a
tiny bit more on the documentation side before we can install the change.
While I think a rewrite of the whole argument passing section would be
advisable, that may be a bit much to expect. So let's try to just
cleanup FUNCTION_INCOMING_ARG.
FUNCTION_INCOMING_ARG has text like "Define this hook if the target
machine has register windows ..."
I'd change that text to be something like
"Define this hook if the caller and callee on the target have different
views of where arguments are passed. Also define this hook if there are
functions that are never directly called, but are invoked by the
hardware and which have nonstandard calling conventions."
Or something along those lines.
At one time I thought we'd want to specify how the cumulative args
structure would or would not be updated for these special arguments.
But after further reflection, I think that can be a target dependent
implementation detail.
I think with that one documentation update this will be OK, but I would
like you to repost it so I can look at it one final time.
jeff
