re: How to deal with unrecognizable RTL code

re: How to deal with unrecognizable RTL code

[daniel.tian]

>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.tian@mavrixtech.com.cn
www.mavrixtech.com
________________________________________
发件人: Paul Yuan [mailto:yingbo.com@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.tian@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.tian@mavrixtech.com.cn
www.mavrixtech.com






-- 
Regards,
Paul Yuan (袁鹏)

Re: How to deal with unrecognizable RTL code

[Dave Korn]

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 (GET_MODE_CLASS (MODE) == MODE_INT         \
>      && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \
>    {                                           \
>      (MODE) = Pmode;                           \
>    }

  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?

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

  Is one of your MD macros not handling the post-reload REG_OK_STRICT macro
correctly perhaps?

    cheers,
      DaveK

RE: How to deal with unrecognizable RTL code

[daniel.tian]

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.tian@mavrixtech.com.cn

www.mavrixtech.com

Re: How to deal with unrecognizable RTL code

[Jeff Law]

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 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?
>   
No, you do not want to accept that form since your target doesn't
support it. I wanted you to verify that GO_IF_LEGITIMATE_ADDRESS was
rejecting that form.

So probably the next step would be to trace find_reloads for your insn
and see what reloads are recorded/performed.

Jeff

RE: How to deal with unrecognizable RTL code

[daniel.tian]

> 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.tian@mavrixtech.com.cn

www.mavrixtech.com

Re: How to deal with unrecognizable RTL code

[Jeff Law]

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

RE: How to deal with unrecognizable RTL code

[daniel.tian]

> 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

[Jim Wilson]

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

Re: How to deal with unrecognizable RTL code

[Ian Lance Taylor]

"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

Re: How to deal with unrecognizable RTL code

[Jeff Law]

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
intended, particularly since I haven't seen anything to-date which would
indicate your chip has characteristics which reload can't handle.

Once your port is working well, you can go back and define
LEGITIMIZE_RELOAD_ADDRESS to optimize handling of reloads -- and because
your port was working prior to defining LEGITIMIZE_RELOAD_ADDRESS any
new failures are most likely due to an improper definition of
LEGITIMIZE_RELOAD_ADDRESS (which is easy to do given you have to know
how reload works to properly implement LEGITIMIZE_RELOAD_ADDRESS).


[ ... ]
>
> 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.
>   
Again, the best thing you can do is find the first dump file where these
problematical insns exist. That would be a huge step forward.

jeff

Re: How to deal with unrecognizable RTL code

[Jeff Law]

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

Re: How to deal with unrecognizable RTL code

[daniel tian]

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 remove the subreg operations.

> 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) != REG && GET_CODE(x) != SUBREG)
		return RICE_NO;
	if(GET_CODE(x) == SUBREG)
	{
		regnum = true_regnum (x);		
	}
	else
		regnum = 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 <variable>.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_<mode>"
	[(set (match_operand:GPR 0 "memory_operand" "=m")
	      (match_operand:GPR 1 "rice_gpr_operand" "r"))]
	"TARGET_RICE"
       {
		return rice_output_move (operands, <MODE>mode);
	}
)

;;Load word
(define_insn "load_<mode>"
	[(set (match_operand:GPR 0 "rice_gpr_operand" "=r")
	      (match_operand:GPR 1 "memory_operand" "m"))]
	"TARGET_RICE"
	 {
		return rice_output_move (operands, <MODE>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 <variable>.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 <variable>.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.

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

Re: How to deal with unrecognizable RTL code

[Dave Korn]

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

Re: How to deal with unrecognizable RTL code

[Paolo Bonzini]

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

[Dave Korn]

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

[daniel.tian]

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

Re: How to deal with unrecognizable RTL code

[Paolo Bonzini]

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

How to deal with unrecognizable RTL code

[田晓南]

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