Re: [RFC][4.4] Convenience reorganization of parts of tree.h

[Diego Novillo <dnovillo at google dot com>]

Richard Guenther wrote:

>   fold_build2 (PLUS_EXPR, type, TREE_OPERAND (arg0, 1), tmp);
>
> as you first step into that for TREE_OPERAND.  If you now make _all_
> the macros inline functions I can imagine myself running and screaming.

Well, there is that.  But this is a common scenario in languages like 
C++ and there are other places where we have function calls embedded in 
arguments to other functions.  In particular all of the GIMPLE and SSA 
primitive accessors are all static inline functions.  I tend to just set 
a breakpoint in the toplevel function (fold_build2 here) and do 'n'.

> So please - with this work - make sure there is a way to make this smoother,
> either with some fancy gdb support or with fancy gcc support.  Or just tell
> me this is already possible.

The artificial attribute should help, but it doesn't seem to.  I think 
GCC is emitting it but GDB is still going into the inlined functions. 
Perhaps one of the gdb folks can help here.

> > It has other beneficial properties as well.  It makes it easier to
> > refactor internal APIs, add new checks, etc.
>
> I don't see how it is easier with inline functions than with macros.

Macros allow two things that are particularly nasty when refactoring 
code: they can be used as lvalues and &MACRO gives the address of the 
field.  This exposes too much structural knowledge to the client code. 
The idea is to move away from that for better abstraction properties. 
It's easier to instrument, set breakpoints in the debugger, trace when a 
field is accessed when finding bugs, etc.

They also permit tighter static checking because arguments are typed.

This can be phased in, of course.  We don't need to convert everything 
all at once.  I also agree that we have to keep an eye on bootstrap times.

This first patch only re-arranges definitions inside tree.h to permit 
converting macros into inline functions.  It doesn't introduce any 
inline functions, so it will be performance neutral.


Diego.