From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28609 invoked by alias); 24 Jun 2009 10:16:39 -0000 Received: (qmail 28597 invoked by uid 22791); 24 Jun 2009 10:16:38 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-yx0-f178.google.com (HELO mail-yx0-f178.google.com) (209.85.210.178) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Jun 2009 10:16:31 +0000 Received: by yxe8 with SMTP id 8so1154458yxe.0 for ; Wed, 24 Jun 2009 03:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.124.11 with SMTP id w11mr2145811ybc.276.1245838589159; Wed, 24 Jun 2009 03:16:29 -0700 (PDT) Date: Wed, 24 Jun 2009 12:42:00 -0000 Message-ID: <121fadb80906240316y68a8c132yd254db302e246b37@mail.gmail.com> Subject: Re: How to deal with unrecognizable RTL code From: daniel tian To: Dave Korn Cc: gcc@gcc.gnu.org, peng.zheng@mavrixtech.com, thomas.liau@mavrixtech.com Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00561.txt.bz2 Hi Dove: > The docs for PROMOTE_MODE suggest using `word_mode'; it may be that on mi= ps, > Pmode and word_mode are the same, but they aren't on your machine? Yes. I think the Pmode and word_mode is the same as MIPS. So I copy the code in mips. I just wanna do the operations in WORD mode, and remove the subreg operatio= ns. > Is one of your MD macros not handling the post-reload REG_OK_STRICT macro > correctly perhaps? Yes, REG_OK_STRICT macro is important. I only do it in macro GO_IF_LEGITIMATE_ADDRESS: #define GO_IF_LEGITIMATE_ADDRESS(mode,x,label) \ {\ if (rice_go_if_legitimate_address(mode,x, RICE_REG_STRICT_P))\ goto label;\ } and #ifndef REG_OK_STRICT #define RICE_REG_STRICT_P 0 #else /* REG_OK_STRICT */ #define RICE_REG_STRICT_P 1 #endif /* REG_OK_STRICT */ I don't know where I should check it again. BTW: After tracing the code and comparing with former code I wrote, I find something some clues. I added a judgement in almost insn patterns that if the no_new_pseudos is true, if it is, no more force_reg operations allowed. And another thing is that I add the SUBREG support in BASEREG, INDEXREG, and any other register predicate functions used in MD insn pattern. Like following: /*Here also, strict and non-strict varients are needed.*/ int rice_reg_ok_for_base(rtx x, int bIsStrict) { int regnum; if(GET_CODE(x) !=3D REG && GET_CODE(x) !=3D SUBREG) return RICE_NO; if(GET_CODE(x) =3D=3D SUBREG) { regnum =3D true_regnum (x);=09=09 } else regnum =3D REGNO(x); if(is_base_reg_strict(regnum) && bIsStrict) return RICE_YES; if(non_strict_base_reg(regnum)) return RICE_YES; return RICE_NO; } it will be called in GO_IF_LEGITIMATE_ADDRESS, and LEGITIMIZE_RELOAD_ADDRESS. So like the following unrecognizable RTL has gone. > (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)) But still some problems puzzled me. Maybe the two errors are coherent. I mean they may be the same error. Like the RTL below(including cc1 error notice): error: insn does not satisfy its constraints: (insn:HI 20 539 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 .mode+0 S4 A32])) 11 {load_si} (insn_list:REG_DEP_TRUE 12 (nil)) (nil)) Obviously, the RTL is wrong. And my load and store patterns: ;;store word (define_insn "store_" [(set (match_operand:GPR 0 "memory_operand" "=3Dm") (match_operand:GPR 1 "rice_gpr_operand" "r"))] "TARGET_RICE" { return rice_output_move (operands, mode); } ) ;;Load word (define_insn "load_" [(set (match_operand:GPR 0 "rice_gpr_operand" "=3Dr") (match_operand:GPR 1 "memory_operand" "m"))] "TARGET_RICE" { return rice_output_move (operands, mode); } [(set_attr "type" "load")] ) I checked *.22.lreg, the RTL is fine: (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 .mode+0 S4 A32])) 11 {load_si} (insn_list:REG_DEP_TRUE 12 (nil)) (nil)) but in *.23.greg, error occurred: (insn:HI 20 539 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 .mode+0 S4 A32])) 11 {load_si} (insn_list:REG_DEP_TRUE 12 (nil)) (nil)) The RTL is at the beginning of the function, and R5 is used to pass parameter. So I think maybe should also trace the parameter passing function. Maybe you guys can give me some advices. Thank you. --=20 Best Regards daniel tian Mavrix Technology, Inc. Address=A3=BA200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech Park, Shanghai, P.R.China (201204) Tel:86(21)51095958 - 8125 Fax:86(21)50277658 Email=A3=BAdaniel.tian@mavrixtech.com.cn www.mavrixtech.com