This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

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


Mark Mitchell <mark@codesourcery.com> writes:
> 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.

Since no-one else has really commented on the implementation specifics,
my concerns are that:

  1. This patch doesn't make clear what reinitialisation is and isn't done.
     It implies that backend_reinit reinitialises all backend-related data,
     but the fact that the MIPS hook needs to:

     /* HARD_FRAME_POINTER_REGNUM changes between MIPS16 and non-MIPS16.  */
     if (hard_frame_pointer_rtx)
       SET_REGNO (hard_frame_pointer_rtx, HARD_FRAME_POINTER_REGNUM);
     else
       hard_frame_pointer_rtx
         = gen_rtx_raw_REG (Pmode, HARD_FRAME_POINTER_REGNUM);

     clearly shows that some bits are not reinitialised.

  2. There's no clean distinction between initialisation functions that
     really are called once and those that are called by backend_reinit.
     E.g. we're calling init_alias_once from backend_reinit, so it clearly
     isn't just something we call "once", but nothing in the function's
     name or comment makes that clear.

  3. Not all the functions called by backend_reinit completely reinitialise
     the associated data from scratch.  E.g. init_alias_once relies on the
     zero-initialisation of static_reg_base_value.

>From this point of view, I disagree that it's a clean-up as things stand.
It seems to muddy the waters in some ways.

How about the following strawman suggestion:

  - Rename backend_reinit to something like target_init.

  - Split every function it calls into init_foo and init_foo_target,
    or some such.  The former would do completely target-independent
    initialisation; the latter would do initialisation that depends on
    target macros or target hooks.  (init_foo might not be needed if
    everything that the function initialises is partly target-dependent.)

  - Audit all other initialisation functions to see if they should
    be split in the same way.  Call the new init_*_target functions
    from target_init if so.  The aim is to get target_init to initialise
    _all_ target-dependent global data, and thus avoid things like the
    code quoted in #1 above.

  - Make sure that each init_foo_target initialises data from scratch
    (#3 above).

  - Call target_init from backend_init.

Richard


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