[PATCH/MIPS] Use ins/dins instruction when written manually
Andrew Pinski
andrew.pinski@cavium.com
Sat Nov 10 03:12:00 GMT 2012
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
> >
>
>
>
More information about the Gcc-patches
mailing list