Thank you,
Here is the repost.

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.


Br,
Yulia

On Thu, Apr 28, 2016 at 7:32 PM, Jeff Law <law@redhat.com> wrote:
> 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.lu@intel.com>; 'vaalfreja@gmail.com'
>> <vaalfreja@gmail.com>; 'ubizjak@gmail.com' <ubizjak@gmail.com>;
>> 'law@redhat.com' <law@redhat.com>; Zamyatin, Igor <igor.zamyatin@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
>
>