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/MIPS] Use ins/dins instruction when written manually


On Mon, 2012-11-05 at 11:20 -0800, Andrew Pinski wrote:
> On Mon, 2012-11-05 at 19:19 +0000, Richard Sandiford wrote:
> > Hi Andrew,
> > 
> > Andrew Pinski <andrew.pinski@caviumnetworks.com> writes:
> > > On Fri, Oct 5, 2012 at 8:43 PM, Andrew Pinski
> > > <andrew.pinski@caviumnetworks.com> wrote:
> > >> On Sun, Aug 19, 2012 at 10:13 AM, Richard Sandiford
> > >> <rdsandiford@googlemail.com> wrote:
> > >>> Andrew Pinski <andrew.pinski@caviumnetworks.com> writes:
> > >>>>   Right now we only produce ins when a zero_extract is used on the
> > >>>> right hand side.  We can do better by adding some patterns which
> > >>>> combine for the ins instruction.  This patch adds those patterns and a
> > >>>> testcase which shows a simple example where the code is improved.
> > >>>
> > >>> Sorry for the delay in reviewing this.  Had you thought about trying to
> > >>> teach combine.c about this instead?  It doesn't look like any of the
> > >>> patterns are really providing more information about the underlying
> > >>> instruction.
> > >>
> > >> combine.c has some code to do this already if one of the src register
> > >> is the same as the dest register; that is what make_field_assignment
> > >> does.  Quickly looking at the code, the problem I doing it in
> > >> make_field_assignment is there is no way to return that you need a
> > >> copy of the value first unless I am missing something obvious.  Now I
> > >> agree we should be optimize this in combine rather than these manual
> > >> patterns.
> > >
> > > I now have a patch which implements this in combine which allows the
> > > backend not need to change.  I generate a SEQUENCE which then
> > > try_combine splits like we do for PARALLEL but keeping it in the
> > > correct order and allowing for the case where we are combing two
> > > instructions into two instructions.
> > > I hope to be able to post it later on Saturday.
> > 
> > Just wondering, what's the status of this?  Was worried that you might
> > have posted it and I'd missed it.
> 
> I have not posted it yet.  I am still cleaning up the code and making
> sure it does not cause regressions.

Hi Richard,
  Yesterday, I found out my approach is not ready for the rest of
combine.  So I have to go back to the drawing board of writing a patch.
I will commit the testcase which shows the regression as the testsuite
did not have a testcase for the issue before.

Thanks,
Andrew Pinski


> 
> Thanks,
> Andrew
> 
> > 
> > Richard
> > 
> 
> 
> 



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