Re: [PATCH/MIPS] Use ins/dins instruction when written manually

[Andrew Pinski <andrew dot pinski at cavium dot com>]

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.

Thanks,
Andrew

> 
> Richard
>