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: [PATCH 1/2] New pass to partition single function into multiple sections


Hello Michael,

> > Index: target.h
> > ===================================================================
> > --- target.h   (revision 138847)
> > +++ target.h   (working copy)
> > @@ -694,6 +694,37 @@
> >       delayed-branch scheduling.  */
> >    void (* machine_dependent_reorg) (void);
> >
> > +    /* Estimate the number of extra instructions that will be added
for each
> > +       section.  Called when partitioning a function into sections.
*/
> > +  int (* est_section_overhead) (void);
> > +
> > +  /* Return the size of instruction in bytes.  Take into account the
> > +     size of extra machine depndent instructions that can be added as
> > +     a result of insn. (like branch-hints for branch instructions).
> > +     Called when partitioning a function into sections.   */
> > +  int (* est_instruction_size) (rtx);
> > +
> > +  /* Set specific flags; if needed; when partitioning a function into
> > +     several sections.  */
> > +  void (* part_func_to_sections_flags) (void);
> > +
> > +  /* True if an instruction (which is the first parameter) is the
> > +     begining/end of a critical section.  Called when partitioning a
> > +     function into sections.  Define this hook if a sequence of
> > +     instructions must reside in the same section.
> > +     The second parameter is the type of the critical section.  */
> > +  bool (* begin_critical_section) (rtx, int *);
> > +  bool (* end_critical_section) (rtx, int *);
> > +
> > +  /* Record the critical section which contains a jump-table.  The
first
> > +     two parameters are the jump-instruction and the label of the
> > +     jump-table.  The last two parameters are the indices of the
> > +     basic-blocks which indicate the boundaries of the critical
section.
> > +     Called when partitioning a function into sections.  The critical
> > +     section should contain the jump-table and the code that reads the
> > +     table to make sure they will appear in the same section.  */
> > +  void (* record_jump_table) (rtx, rtx, int *, int *);
> > +
> >    /* Create the __builtin_va_list type.  */
> >    tree (* build_builtin_va_list) (void);
>
> Obviously if you follow the suggestions in my previous message, these
will all
> change.  Depending on the hooks that you create, you probably should
consider
> making a substructure to hold all of the partitioning hooks.  If you keep
in
> the est_* hooks, I would spell them estimate_ instead of est_, but that
is minor.
>

It seems that the est_* hooks should be used in the machine independent
part even after we hide all the critical section bits in the back-end;
because it is used to estimate the size of the loops in the decision
of starting a new section if there exists a loop which can be made
to completely fall within the next section while it can not fully be
inserted into the current section.

Thanks,
Revital


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