This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: remove tm.h include from function.h
Quoting "Joseph S. Myers" <joseph@codesourcery.com>:
On Thu, 25 Nov 2010, Joern Rennecke wrote:
I generate a new header file, tm-holdover.h, for BITS_PER_UNIT.
Creating the file through grep is a really ugly way of doing things.
I think it is practically superior to including tm.h in a C file and then
emitting BITS_PER_UNIT with a printf. Consider the case when you have
#define BITS_PER_UNIT (TARGET_64BIT ? 1 : 32)
Then if the generator file compiles at all it would emit a constant;
OTOH the grep statement does the right thing.
We could use a more sophisticated solution with assigning a string - to
be interpreted as a C expression in config,gcc, or by actually parsing
all the include files.
But considering that the few targets the define BITS_PER_UNIT define it
as 8, that would seem over-engineering to me.
There's a case for having multiple tm.h variants for different uses. For
example, completing the toplevel libgcc transition will involve some
headers in libgcc/config for those cases where target macros really are
appropriate rather than built-in macros and functions and other similar
approaches.
Would that then be macros that would be available to user programs via
an installed header file?
Or are you talking about ways to identify the build time or other
circumstances of building the package?
Otherwise, I'm at a loss why the libgcc should be able to do things that
user code couldn't do.
And when the driver starts to use a target structure, the
macros filling in that structure will probably continue to go in headers
(given that they tend to depend on both target OS and target architecture,
unlike many macros in the core compiler) but it would be good to have a
separation of those relevant to the driver from those relevant to the rest
of the compiler - a driver/config/ tree, say. (This is certainly
nontrivial; many specs depend on other macros defined in tm.h.)
But doing things through grep isn't reliable (macros may be conditionally
defined or defined over more than one line)
If the macro goes over more than one line, that is an indicator that it
should be considered if it would be better made into a hook.
Certainly BITS_PER_UNIT is quite far from that.
and doesn't achieve logical separation of the different areas of
compiler configuration. If there is
a set of macros you believe are appropriately defined for files in the
compiler that should not use other macros, work out a logical way to tell
whether a macro is in that class,
It wasn't my idea to leave BITS_PER_UNIT exposed to the entirety of the
compiler, it was Richard Guenther's.
What I'm saying is that I can make a multi-target compiler for an interesting
subset of possible configurations work with BITS_PER_UNIT as a macro.
Also, target-agnostic frontend / tree-optimizer plugins would still be
useful because so many target share the same constant value of BITS_PER_UNIT.
But having the frontends include tm.h for the purpose of getting
BITS_PER_UNIT makes it pretty much impossible to tell if there are any
other target macros in use there. Witness the include in java/class.c
that continued to claim to be there for the sake of gcc_obstack_init,
even though that macro was long since moved to coretypes.h; java/class.c
hade become dependent in the meantime on tm.h in a multitude of other ways.
So, if Richard Guenter and anybody else wo thinks that frontends and tree
optimizers should continue to use target macros, could list those putatively
inalienable macros, we can then discuss if we will be able to gain any real
benefits from our target hooks if these macros remain.
From a practical use standpoint, the impact of macros in different files
is actually different for the different uses. I.e. for frontend plugins,
you'd care only about the frontend files, but very much about these.
For a multi-target compiler that targets a heterogenous system with a uniform
API, for most part, the front-ends don't actually matter, because they
define the semantics of the program in the context of the API. But all the
tree-optimizers than can be re-run after outlining / autoparallelization
have to be able to optimize for the different targets.
then create a separate set of
configuration headers for them in the source tree.
I was kinda hoping we could stop at BITS_PER_UNIT...
Such changes should *definitely* not be mixed in with any other patch like
you have done here.
So what do you propose to do instead? Including tm.h in more source files?
Or having this work block till we have made a census of all macros and
decided which to put where, and implemented a mechanism to effect any
agreed moving of macros?
Regarding the main aim of the present patch, my only
comment is that splitting up function.h into two separate headers would
seem cleaner than making what it declares depend on what headers have been
included first -
Yes, I could do that. All the targets $(out_file)s would have to include
this, though. name it something like function-implementation.h and
$(FUNCTION_IMPLEMENTATION_H) ?
but at least for CUMULATIVE_ARGS it would be better to
remove all variables and fields of that type from target-independent code,
I consider calls.c and function.c target-dependent, but I'm not sure if
you do too. Could you clarify?
instead using a target-independent type and having targets responsible in
some way for allocating and deallocating values of that type.
AFAICT the meaning of this statement becomes either approval or rejection of
the basic premise of my patch depending on how the above question is answered.