This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Experiences using struct gcc_target


Hi Stan!

Stan Shebs wrote:-

> 1. target.h has to be included manually everywhere, which is
> a lot of file touching.  Perhaps it should be included from
> tm.h or some such?  A fully filled-out target.h is going to
> be needed by just about every source file.

I was just adding it one by one as needed.  If others agree, it could
go in some other header file; I'm not bothered either way.

> 1a. Because expand_builtin gets rtxes as args, and because
> target.h is included in tree.c, I had to include rtl.h in tree.c.
> Although I don't think this is Evil(tm), it's certainly
> counterintuitive.

You shouldn't need to.  Your problem is rtx is a typedef.  Use a
(possibly predeclared) union rtx_def * (or whatever rtx really is).
You just have a pointer to the type, and not the type itself, so you
shouldn't need rtl.h.

> 2. There are lots and lots of local variables named "target"
> in the sources, and every one of them is going to mask the global
> "target" that is the function vector.  I don't know whether it
> makes more sense to change the global's name or to adjust each
> function as conflicts occur.

Ugh.  I've changed one I hit in cp/decl2.c to tgt.  I'm open on what
to do in general here too.  If we rename "target" from target.h, I
request we keep the name short, otherwise we'll cause lots of stuff
that accesses it to line wrap.

> Even with these little difficulties, I really like the new setup.
> It will go a long way to cleaning up some of rat's nests of ifdefs
> that have accumulated in the compiler	, and as a bonus, I don't have
> to touch <arch>.h and do massive rebuilds over and over...

8-) Some of the conditional compilation is just transferred to
cpu/cpu.c, though.  However, since we all spend more time browsing the
main sources, I think it's still a readability win.

I'm still working on FUNCTION_{PRO,EPI}LOGUE.  Needless to say, it's
taking a lot longer than I thought :-)

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]