From: Richard Sandiford <rsandifo@redhat.com>
To: Nigel Stephens <nigel@mips.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
Ralf Baechle <ralf@linux-mips.org>,
Richard Henderson <rth@redhat.com>,
gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
Date: Tue, 03 Aug 2004 10:36:09 +0100 [thread overview]
Message-ID: <876580bm2e.fsf@redhat.com> (raw)
In-Reply-To: <410F5964.3010109@mips.com> (Nigel Stephens's message of "Tue, 03 Aug 2004 10:22:44 +0100")
Nigel Stephens <nigel@mips.com> writes:
>>If we handle it in a target-independent way, with each insn exposed
>>separately, we will be able to optimize special cases better.
>>We'll also get the usual scheduling benefits.
>
> I agree that we should open-code it for the obvious reasons, but does it
> have to be target independent, or could/should we prototype it with
> define_expand?
I think we should only use define_expands if there's a truly
MIPS-specific feature in the expansion (as there is in the block
move stuff, for example, where we use left/right loads and stores).
Now obviously I'm only guessing what insn sequence you're using,
but I suspect it doesn't involve anything that the middle-end
couldn't work out from stock optabs. If there are different
trade-offs to be made during the expansion, they should probably
be predicated on rtx_costs.
Richard
next prev parent reply other threads:[~2004-08-03 9:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-19 15:35 [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets Maciej W. Rozycki
2004-07-19 16:59 ` Richard Sandiford
2004-07-19 17:32 ` [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bittargets David Edelsohn
2004-07-19 17:33 ` [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets Maciej W. Rozycki
2004-07-19 17:37 ` Richard Sandiford
2004-07-19 21:38 ` Richard Henderson
2004-07-23 14:41 ` Maciej W. Rozycki
2004-07-23 20:27 ` Richard Henderson
2004-07-23 21:12 ` Ralf Baechle
2004-07-26 11:56 ` Maciej W. Rozycki
2004-08-02 20:03 ` Nigel Stephens
2004-08-03 5:30 ` Richard Sandiford
2004-08-03 9:22 ` Nigel Stephens
2004-08-03 9:36 ` Richard Sandiford [this message]
2004-08-03 9:54 ` Nigel Stephens
2004-08-04 19:57 ` Maciej W. Rozycki
2004-08-04 20:37 ` Nigel Stephens
2004-08-04 20:54 ` Maciej W. Rozycki
2004-08-04 23:39 ` Nigel Stephens
2004-08-07 19:01 ` Richard Sandiford
2004-08-09 22:08 ` Richard Henderson
2004-08-10 5:30 ` Richard Sandiford
2004-08-10 23:20 ` Richard Henderson
2004-08-11 0:24 ` Andreas Schwab
2004-08-11 0:40 ` Paul Brook
2004-08-11 4:32 ` Richard Henderson
2004-08-31 19:51 ` Richard Sandiford
2004-09-03 6:53 ` Richard Henderson
2004-09-03 7:05 ` Richard Sandiford
2004-09-03 7:08 ` Richard Henderson
2004-09-03 7:11 ` Richard Sandiford
2004-09-03 7:20 ` Richard Henderson
2004-09-03 7:29 ` Richard Sandiford
2004-09-03 20:15 ` Richard Henderson
2004-09-04 8:53 ` Richard Sandiford
2004-09-05 0:03 ` Richard Henderson
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=876580bm2e.fsf@redhat.com \
--to=rsandifo@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.org \
--cc=nigel@mips.com \
--cc=ralf@linux-mips.org \
--cc=rth@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.