From: Andrew Pinski <andrew.pinski@cavium.com>
To: Richard Sandiford <rdsandiford@googlemail.com>
Cc: Andrew Pinski <andrew.pinski@caviumnetworks.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH/MIPS] Use ins/dins instruction when written manually
Date: Sat, 10 Nov 2012 03:12:00 -0000 [thread overview]
Message-ID: <1352517121.2877.59.camel@apinskidesktop> (raw)
In-Reply-To: <1352143220.10563.5.camel@apinskidesktop>
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
> >
>
>
>
prev parent reply other threads:[~2012-11-10 3:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 2:56 Andrew Pinski
2012-08-19 17:13 ` Richard Sandiford
2012-10-06 3:43 ` Andrew Pinski
2012-10-06 6:07 ` Andrew Pinski
2012-11-05 19:19 ` Richard Sandiford
2012-11-05 19:20 ` Andrew Pinski
2012-11-10 3:12 ` Andrew Pinski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1352517121.2877.59.camel@apinskidesktop \
--to=andrew.pinski@cavium.com \
--cc=andrew.pinski@caviumnetworks.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rdsandiford@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).