RE: How to deal with unrecognizable RTL code

Hi, Jeff: Thanks. I fixed the bug. The problem is in GO_IF_LEGITIMATE_ADDRESS. In the reload processing, find_reload function will check the operand address whether it is effective. I traced the function, and found my GO_IF_LEGITIMATE_ADDRESS macro thought the following address is strict legit

Re: How to deal with unrecognizable RTL code

daniel.tian wrote: >> 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 spill

RE: How to deal with unrecognizable RTL code

> 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 reg

Re: How to deal with unrecognizable RTL code

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

RE: How to deal with unrecognizable RTL code

> 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 m

Re: How to deal with unrecognizable RTL code

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 becaus

Re: How to deal with unrecognizable RTL code

"daniel.tian" 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

Re: How to deal with unrecognizable RTL code

daniel tian wrote: > > it will be called in GO_IF_LEGITIMATE_ADDRESS, and > LEGITIMIZE_RELOAD_ADDRESS. So like the following unrecognizable RTL > has gone. > I would _strongly_ recommend you initially develop your port without defining LEGITIMIZE_RELOAD_ADDRESS. Let reload work in the way it was

Re: How to deal with unrecognizable RTL code

田晓南 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

Re: How to deal with unrecognizable RTL code

Hi Dove: > The docs for PROMOTE_MODE suggest using `word_mode'; it may be that on mips, > 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 remov

Re: How to deal with unrecognizable RTL code

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 m

Re: How to deal with unrecognizable RTL code

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

Re: How to deal with unrecognizable RTL code

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

re: How to deal with unrecognizable RTL code

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 MIP

Re: How to deal with unrecognizable RTL code

daniel.tian wrote: > But I have already defined the PROMOTE_MODE which will convert all the > QImode, HImode to SImode in computation. ? That's not what the code you posted says: > PROMOTE_MODE, stolen from mips, is defined in my port: > #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \ > if

re: How to deal with unrecognizable RTL code

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 RT

Re: How to deal with unrecognizable RTL code

田晓南 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 you