>1) How these unrecognized RTLs are generated? >RTL generation depends on the templates in the .md file. If the format of >these RTLs is not legal, you should review related templates. >2) Add templates to match the unrecognized RTLs if they are legal.
Yeah, you are right. But I have already defined the PROMOTE_MODE which will convert all the QImode, HImode to SImode in computation. And the RTL mentioned, including " SUBREG " should not exist after reload. Now all the instructions pattern, which modes are smaller than SImode, formed in SUBREG. Could anyone give me clue to find out why? Thank you. _______________________________________________ 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.t...@mavrixtech.com.cn www.mavrixtech.com ________________________________________ 发件人: Paul Yuan [mailto:yingbo....@gmail.com] 发送时间: 2009年6月19日 22:27 收件人: 田晓南 主题: Re: How to deal with unrecognizable RTL code Hi Daniel, You can handle this issue from two points: 1) How these unrecognized RTLs are generated? RTL generation depends on the templates in the .md file. If the format of these RTLs is not legal, you should review related templates. 2) Add templates to match the unrecognized RTLs if they are legal. 2009/6/19 田晓南 <daniel.t...@mavrixtech.com.cn> Hello, guys: The porting is really a difficult and huge job. So many things I don't know or miss result in countless bugs. I'd like to thank you for your guys in maillist helping so much, especially, Ian Lance Taylor. Here I encounter some unrecognizable RTL (R0 to R15 are registers. I hate the unrecognizable RTL insns always coming about, and I wanna end it.): (insn 264 191 193 15 (set (reg:HI 5 R5) (subreg:HI (mem:SI (plus:SI (reg/f:SI 14 R14) (const_int 12 [0xc])) [0 crc+0 S4 A32]) 0)) -1 (nil) (nil)) (insn 261 197 200 14 (set (reg:HI 5 R5) (subreg:HI (mem:SI (reg/f:SI 14 R14) [7 crc.16+0 S4 A32]) 0)) -1 (nil) (nil)) PROMOTE_MODE, stolen from mips, is defined in my port: #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \ if (GET_MODE_CLASS (MODE) == MODE_INT \ && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \ { \ (MODE) = Pmode; \ } I don't know whether those RTL related with this macro. Yeah, there is a solution to fix them -- updated the LOAD/STORE constraint. But I don't think it's a good point. My RISC chip only accepts the specified RTL which I have already defined them with insn and expand patterns. So I think there must be a way which legitimizes RTL code. (insn:HI 17 13 14 0 (set (mem/s:SI (plus:SI (mem/f:SI (reg/f:SI 14 R14) [15 header+0 S4 A32]) (const_int 32 [0x20])) [10 <variable>.private_bits+0 S4 A32]) (reg:SI 4 R4 [56])) 8 {store_si} (insn_list:REG_DEP_TRUE 13 (insn_list:REG_DEP_TRUE 6 (nil))) (expr_list:REG_EQUAL (const_int 0 [0x0]) (nil))) If I have to fix those RTL one by one, that would be so tough! So did there are some macros or TARGET HOOKs, which retrieve those unknown RTL, then, I can write code there to force them into specified way. Any suggestion is appreciated! Thank you very much! Daniel.Tian _______________________________________________ Best Regards Daniel Tian Tel:86(21)51095958 - 8125 Fax:86(21)50277658 email：daniel.t...@mavrixtech.com.cn www.mavrixtech.com -- Regards, Paul Yuan (袁鹏)
