Re: ping: back end reinitialization hooks to support mixed mips16/nomips16 compilation in same file

[Mark Mitchell <mark at codesourcery dot com>]

Richard Guenther wrote:
> On 7/8/07, Sandra Loosemore <sandra@codesourcery.com> 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.
>>
>> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01785.html
> 
> 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...

One advantage is just simplicity for the programmer.  It allows
programmers to group functions in a logical way, by functionality,
rather than by what ISA they use.  This feature allows users to avoid
making functions non-static just because they happen to be in a
different ISA.

Another advantage is better code-generation.  There are optimizations
that GCC can do if two functions are in the same translation unit that
are not otherwise possible.  LTO will hopefully eliminate many of those
issues, but it's not going to be here soon, and it will always have a
cost.  Inlining is the obvious one, but PC-relative calls, using short
branch instructions, is another.  Automatically determining that a
function is pure or const, and applying CSE is another example.

Also, this capability exists in other compilers, including ARM's
RealView compiler which lets you switch between ARM and Thumb (16-bit
ARM) mode, in much the same way that these patches are designed to let
you switch between MIPS and MIPS16.  I believe that CodeWarrior will let
you switch between Power and VLE (16-bit Power ISA) as well, although I
am not 100% certain.  So, people with code written for those compilers
can more easily bring it to GCC if we support this model too.  And,
presumably, these other vendors implemented it for a reason.  Certainly,
I've had users complain about the lack of this feature.

This feature may not be as useful to workstation and server users as it
is to embedded programmers, where the ability to use 16-bit ISAs for
part of the code can save large amounts of codespace.  But, even there,
this same infrastructure could provide the ability to compile SSE and
non-SSE functions within a single IA32 translation unit, etc.  As Mike
Stump said, Apple's implemented something like this for optimization
levels within GCC.  Your example of Power/SPE for Cell is harder because
the ISAs are completely different, but this a step in that direction.
Personally, I'd love a situation in which we could configure GCC for
multiple targets in the same way that we can configure BFD that way.

So, I think Sandra's right: the choice is between (1) an object-oriented
interface, in which there is a back-end object, and a pointer for the
current back-end, or (2) this procedural approach, in which we
re-initialize things.

I think we already have (1), in a way: that's the targetm object.  But,
we've set up so that's an object, not a pointer, so it's not easy to
switch it dynamically, and we've also got globals that aren't part of
that object.  Even if we decide we like (1) better, I think the current
patch is a step in that direction by highlighting what can change at
reinitialization points.  I don't think we're making moving to (2) any
harder.  And, as you say (2) is might have some performance impact; this
way the cost of switching modes is paid only by backends that support that.

Ignoring the MIPS-specific parts of Sandra's patch, I think that a lot
of what's been done is a cleanup -- initialization hunks have been
broken out of functions into separate init_* functions.  That seems good
in any case.  There are some additional memzero calls which
theoretically introduce some startup overhead, but almost certainly
unmeasurably so.

So, I think the target-independent part of the patch is OK, but please
wait at least 72 hours to allow for objections.  If there are some, then
we'll need to work through the issues.  The MIPS changes should be
reviewed by a MIPS maintainer.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713