This is the mail archive of the gcc@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: How to make use of instruction scheduling to improve performance?


2007/7/29, 吴曦 <wu.andrew.xi@gmail.com>:
> 28 Jul 2007 12:16:51 -0700, Ian Lance Taylor <iant@google.com>:
> > "吴曦" <wu.andrew.xi@gmail.com> writes:
> >
> > > 28 Jul 2007 09:04:01 -0700, Ian Lance Taylor <iant@google.com>:
> > > > "吴曦" <wu.andrew.xi@gmail.com> writes:
> > > >
> > > > > there are some questions after I read the source code today.
> > > > > 1st. if I add the instrumentation before 2nd scheduling; will gcc emit
> > > > > an insn which will be output as a ld instruction later? If this could
> > > > > happen, some ld instruction may not be instrumented...
> > > >
> > > > No, gcc won't introduce any new memory load or store instructions
> > > > after the prologue and epilogue instructions are threaded.  It may
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > when are prologue and epilogue instructions threaded? (after register
> > > allocation? besides, what is the exact meaning of "prologue and
> > > epilogue instructions are threaded"? Would you mind explaining in more
> > > detail? thx :-))
> >
> > If you look in gcc/passes.c you will see the list of passes.  The
> > prologue and epilogue instructions are threaded in
> > pass_thread_prologue_and_epilogue.  This happens after register
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Sorry, I didn't find that pass in gcc 4.1.1. This pass is added in the
> newest gcc?
> thx.
>
> > allocation.  It means that the prologue and epilogue instructions are
> ~~~~~~~~~~
> As you have indicated, this pass happens after register allocation, I
> want to allocate register rather than dedicating register to do the
> instrumentation calculation, are there any hints to do this?
>
> > added to the RTL, so that the second scheduling pass can see them.
> >
> > > > still move them around or eliminate them, though.
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > emmm, I need to move/remove my instrumentation if necessary...
> >
> > Yes.  This is true by definition, since you want to instrument before
> > the second scheduling pass.  The scheduler can and will move load and
> > store instructions.  You need to set up the dependencies so that your
> > instrumentation will still occur at the right time.
> >
> > > > > 2nd. to identify ld/st instruction (memory access op), I want to
> > > > > modify gen_rtx_SET, the method is that, if I find SRC or DST is an
> > > > > memory operand in gen_rtx_SET, then add instrumentation code before
> > > > > and after the insn to emit. Will this method work? Besides, if some
> > > > > false positives occur, how to correct them (I don't have some very
> > > > > clear idea.)
> > > >
> > > > Modifying gen_rtx_SET is probably not the right way to go.  That is
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Then, what about modifying machine description file? Add define_expand
> > > for the define_insn which will output ld/st instruction (this
> > > define_expand can insert instrumentation insns. Of course, I need to
> > > identify the operands to the define_expand contains a memory operand
> > > and a reg operand.)
> >
> > That will work in some sense, but if a load or store instruction is
> > eliminated you are quite likely to still have the instrumentation
> > instructions lying around.
> >
> > Ian
> >
> Thanks for your hints.
>
rest_of_handle_flow2 calls thread_prologue_and_epilogue_insns, maybe I
need to move to a newer version of gcc

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