re: How to deal with unrecognizable RTL code
>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 田晓南
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 .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 (袁鹏)
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 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.t...@mavrixtech.com.cn
www.mavrixtech.com
答复: How to deal with unrecognizable RTL code
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 .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 .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.t...@mavrixtech.com.cn
www.mavrixtech.com
Re:How to deal with unrecognizable RTL code
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.t...@mavrixtech.com.cn www.mavrixtech.com
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 memory location. > Exactly, But how do I prevent it, replacing a pseudo with an equivalent memory location, happening. Daniel Tian
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 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 > Actually, you are right. I have traced the GO_IF_LEGITIMATE_ADDRESS. I do reject the memory form like (plus (mem (...))). And my Risc do not support the memory reference like this. You mean I should accept the form in GO_IF_LEGITIMATE_ADDRESS macro? Thanks. Daniel. ___ 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
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 legitimate address: mem/s:SI (plus:SI (reg/v/f:SI 91 [ frame ]) (const_int 4 [0x4])) Of course it is not a valid address in strict mode. And a logical error was found in my rice_reg_ok_for_base function. After fixing it, cc1 works well . Thank you very much! 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.t...@mavrixtech.com.cn www.mavrixtech.com
how to optimize address offset assignment
Hi, everyone: The address mode in my my RISC chip is like (BaseReg) + 8bit offset, or (BaseReg) + indexReg. And there a 16 general register from R0 to R15 which can be used as Base register or Index Regster. So you can see that if the frame space is larger than 255, there will be a problem. For a single Load/Store Operation, there should be an additional insn to force the immediate into index register. But this will cause some redundancy code, especially assessing some adjacent area. Like the following code(this is the assemble code generated by my cc1): MOVI#1084 -L ;; Load a immediate to R0 register ADD R5 R0 R14 ;; R14 is regarded as frame pointer STOREH R4 (R5) #0 -PRI ;;load a half word from memory at (R5 + 0). R4 = (R5 + 0) MOVI#1086 -L ADD R4 R0 R14 STOREH R5 (R4) #0 -PRI MOVI#1088 -L ADD R5 R0 R14 STOREH R4 (R5) #0 -PRI You can see the offset loaded three times. But they abut. It can be optimized. I read a paper named ”Optimal Stack Slot Assignment in GCC”. There is an option to enable the stack reorganization. But I didn’t find it in Internal Document. (The SH machine seems to use this method, how do I trigger it?) So I need your guys give me some advices. Thank you very much. ___ 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
