Re: Tree inlining for the C front end (part 1 of 3)

[Alexandre Oliva <aoliva at redhat dot com>]

On Oct  3, 2001, Richard Henderson <rth@redhat.com> wrote:

> On Wed, Oct 03, 2001 at 03:50:15AM -0300, Alexandre Oliva wrote:
>> >> http://gcc.gnu.org/ml/gcc-patches/2001-09/msg01019.html
>> > +#define LANG_CANNOT_INLINE_TREE_FN(FNP) \
>> > +  (lang_cannot_inline_tree_fn ? (*lang_cannot_inline_tree_fn)(FNP) : 0)
>> > +typedef int treeopt_cannot_inline_tree_fn_type PARAMS ((tree*));
>> > +extern treeopt_cannot_inline_tree_fn_type *lang_cannot_inline_tree_fn;
>> 
>> > I do not like these.  If you need hooks, add them to the
>> > lang_hooks struct in toplev.c.
>> 
>> I considered doing this, but it would require anything that uses the
>> hooks to have to include tree-inline.h.  Besides, I don't like
>> lang_hooks much because the initializers are ordered, not named, which
>> may lead to synchronization difficulties and warnings about missing
>> initializers, especially for languages maintained outside the GCC CVS
>> tree.

> Hmm.  Well, a minimum acceptable solution is _not_ to use macros,
> but to have e.g. lang_cannot_inline_tree_fn initialized to something
> that does what you want as the default.  While this may seem silly
> for this example, it isn't for LANG_AUTO_VAR_IN_FN_P.

I see how this would be good for LANG_AUTO_VAR_IN_FN_P(), but not for
other macros that have do-nothing or extremely simple definitions.
Besides, it would still have to be written (*fnptr)(args) for K&R C,
which is the ugliness the macro is intended to hide, in addition to
making the potential NULL.  It would surely be easy to arrange for us
to always make a function call, but it would no longer save the
function call that the macros are likely to save for a number of
languages.

I'm not attached to any of these solutions, though; I can justify the
decisions I made (in fact, I've already exposed my arguments :-), but
I'll be glad adopting any solution that would please more people.

> Fixing lang_hooks to be more like target-def.h would be a nice project...

I'm not sure the same caveats about implicit ordering in initializers
don't apply.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me