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.pin...@caviumnetworks.com> writes: > > > On Fri, Oct 5, 2012 at 8:43 PM, Andrew Pinski > > > <andrew.pin...@caviumnetworks.com> wrote: > > >> On Sun, Aug 19, 2012 at 10:13 AM, Richard Sandiford > > >> <rdsandif...@googlemail.com> wrote: > > >>> Andrew Pinski <andrew.pin...@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 > > > > >
