Re: [dfa-branch] DFA pipeline description for SH4

[Vladimir Makarov <vmakarov at redhat dot com>]

Naveen Sharma wrote:
> 
> Hi,
> 
> I would like to discuss two issues.( I am CCing to SH maintainers
> for primarily for issue #2, I hope that's all right)
> 
> 1.
> 
> Thursday, December 20, 2001 9:50 PM Vladimir Makarov Wrote:
> > > Meanwhile there are certain applications which have slightly
> > > degraded performance.We are analysing them and would update
> > > you regarding them.
> > >
> >
> >   Usually, it is well known conflict between insn schedulers and
> > register allocators.  Dfa-based scheduler improves fine-grain
> > parallelism by moving some insns further which results in increasing
> > register pressure and spilling registers.  So you could check
> > additional spilling registers the first to find the reason of the
> > degradation.  The simplest solution of the problem could be using register
> > pressure in insn scheduler heuristics.
> 
> We have an interesting problem(although on a different note than above).
> SH4 is dual issue machine.SH Instructions are
> categorized into six groups depending on internal function blocks used.(in
> SH parlance, these
> groups are named LS,MT,BR,CO,FE and EX)
> The limitation is that two "same group" instructions cannot be issued on
> same cycle(MT group is
> the exception).The description takes care of these facts and normally
> generates good
> code where normally  "different group" instructions are issued in same
> cycle. But there is problem in
> loops. I explain with an example.
> 
>                       Block 1 ( Contains an odd number of insns)
>          LOOP:
>                       Block  2
>          LOOP_END
>                        Block 3
> 
> First time through the loop ,the last insn of Block 1 is issued in pair with
> first insn
> of the Block 2( which is loop body). In subsequent iterations, the pairing
> changes
> and some same group insns are issued in the same cycle thus introducing
> pipeline
> stalls.I hope I have explained the problem well. If it is not clear please
> let me know.
> 
> This could possibly  be solved if some insn of loop body be moved to pair
> with
> last insn of Block 1 or otherwise inserting a nop with last insn of Block1.
> Put it in simple words, the scheduler seems to have no provision that fall
> through
> dominator of the basic block ends on CPU cycle boundary.
> Please let me know ur opinion on this.
> 

  All software pipelining algorithms addresses to the problem.  Gcc (in
redhat repository and probably in the latest redhat releases to Hitachi)
has already a software pipelining algorithm.  It is the RCSP (resource
constrained software pipelining):

  Resource-Contrained Software Pipelining, Alexander Aiken, Alexandru
Nickolau, Steven Novack, IEEE Transactions on Parallel and Distributed
Systems, 6(12), pp. 1248--1270, December 1995.

  It is based on the DFA ipeline hazard recognizer.  Although the
current implementation is slow and quite constrained (it can not move
dangerous insns through iterations and has no dependency analysis), it
should solve the problem.  I am going to commit it into the branch after
moving the dfa-based scheduler into the main trunk.

  I expect many objections to this code because it is written not in gcc
style (it is written as an abstract data with well defined interface and
can be easy embedded into other compilers).  Unfortunately I have no
time to work on dfa-based scheduler now (I'd like to improve it and
write the new interblock scheduler) and to improve and finish RCSP
implementation.  So I can not promise the RCSP will be soon there.

>  2. We presume that the patch we submitted would first go into dfa branch
> after approval.
>       As of now, it is not checked in. There are some minor changes in the
> patch. Do we re-submit ?         Would you suggest  the course of action.
> ( Actually I don't know who has rights to check in the patch in dfa-branch.)
>

  Sorry, I missed your patch.  Could you resubmit it to me and I'll look
at this for approval.  If you have write access to FSF repository, you
could commit it yourself into the branch after my approval, otherwise
I'll commit it myself.
 
Thank you for your interest in dfa-based scheduler.

Best regards,
Vladimir Makarov