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


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.

Richard


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