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.
