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. Thanks, Andrew > > Richard >