Re: revised PATCH: per-function back end reinitialization, part 2/2

[David Ung <davidu at mips dot com>]

Sandra Loosemore wrote:
> Richard Sandiford wrote:
> > Sandra Loosemore <sandra@codesourcery.com> writes:
> > > ! /* Remember the ambient target flags, excluding mips16.  */
> > > ! static GTY(()) int mips_base_target_flags;
> > > ! /* The mips16 command-line target flags only.  */
> > > ! static GTY(()) int mips_base_mips16;
> > > ! /* Similar copies of option settings.  */
> > > ! static int mips_base_schedule_insns; /* flag_schedule_insns */
> > > ! static int mips_base_align_loops; /* align_loops */
> > > ! static int mips_base_align_jumps; /* align_jumps */
> > > ! static int mips_base_align_functions; /* align_functions */
> > > ! static GTY(()) int mips16_flipper;
> >
> > Why are only some of these GTY(())?
>
> For that matter, why are any of these marked GTY(())?  I assumed it had 
> something to do with precompiled header support, which is a bit of the 
> compiler I know nothing about (yet).  David, Nigel?

aiye, it fixes the GCC PCH regressions.

> > > +   /* If we are generating non-mips16 code for this function and we 
> > > pass
> > > +      -mips16 on the command line, we need to generate a fn_stub for 
> > > any +      built-in functions that we call.  */
> > > +   if (!TARGET_MIPS16
> > > +       && mips_base_mips16
> > > +       && TARGET_HARD_FLOAT_ABI
> > > +       && GET_CODE (addr) == SYMBOL_REF
> > > +       && SYMBOL_REF_DECL (addr)
> > > +       && TREE_TYPE (SYMBOL_REF_DECL (addr))
> > > +       && TREE_TYPE (SYMBOL_REF_DECL (addr)) != error_mark_node
> > > +       && DECL_BUILT_IN (SYMBOL_REF_DECL (addr)))
> > > +     build_mips16_function_stub (asm_out_file, SYMBOL_REF_DECL (addr),
> > > +                 aux == 0 ? 0 : (int) GET_MODE (aux));
> >
> > I'm not sure I follow.  What sort of built-in functions are we talking
> > about here?  What is the TREE_TYPE test doing?  Do we ever see
> > error_mark_node here?  (My understanding is that we don't any more.)
>
> Hrmmm.  This didn't look implausible to me, but I tried commenting it 
> out and didn't see any testsuite regressions with -mflip-mips16.  (In 
> fact, that even fixed a few.)  David, was there a specific test case 
> that was failing without this?  Otherwise I think we can chuck this part 
> of the patch, as well as the changes to build_mips16_function_stub to 
> support it.

any function that does floating point, eg sin, cos (and we need to link to these 
mips16 functions) as the compiler don't automatically generate stubs in 
non-mips16 mode.
I am not remembering much about this at the moment.  I am ok chucking out bits 
that seem redundant until we find a test case for it.

David