From: Richard Henderson <rth@redhat.com>
To: Walter Lee <walt@tilera.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PING2] New port for ... TILE-Gx
Date: Tue, 08 Nov 2011 21:30:00 -0000 [thread overview]
Message-ID: <4EB99E01.2000103@redhat.com> (raw)
In-Reply-To: <4EB869A3.4040709@tilera.com>
On 11/07/2011 03:28 PM, Walter Lee wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02084.html
TileGx:
Almost all the same comments as for TilePro.
I see that you've started some macroization of the port, but havn't completed it. E.g. sub<mode>3 vs addsi3+adddi3.
> (define_expand "addsf3"
Clever. I do wonder if it wouldn't be better to wait until after reload to split these though.
> (define_insn "*and_0x00000000FFFFFFFF"
> (define_insn "*and_0xFFFFFFFF00000000"
These probably should be merged into the main AND pattern. But failing that, they're only applicable to DImode and needn't be macroized.
> (define_expand "clzsi2"
> [(set (match_dup 2)
> (ashift:DI (match_operand:SI 1 "reg_or_0_operand" "")
> (const_int 32)))
> (set (subreg:DI (match_operand:SI 0 "register_operand" "") 0)
> (clz:DI (match_dup 2)))]
> ""
Generic code can handle this. Likewise ctz, popcount, parity.
> (define_insn "insn_cmpexch<four_if_si>"
> (define_insn "insn_exch<four_if_si>"
> (define_insn "insn_fetchadd<four_if_si>"
> (define_insn "insn_fetchand<four_if_si>"
> (define_insn "insn_fetchor<four_if_si>"
Use the atomic_ names and interfaces.
> #define LIBCALL_VALUE(MODE) gen_rtx_REG (MODE, 0)
> #define FUNCTION_VALUE_REGNO_P(N) ((N) < TILEGX_NUM_RETURN_REGS)
> #define FUNCTION_ARG_REGNO_P(N) ((N) < TILEGX_NUM_ARG_REGS)
> #define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
> #define GO_IF_MODE_DEPENDENT_ADDRESS(ADDR, LABEL) \
All of these are now target hooks. There may be more.
> /* We represent all SI values as sign-extended DI values in
> registers. */
> #define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) \
> ((INPREC) <= 32 || (OUTPREC) > 32)
I think you should be *very* careful before you insist on this. Do you not have a memory mode that ignores the high bits for 32-bit pointers? From the description of "memoryReadWord", it does seem like you've got modes that pre-process input addresses.
MIPS uses this because, techinically, the 32-bit operation insns produce undefined results when given inputs that are not sign-extended. I see no such restriction in the TileGx manual.
At least in 64-bit pointer mode, I think you should drop this and make sure that you've got appropriate sign_extend patterns for all of the "x" insns. Similar to how x86_64 does for the zero_extend patterns.
r~
prev parent reply other threads:[~2011-11-08 21:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee
2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib Walter Lee
2011-10-20 17:11 ` Walter Lee
2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 1/7: toplevel changes Walter Lee
2011-10-15 11:09 ` [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port Walter Lee
2011-10-15 18:33 ` Joseph S. Myers
2011-10-20 16:40 ` Walter Lee
2011-10-20 20:55 ` Joseph S. Myers
2011-10-23 10:23 ` Walter Lee
2011-10-15 11:36 ` [PATCH] New port for TILEPro and TILE-Gx 4/7: libcpp port Walter Lee
2011-10-15 12:04 ` [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port Walter Lee
2011-10-15 19:00 ` Joseph S. Myers
2011-10-20 17:29 ` Walter Lee
2011-10-23 11:25 ` Walter Lee
2011-10-15 13:31 ` [PATCH] New port for TILEPro and TILE-Gx: 6/7 libgomp port Walter Lee
2011-10-15 14:25 ` [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes Walter Lee
2011-10-16 18:51 ` Gerald Pfeifer
2011-10-30 17:14 ` [PING] New port for TILEPro and TILE-Gx Walter Lee
2011-11-07 17:03 ` [PING2] " Walter Lee
2011-11-07 22:27 ` Richard Henderson
2011-11-07 23:56 ` Walter Lee
2011-11-08 19:47 ` [PING2] New port for TILEPro Richard Henderson
2011-11-08 21:30 ` Richard Henderson [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=4EB99E01.2000103@redhat.com \
--to=rth@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=walt@tilera.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).