From: "daniel.tian" <daniel.tian@mavrixtech.com.cn>
To: "'Jeff Law'" <law@redhat.com>
Cc: <gcc@gcc.gnu.org>, "'Peng Zheng'" <peng.zheng@mavrixtech.com>,
<thomas.liau@mavrixtech.com>,
"'Ian Lance Taylor'" <iant@google.com>,
"'Michael Hope'" <michael.hope@gmail.com>,
"'Joern Rennecke'" <amylaar@spamcop.net>
Subject: 答复: How to deal with unrecognizable RTL code
Date: Mon, 29 Jun 2009 10:40:00 -0000 [thread overview]
Message-ID: <20090629093824.716BB3758001@mail.mavrixtech.com.cn> (raw)
In-Reply-To: <4A43C3F9.4080508@redhat.com>
Hi, Jeff:
> OK. Subregs of MEMs are a little special. In general, you don't want to
> see these at all. I wouldn't necessarily expect this to be a
> PROMOTE_MODE problem.
>
> As others have suggested, find the first pass where you see a (subreg
> (mem)) expression. That will be a big help. Extra credit if you can
> correlate the insns in that dump with insns in the previous dump file
> which would show how the pass in question modified the RTL incorrectly.
> Given that it should be relatively easy to start digging into the problem.
>
Yeah, You are right. Now I, making reference to ARM movm pattern, wanna
rewrite the movm pattern. Now the movm pattern do not performs well.
> This looks like a different problem. What pass generates insn 17? What
> does insn 17 look like in the prior pass? If r14 is your stack/frame
> pointer, this might point to a problem in how your port interacts with
> register allocation/reload as reload can replace a pseudo with an
> equivalent memory location.
>
Here is RTL in *.22.lreg:
(insn:HI 12 13 20 0 (set (reg/v/f:SI 91 [ frame ])
(reg:SI 5 R5 [ frame ])) 14 {move_regs_si} (nil)
(expr_list:REG_DEAD (reg:SI 5 R5 [ frame ])
(nil)))
(insn:HI 20 12 11 0 (set (reg:SI 88 [ D.1221 ])
(mem/s:SI (plus:SI (reg/v/f:SI 91 [ frame ])
(const_int 4 [0x4])) [13 <variable>.mode+0 S4 A32])) 11
{load_si} (insn_list:REG_DEP_TRUE 12 (nil))
(nil))
You can see the two insns are right. Reg91 <-- R5, Reg88 <-- (R91 + 4).
But in *.23.greg, RTL is wrong:
(insn:HI 12 13 545 0 (set (reg:SI 5 R5)
(reg:SI 5 R5 [ frame ])) 14 {move_regs_si} (nil)
(nil))
(insn 545 12 20 0 (set (mem/f:SI (plus:SI (reg/f:SI 14 R14)
(const_int 172 [0xac])) [35 frame+0 S4 A32])
(reg:SI 5 R5)) 8 {store_si} (nil)
(nil))
(insn:HI 20 545 11 0 (set (reg:SI 6 R6 [orig:88 D.1221 ] [88])
(mem/s:SI (plus:SI (mem/f:SI (plus:SI (reg/f:SI 14 R14)
(const_int 172 [0xac])) [35 frame+0 S4 A32])
(const_int 4 [0x4])) [13 <variable>.mode+0 S4 A32])) 11
{load_si} (insn_list:REG_DEP_TRUE 12 (nil))
(nil))
Why there is a crap insn existence: R5 <-- R5??
The following RTL insn is right which means storing R5 register to a
specific memory location.
The finally insn is weird. Actually, we can see that the location in
(mem/f:SI (plus:SI (reg/f:SI 14 R14) (const_int 172 [0xac])) is R5. I don't
why it is placed and what criteria the displacement bases.
Does Gcc like to merge some RTL? If it does, gcc merge RTL base what?
I mean if the merging happening, some generating RTL will be incorrect.
Thank you for your guys help!
Daniel.Tian
_______________________________________________
Best Regards
Daniel Tian
Mavrix Technology, Inc.
Address:200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech Park,
Shanghai, P.R.China (201204)
Tel:86(21)51095958 - 8125
Fax:86(21)50277658
Email:daniel.tian@mavrixtech.com.cn
www.mavrixtech.com
next prev parent reply other threads:[~2009-06-29 9:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-19 8:08 田晓南
2009-06-19 11:56 ` Paolo Bonzini
2009-06-24 9:35 ` daniel.tian
2009-06-24 9:36 ` Dave Korn
2009-06-24 9:37 ` Paolo Bonzini
2009-06-24 10:16 ` Dave Korn
2009-06-25 18:43 ` Jeff Law
2009-06-29 10:40 ` daniel.tian [this message]
2009-07-01 1:57 ` 答复: " Jeff Law
2009-06-29 10:52 ` daniel.tian
2009-06-29 21:11 ` How " Ian Lance Taylor
2009-06-30 6:20 ` Jim Wilson
2009-06-30 14:22 ` daniel.tian
2009-07-01 2:05 ` Jeff Law
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=20090629093824.716BB3758001@mail.mavrixtech.com.cn \
--to=daniel.tian@mavrixtech.com.cn \
--cc=amylaar@spamcop.net \
--cc=gcc@gcc.gnu.org \
--cc=iant@google.com \
--cc=law@redhat.com \
--cc=michael.hope@gmail.com \
--cc=peng.zheng@mavrixtech.com \
--cc=thomas.liau@mavrixtech.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).