This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Experiences using struct gcc_target
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: Experiences using struct gcc_target
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Thu, 5 Jul 2001 07:45:34 +0100
- Cc: gcc at gcc dot gnu dot org
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.