This is the mail archive of the
mailing list for the GCC project.
Re: ping: back end reinitialization hooks to support mixed mips16/nomips16 compilation in same file
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Sandra Loosemore" <sandra at codesourcery dot com>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 8 Jul 2007 23:11:52 +0200
- Subject: Re: ping: back end reinitialization hooks to support mixed mips16/nomips16 compilation in same file
- References: <46914FFB.email@example.com>
On 7/8/07, Sandra Loosemore <firstname.lastname@example.org> wrote:
Anyone had a chance to look over these patches yet? Even some general feedback
or discussion about whether this is a good idea would be appreciated.
What's the advantage of controlling the target per function instead of per
compilation unit? You can trivially split the compilation unit into a
per function one...
Also this looks ugly ;) And creating a backend object that can be
easily switched as you suggest will potentially cause a lot of indirection
overhead. Maybe separate shared objects for libbackend (of course the
"right" parts of it) and explicitly calling the correct one would be a more
efficient (and easier to implement?) way?
That said - the only scenario I can see having more than one backend
available is if the compiler itself creates functions for the different
(sub-)architecture. Like it would happen for auto-parallelization on