* How to deal with unrecognizable RTL code @ 2009-06-19 8:08 田晓南 2009-06-19 11:56 ` Paolo Bonzini 2009-06-25 18:43 ` Jeff Law 0 siblings, 2 replies; 14+ messages in thread From: 田晓南 @ 2009-06-19 8:08 UTC (permalink / raw) To: gcc Cc: 'Peng Zheng', thomas.liau, 'Ian Lance Taylor', 'Jeff Law', 'Michael Hope', 'Joern Rennecke' 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.tian@mavrixtech.com.cn www.mavrixtech.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-19 8:08 How to deal with unrecognizable RTL code 田晓南 @ 2009-06-19 11:56 ` Paolo Bonzini 2009-06-24 9:35 ` daniel.tian 2009-06-25 18:43 ` Jeff Law 1 sibling, 1 reply; 14+ messages in thread From: Paolo Bonzini @ 2009-06-19 11:56 UTC (permalink / raw) To: 田晓南 Cc: gcc, 'Peng Zheng', thomas.liau, 'Ian Lance Taylor', 'Michael Hope' [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=GB2312, Size: 872 bytes --] ÌïÏþÄÏ wrote: > Hello, guys: > The porting is really a difficult and huge job. So many things I > don't know or miss result in countless bugs. It should not be hard. You have to tell us however why this is unrecognizable, that is, what would be the "closest" recognizable insn supported by your port. > (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)) Also: 1) does your machine use cc0? 2) what pass is producing those subregs? 3) what is your definition of GO_IF_LEGITIMATE_ADDRESS? [I trimmed a bit the list of recipients, sending to the mailing list is usually enough.] Paolo ^ permalink raw reply [flat|nested] 14+ messages in thread
* re: How to deal with unrecognizable RTL code 2009-06-19 11:56 ` Paolo Bonzini @ 2009-06-24 9:35 ` daniel.tian 2009-06-24 9:36 ` Dave Korn 0 siblings, 1 reply; 14+ messages in thread From: daniel.tian @ 2009-06-24 9:35 UTC (permalink / raw) To: 'Paolo Bonzini'; +Cc: gcc, 'Peng Zheng' Hi: >> 1) does your machine use cc0? No. In my RISC chip, there is a status register existed, like ARM. But I now I didn't write any code to support it, as well as absent cc0 register. >> 2) what pass is producing those subregs? This is really puzzled me. I just wrote the PROMOTE_MODE like MIPS. >> 3) what is your definition of GO_IF_LEGITIMATE_ADDRESS? Here is my definition of GO_IF_LEGITIMATE_ADDRESS: #ifndef REG_OK_STRICT #define RICE_REG_STRICT_P 0 #else /* REG_OK_STRICT */ #define RICE_REG_STRICT_P 1 #endif /* REG_OK_STRICT */ #define GO_IF_LEGITIMATE_ADDRESS(mode,x,label) \ {\ if (rice_go_if_legitimate_address(mode, x, RICE_REG_STRICT_P))\ goto label;\ } int rice_go_if_legitimate_address(enum machine_mode mode,rtx X, int bIsStrict) { rtx op1,op2; enum rtx_code code = GET_CODE (X); //(Rmem) #4/2/1 -PRI/PRD/POI/POD if ((code == PRE_INC || code == PRE_DEC) && (GET_MODE_SIZE (mode) <= 4)) { rtx op1; op1=XEXP(X, 0); if(GET_CODE(op1) == REG) return is_base_reg_strict(REGNO(op1)); else return RICE_NO; } //(Rmem) {Rx, #UImm8} -PRI/PRD/POI/POD -W if ((code == POST_MODIFY || code == PRE_MODIFY) && rice_reg_ok_for_base (XEXP (X, 0), bIsStrict) && GET_CODE (XEXP (X, 1)) == PLUS && rtx_equal_p (XEXP (XEXP (X, 1), 0), XEXP (X, 0))) { rtx addend = XEXP (XEXP (X, 1), 1); return (rice_if_legitimate_index (mode, addend, bIsStrict)); } if(GET_CODE(X) == PLUS) { //check where the form is like (Rmem) {Rx, #UImm8} return rice_base_index_address(X, bIsStrict); } return RICE_NO; } BTY: the address mode in my RISC chip is like the following: LOADW Rd (Rs) Rx/offset(8bits unsigned immediate) Which means Rd = (Rs + Rx) 0r Rd = (Rs + imm_8bits). So if the immediate offset is larger than 255, it should be move into register first. I think this definition in my port is appropriate. Any advice? >> [I trimmed a bit the list of recipients, sending to the mailing list is usually enough.] Ok, I gotta it and will keep attention in future. Thanks! _______________________________________________ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-24 9:35 ` daniel.tian @ 2009-06-24 9:36 ` Dave Korn 2009-06-24 9:37 ` Paolo Bonzini 0 siblings, 1 reply; 14+ messages in thread From: Dave Korn @ 2009-06-24 9:36 UTC (permalink / raw) To: daniel.tian; +Cc: 'Paolo Bonzini', gcc, 'Peng Zheng' daniel.tian wrote: >>> 2) what pass is producing those subregs? > This is really puzzled me. I just wrote the PROMOTE_MODE like MIPS. > Any advice? Turn on the RTL dump files and see where the subregs first appear? My guess would be reload, but let's find out. cheers, DaveK ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-24 9:36 ` Dave Korn @ 2009-06-24 9:37 ` Paolo Bonzini 2009-06-24 10:16 ` Dave Korn 0 siblings, 1 reply; 14+ messages in thread From: Paolo Bonzini @ 2009-06-24 9:37 UTC (permalink / raw) To: Dave Korn; +Cc: daniel.tian, 'Paolo Bonzini', gcc, 'Peng Zheng' Dave Korn wrote: > daniel.tian wrote: > >>>> 2) what pass is producing those subregs? >> This is really puzzled me. I just wrote the PROMOTE_MODE like MIPS. > >> Any advice? > > Turn on the RTL dump files and see where the subregs first appear? Yes, that's waht I meant. Paolo ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-24 9:37 ` Paolo Bonzini @ 2009-06-24 10:16 ` Dave Korn 0 siblings, 0 replies; 14+ messages in thread From: Dave Korn @ 2009-06-24 10:16 UTC (permalink / raw) To: Paolo Bonzini Cc: Dave Korn, daniel.tian, 'Paolo Bonzini', gcc, 'Peng Zheng' Paolo Bonzini wrote: > Dave Korn wrote: >> daniel.tian wrote: >> >>>>> 2) what pass is producing those subregs? >>> This is really puzzled me. I just wrote the PROMOTE_MODE like MIPS. >>> Any advice? >> Turn on the RTL dump files and see where the subregs first appear? > > Yes, that's waht I meant. > > Paolo We should probably also take a look at the movhi pattern(s) while we're at it. cheers, DaveK ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-19 8:08 How to deal with unrecognizable RTL code 田晓南 2009-06-19 11:56 ` Paolo Bonzini @ 2009-06-25 18:43 ` Jeff Law 2009-06-29 10:40 ` 答复: " daniel.tian ` (2 more replies) 1 sibling, 3 replies; 14+ messages in thread From: Jeff Law @ 2009-06-25 18:43 UTC (permalink / raw) To: 田晓南 Cc: gcc, 'Peng Zheng', thomas.liau, 'Ian Lance Taylor', 'Michael Hope', 'Joern Rennecke' [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=GB2312, Size: 1913 bytes --] ÌïÏþÄÏ wrote: > Hello, guys: > The porting is really a difficult and huge job. So many things I > don't know or miss result in countless bugs. > Definitely true. Though it gets easier the 2nd, 3rd, 4th, time around :-) > > 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)) > 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. > > (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))) > 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. Jeff ^ permalink raw reply [flat|nested] 14+ messages in thread
* 答复: How to deal with unrecognizable RTL code 2009-06-25 18:43 ` Jeff Law @ 2009-06-29 10:40 ` daniel.tian 2009-07-01 1:57 ` Jeff Law 2009-06-29 10:52 ` daniel.tian 2009-06-30 14:22 ` daniel.tian 2 siblings, 1 reply; 14+ messages in thread From: daniel.tian @ 2009-06-29 10:40 UTC (permalink / raw) To: 'Jeff Law' Cc: gcc, 'Peng Zheng', thomas.liau, 'Ian Lance Taylor', 'Michael Hope', 'Joern Rennecke' 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 答复: How to deal with unrecognizable RTL code 2009-06-29 10:40 ` 答复: " daniel.tian @ 2009-07-01 1:57 ` Jeff Law 0 siblings, 0 replies; 14+ messages in thread From: Jeff Law @ 2009-07-01 1:57 UTC (permalink / raw) To: daniel.tian Cc: gcc, 'Peng Zheng', thomas.liau, 'Ian Lance Taylor', 'Michael Hope', 'Joern Rennecke' daniel.tian wrote: > > > >> 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?? > I wouldn't worry too much about that insn, it's a nop move and will be eliminated. However... > The following RTL insn is right which means storing R5 register to a > specific memory location. > Which means that reg 91 was spilled (ie, it did not get a hard register assigned). You can verify this by looking at reg_equiv_mem[91] just before this loop in reload1.c: /* This loop scans the entire function each go-round and repeats until one repetition spills no additional hard regs. */ for (;;) Presumably reload then replaced reg91 with its equivalent memory location in insn 20, thus giving you the somewhat strange looking (mem (plus (mem (...)). This is normal behaviour so far. Presumably your port rejects (plus (mem (...)) in GO_IF_LEGITIMATE_ADDRESS? You'll probably want to put a breakpoint at this point in reload1.c: /* Now eliminate all pseudo regs by modifying them into their equivalent memory references. The REG-rtx's for the pseudos are modified in place, so all insns that used to refer to them now refer to memory. For a reg that has a reg_equiv_address, all those insns were changed by reloading so that no insns refer to it any longer; but the DECL_RTL of a variable decl may refer to it, and if so this causes the debugging info to mention the variable. */ When you hit that breakpoint look at insn 20. If it still references reg91, then reload thinks that (plus (mem (...))) is a valid address, most likely due to a botched GO_IF_LEGITIMATE_ADDRESS macro. Jeff ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re:How to deal with unrecognizable RTL code 2009-06-25 18:43 ` Jeff Law 2009-06-29 10:40 ` 答复: " daniel.tian @ 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 2 siblings, 2 replies; 14+ messages in thread From: daniel.tian @ 2009-06-29 10:52 UTC (permalink / raw) To: 'Jeff Law'; +Cc: gcc, 'Peng Zheng', thomas.liau Hi, I check the MIPS and ARM, both those cc1 files opened in Insight debug tool contain the mips.md and arm.md file. It is convenient while break point can be set in it. My port md file doesn't appear in the insight. How can I make it? _______________________________________________ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-29 10:52 ` daniel.tian @ 2009-06-29 21:11 ` Ian Lance Taylor 2009-06-30 6:20 ` Jim Wilson 1 sibling, 0 replies; 14+ messages in thread From: Ian Lance Taylor @ 2009-06-29 21:11 UTC (permalink / raw) To: daniel.tian; +Cc: 'Jeff Law', gcc, 'Peng Zheng', thomas.liau "daniel.tian" <daniel.tian@mavrixtech.com.cn> writes: > I check the MIPS and ARM, both those cc1 files opened in Insight debug tool > contain the mips.md and arm.md file. It is convenient while break point can > be set in it. > My port md file doesn't appear in the insight. You seem to be asking a question about Insight rather than about gcc. I haven't used Insight in a long time, but when I use gdb it knows about the .md file (e.g., "list CPU.md:1" works). So I think this question would be better directed to Insight users. Ian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-29 10:52 ` daniel.tian 2009-06-29 21:11 ` How " Ian Lance Taylor @ 2009-06-30 6:20 ` Jim Wilson 1 sibling, 0 replies; 14+ messages in thread From: Jim Wilson @ 2009-06-30 6:20 UTC (permalink / raw) To: daniel.tian; +Cc: 'Jeff Law', gcc, 'Peng Zheng', thomas.liau daniel.tian wrote: > Hi, > I check the MIPS and ARM, both those cc1 files opened in Insight debug tool > contain the mips.md and arm.md file. It is convenient while break point can > be set in it. > My port md file doesn't appear in the insight. The mips.md and arm.md file end up in the debug info because they contain C code segments that get copied into the insn-*.c files. If you look at these insn-*.c files, you will see things like (copied from i386 port) > #line 1310 "../../gcc/gcc/config/i386/i386.md" which causes debug info to be generated that includes a reference to this file. If you have a very simple port, you might not have any such cases like this. Without this debug info, Insight (aka gdbtk) won't be able to show the files. Or something could be broken in your port. Jim ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: How to deal with unrecognizable RTL code 2009-06-25 18:43 ` Jeff Law 2009-06-29 10:40 ` 答复: " daniel.tian 2009-06-29 10:52 ` daniel.tian @ 2009-06-30 14:22 ` daniel.tian 2009-07-01 2:05 ` Jeff Law 2 siblings, 1 reply; 14+ messages in thread From: daniel.tian @ 2009-06-30 14:22 UTC (permalink / raw) To: 'Jeff Law'; +Cc: gcc > 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. > Exactly, But how do I prevent it, replacing a pseudo with an equivalent memory location, happening. Daniel Tian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to deal with unrecognizable RTL code 2009-06-30 14:22 ` daniel.tian @ 2009-07-01 2:05 ` Jeff Law 0 siblings, 0 replies; 14+ messages in thread From: Jeff Law @ 2009-07-01 2:05 UTC (permalink / raw) To: daniel.tian; +Cc: gcc daniel.tian wrote: >> 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. >> >> > Exactly, But how do I prevent it, replacing a pseudo with an equivalent > memory location, happening. > I'd start by looking at your GO_IF_LEGITIMATE_ADDRESS macro and/or trace find_reloads for the problematic insn. jeff ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-07-01 2:05 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-06-19 8:08 How to deal with unrecognizable RTL code 田晓南 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 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
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).