On Wed, Dec 18, 2013 at 6:54 PM, Diego Novillo <dnovi...@google.com> wrote:
> On Wed, Dec 18, 2013 at 8:20 AM, Andrew MacLeod <amacl...@redhat.com> wrote:
>> On 12/18/2013 08:08 AM, Diego Novillo wrote:
>>>
>>> On Wed, Dec 18, 2013 at 6:57 AM, Prathamesh Kulkarni
>>> <bilbotheelffri...@gmail.com> wrote:
>>>
>>>> Would it be better to include tree.h instead of tree-core.h (tree.h
>>>> includes tree-core.h anyway), or shall I leave these macros untouched
>>>> ?
>>>
>>> Better leave these macros intact for now. We are trying to flatten out
>>> the #include tree. Adding tree.h to another header goes in the
>>> opposite direction.
>>>
>>> Please add a note describing the conflict.
>>>
>>>
>>>
>> Looks like function.c is the primary user of {ADD,SUB}_PARM_SIZE, with a
>> single use of ADD_PARM_SIZE in calls.c I'd suggest moving both new
>> functions to function.c and exporting the protoype for add_parm_size() in
>> function.h. calls.c already include function.h.
>>
>> I can't imagine that call to ADD_PARM_SIZE in calls.c having much impact on
>> compile time...
>
> Ah, yes, if the usage pattern of these macros is so simple, that's a
> better option.
>
>
> Diego.
ADD_PARM_SIZE is called at 4 places from the following callers:
File Function Line
0 calls.c initialize_argument_information 1356
ADD_PARM_SIZE (*args_size, args[i].locate.size.var);
1 function.c assign_parm_is_stack_parm 2566 ADD_PARM_SIZE
(all->stack_args_size, data->locate.size.var);
2 function.c locate_and_pad_parm 3866 ADD_PARM_SIZE
(locate->size, sizetree);
3 function.c pad_below 3959
ADD_PARM_SIZE (*offset_ptr, s2);
As suggested by Andrew, I shall move them into function.c and export
their prototype in function.h
Thanks and Regards,
Prathamesh
