Address mode offset spill

Address mode offset spill

[daniel tian]

Hi your guys:
There is a problem I encountered. I port gcc to 32bit RISC. The
LOAD/STORE only has 8bit displacement. If the immediate displacement
larger than 256, the displacement must be force into register. In
addition, if the immediate is larger than 512, it can only move into
one specified register R0.

Like:

LW  R2  (R1)  #252 ;;  means R2 = Mem(R1 + 255)

LW R2  (R1)  #508;;   it is wrong. immediate 508 should force into
register first.


LW R2  (R1)  #0x500;; it is wrong, immediate 0x500 should force into
register R0 first.

Now, for immediate movement, it is achieved to move large immediate.
But I don't know how to make the address mode legitimate. Now I try to
add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
cc1 still crashed, when the frame size is larger than 255. Do I miss
something?

Any suggestion is appreciated.
Thank you for your guys.

                                                          Daniel.tian

Re: Address mode offset spill

[Alexandre Oliva]

On Jun 14, 2009, daniel tian <daniel.xntian@gmail.com> wrote:

> Now, for immediate movement, it is achieved to move large immediate.
> But I don't know how to make the address mode legitimate. Now I try to
> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
> cc1 still crashed, when the frame size is larger than 255. Do I miss
> something?

One common source of this kind of error is prologue/epilogue expanders.
Since they run after reload, they must emit valid instructions to
save/restore registers and to adjust the stack and frame pointers.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

Re: Address mode offset spill

[Ian Lance Taylor]

daniel tian <daniel.xntian@gmail.com> writes:

> There is a problem I encountered. I port gcc to 32bit RISC. The
> LOAD/STORE only has 8bit displacement. If the immediate displacement
> larger than 256, the displacement must be force into register. In
> addition, if the immediate is larger than 512, it can only move into
> one specified register R0.
>
> Like:
>
> LW  R2  (R1)  #252 ;;  means R2 = Mem(R1 + 255)
>
> LW R2  (R1)  #508;;   it is wrong. immediate 508 should force into
> register first.
>
>
> LW R2  (R1)  #0x500;; it is wrong, immediate 0x500 should force into
> register R0 first.
>
> Now, for immediate movement, it is achieved to move large immediate.
> But I don't know how to make the address mode legitimate. Now I try to
> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
> cc1 still crashed, when the frame size is larger than 255. Do I miss
> something?

I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
debug that.

Ian

Re: Address mode offset spill

[Jeff Law]

Ian Lance Taylor wrote:
> daniel tian <daniel.xntian@gmail.com> writes:
>
>   
>> There is a problem I encountered. I port gcc to 32bit RISC. The
>> LOAD/STORE only has 8bit displacement. If the immediate displacement
>> larger than 256, the displacement must be force into register. In
>> addition, if the immediate is larger than 512, it can only move into
>> one specified register R0.
>>
>> Like:
>>
>> LW  R2  (R1)  #252 ;;  means R2 = Mem(R1 + 255)
>>
>> LW R2  (R1)  #508;;   it is wrong. immediate 508 should force into
>> register first.
>>
>>
>> LW R2  (R1)  #0x500;; it is wrong, immediate 0x500 should force into
>> register R0 first.
>>
>> Now, for immediate movement, it is achieved to move large immediate.
>> But I don't know how to make the address mode legitimate. Now I try to
>> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
>> cc1 still crashed, when the frame size is larger than 255. Do I miss
>> something?
>>     
>
> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
> TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
> debug that.
>   
LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this -- 
LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific approaches 
for reloading can generate more efficient code than the generic code in 
reload.   The generic code should be producing correct, though 
potentially inefficient code.

I do agree that the target is going to need secondary reload support.

jeff

Re: Address mode offset spill

[Ian Lance Taylor]

Jeff Law <law@redhat.com> writes:

>> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
>> TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
>> debug that.
>>   
> LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this -- 
> LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific
> approaches for reloading can generate more efficient code than the
> generic code in reload.   The generic code should be producing
> correct, though potentially inefficient code.

I will just note that this is a long-standing point of disagreement
between Jeff and me.

Ian

Re: Address mode offset spill

[Jeff Law]

Ian Lance Taylor wrote:
> Jeff Law <law@redhat.com> writes:
>
>   
>>> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
>>> TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
>>> debug that.
>>>   
>>>       
>> LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this -- 
>> LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific
>> approaches for reloading can generate more efficient code than the
>> generic code in reload.   The generic code should be producing
>> correct, though potentially inefficient code.
>>     
>
> I will just note that this is a long-standing point of disagreement
> between Jeff and me.
>   
True.  But in this specific case we're talking about an out of range 
offset that requires a specific register for the secondary reload.  
That's a case reload should already be handling correctly.
> Ian
>   

Re: Address mode offset spill

[daniel tian]

Hi, your guys:

Here is the cc1 the notation cc1 crashed:

mvx_audio_dec_mp3_test.c:112: error: unable to find a register to
spill in class 'R0_REG'
mvx_audio_dec_mp3_test.c:112: error: this is the insn:
(insn 185 134 133 6 (set (reg/f:SI 4 R4 [101])
        (const_int 2076 [0x81c])) 4 {load_imm_low_si} (nil)
    (expr_list:REG_EQUIV (const_int 2076 [0x81c])
        (nil)))

PS: there are 16 general registers in my RISC chip, from R0 to R15.
R14, and R15 are used for FP,SP. R0 register is special.
Every large immediate, larger than 512, must be moved into R0
register, which means that R0 is the only register to load large
immediate.
This is a thorny problem.

I have traced the rtl code, and RTL code was combined from two rtl
instructions(R14 is Frame pointer register):

(insn 129 127 168 6 (set (reg:SI 88)
        (const_int 2064 [0x810])) 4 {load_imm_low_si} (nil)
    (nil))

(insn 168 129 131 6 (set (reg/f:SI 101)
        (plus:SI (reg/f:SI 14 R14)
            (const_int 12 [0xc]))) 45 {rice_addsi3} (nil)
    (nil))

(insn 133 131 134 6 (set (reg:SI 4 R4)
        (plus:SI (reg/f:SI 101)
            (reg:SI 88))) 45 {rice_addsi3} (nil)
    (expr_list:REG_EQUAL (plus:SI (reg/f:SI 14 R14)
            (const_int 2076 [0x81c]))
        (nil)))

So before cc1 crashed, the unrecognized insn doesn't go through the
LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS macro.
Is there any solution I can handle the similar problems?

And the following code is what I wrote in macro
LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS:

#define LEGITIMIZE_RELOAD_ADDRESS(X,MODE,OPNUM,TYPE,IND_LEVELS,WIN)		\
{	\
	if(rice_legitimize_reload_address(&X,MODE,OPNUM,TYPE,IND_LEVELS))	\
		goto WIN;	\
}

/*constant value like immediate larger than 512,
 *symbol_ref, label_ref, should be moved into R0 register*/
#define PREFERRED_RELOAD_CLASS(X, CLASS)  rice_preferred_reload_class(X, CLASS)


enum reg_class rice_preferred_reload_class (rtx x, enum reg_class class)
{
	if((GET_CODE(x) == SYMBOL_REF) ||
	   (GET_CODE(x) == LABEL_REF) ||
	   (GET_CODE(x) == CONST) ||
	   ((GET_CODE(x) == CONST_INT) && (!Bit10_constant_operand(x, GET_MODE(x)))))
	{
		return R0_REG;
	}
  	return class;
}

bool rice_legitimize_reload_address(rtx* x,
				 enum machine_mode mode ATTRIBUTE_UNUSED,
				 int opnum, int type,
				 int ind_levels ATTRIBUTE_UNUSED)
{
	printf("Come to rice_legitimize_reload_address! \n");
	if((GET_CODE(*x) == SYMBOL_REF) ||
	   (GET_CODE(*x) == LABEL_REF) ||
	   (GET_CODE(*x) == CONST) ||
	   ((GET_CODE(*x) == CONST_INT) && (!Bit10_constant_operand(*x,
GET_MODE(*x)))))
	{
#ifdef DEBUG_RICE_GCC
		printf("Come to rice_legitimize_reload_address: R0 Reload! \n");
#endif
		push_reload (*x, NULL_RTX, x, NULL,
		   R0_REG, GET_MODE (*x), GET_MODE (*x), 0, 0,
		   opnum, type);
      	return RICE_YES;
	}
	// We must re-recognize what we created before.  		
	if (GET_CODE (*x) == PLUS						
	   && (GET_MODE_SIZE (mode) == 4)	
	   && GET_CODE (XEXP (*x, 0)) == PLUS				
	   && GET_CODE (XEXP (XEXP (*x, 0), 1)) == CONST_INT		
	   && rice_reg_ok_for_base (XEXP (XEXP (*x, 0), 0), 1)		
	   && GET_CODE (XEXP (*x, 1)) == CONST_INT)			
    {									
	    rtx sum;
#ifdef DEBUG_RICE_GCC
		printf("Come to rice_legitimize_reload_address: Offset re-recognize! \n");
#endif
		push_reload (XEXP ((*x), 0), NULL_RTX, &XEXP ((*x), 0), NULL,	
					BASE_REG_CLASS, GET_MODE (*x), VOIDmode, 0, 0,
					(opnum), (type));
		sum = XEXP (*x, 0);
		sum = XEXP (*x, 1);
		sum = XEXP(XEXP (*x, 0), 0);
		sum = XEXP(XEXP (*x, 0), 1);
		return RICE_YES;								
    }		
	//Offset >= 256
	if (GET_CODE (*x) == PLUS						
		&& GET_MODE_SIZE (mode) == 4	
		&& (GET_CODE (XEXP (*x, 1)) == CONST_INT && INTVAL(XEXP (*x, 1)) > 255)				
		&& rice_reg_ok_for_base (XEXP (*x, 0), 0))	
    {									
		rtx index_rtx = XEXP (*x, 1);					
		HOST_WIDE_INT high_part, low_part, offset = INTVAL (index_rtx);		
		rtx sum;								
#ifdef DEBUG_RICE_GCC
		printf("Come to rice_legitimize_reload_address: Offset %d ! \n", offset);
#endif
							
		high_part = offset & (~0xFF);
		low_part  = offset & (0xFF);
		
		sum = gen_rtx_PLUS (Pmode, XEXP (*x, 0), GEN_INT (high_part));			
		*x = gen_rtx_PLUS (Pmode, sum, GEN_INT (low_part));
		//Reload
		push_reload (XEXP (*x, 0), NULL_RTX, &XEXP (*x, 0), NULL,		
					 BASE_REG_CLASS, GET_MODE (*x), VOIDmode, 0, 0, (opnum), (type));
		sum = XEXP (*x, 0);
		sum = XEXP (*x, 1);
		sum = XEXP(XEXP (*x, 0), 0);
		sum = XEXP(XEXP (*x, 0), 1);
		return RICE_YES;							
									
    }									
			
	return RICE_NO;
}

I have a few questions.
1 It will split the immediate offset being larger than 255 into pieces
,a  high part and a low part., right? But how to deal with the high
part, especially, when it is still larger than 255.
  Used the above code, will the larger immediate be force into R0
register, and finally generate the right addess code?

2. similar problem, I have define the LEGITIMIZE_RELOAD_ADDRESS and
PREFERRED_RELOAD_CLASS macro. Does the code will take effect to force
the large immediate, symbol and CONST into R0_REG?
   I mean whether I have wrote the right code. Because I found cc1
still crash to allocate the R0 register.

Thank you for your guys advices.



Daniel.Tian

2009/6/16 Jeff Law <law@redhat.com>:
> Ian Lance Taylor wrote:
>>
>> Jeff Law <law@redhat.com> writes:
>>
>>
>>>>
>>>> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
>>>> TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
>>>> debug that.
>>>>
>>>
>>> LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this --
>>> LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific
>>> approaches for reloading can generate more efficient code than the
>>> generic code in reload.   The generic code should be producing
>>> correct, though potentially inefficient code.
>>>
>>
>> I will just note that this is a long-standing point of disagreement
>> between Jeff and me.
>>
>
> True.  But in this specific case we're talking about an out of range offset
> that requires a specific register for the secondary reload.  That's a case
> reload should already be handling correctly.
>>
>> Ian
>>
>
>

Re: Address mode offset spill

[Ian Lance Taylor]

daniel tian <daniel.xntian@gmail.com> writes:

> mvx_audio_dec_mp3_test.c:112: error: unable to find a register to
> spill in class 'R0_REG'
> mvx_audio_dec_mp3_test.c:112: error: this is the insn:
> (insn 185 134 133 6 (set (reg/f:SI 4 R4 [101])
>         (const_int 2076 [0x81c])) 4 {load_imm_low_si} (nil)
>     (expr_list:REG_EQUIV (const_int 2076 [0x81c])
>         (nil)))
>
> PS: there are 16 general registers in my RISC chip, from R0 to R15.
> R14, and R15 are used for FP,SP. R0 register is special.
> Every large immediate, larger than 512, must be moved into R0
> register, which means that R0 is the only register to load large
> immediate.

One thing you certainly need to do is set REG_ALLOC_ORDER so that r0 is
the last register allocated.


> I have traced the rtl code, and RTL code was combined from two rtl
> instructions(R14 is Frame pointer register):
>
> (insn 129 127 168 6 (set (reg:SI 88)
>         (const_int 2064 [0x810])) 4 {load_imm_low_si} (nil)
>     (nil))
>
> (insn 168 129 131 6 (set (reg/f:SI 101)
>         (plus:SI (reg/f:SI 14 R14)
>             (const_int 12 [0xc]))) 45 {rice_addsi3} (nil)
>     (nil))
>
> (insn 133 131 134 6 (set (reg:SI 4 R4)
>         (plus:SI (reg/f:SI 101)
>             (reg:SI 88))) 45 {rice_addsi3} (nil)
>     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 14 R14)
>             (const_int 2076 [0x81c]))
>         (nil)))

You need to set TARGET_RTX_COSTS so that constants larger than 512 are
more expensive than registers.  That should prevent the constant from
being propagated into the insn.


> So before cc1 crashed, the unrecognized insn doesn't go through the
> LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS macro.
> Is there any solution I can handle the similar problems?

You're right, for a pure load like this, you will need a secondary
reload.

Ian

Re: Address mode offset spill

[daniel tian]

>
> One thing you certainly need to do is set REG_ALLOC_ORDER so that r0 is
> the last register allocated.
>
> You need to set TARGET_RTX_COSTS so that constants larger than 512 are
> more expensive than registers.  That should prevent the constant from
> being propagated into the insn.

Yeah. I 've already done it in macro  REG_ALLOC_ORDER and TARGET_RTX_COSTS .



>
>
> > So before cc1 crashed, the unrecognized insn doesn't go through the
> > LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS macro.
> > Is there any solution I can handle the similar problems?
>
> You're right, for a pure load like this, you will need a secondary
> reload.
>
> Ian

you mean in Target hook "TARGET_SECONDARY_RELOAD"?  This is what I
haven't done yet. I will write it and try again.


Thank you very much.


    daniel

Re: Address mode offset spill

[daniel tian]

2009/6/16 Jeff Law <law@redhat.com>:
> Ian Lance Taylor wrote:
>>
>> daniel tian <daniel.xntian@gmail.com> writes:
>>
>>
>>>
>>> There is a problem I encountered. I port gcc to 32bit RISC. The
>>> LOAD/STORE only has 8bit displacement. If the immediate displacement
>>> larger than 256, the displacement must be force into register. In
>>> addition, if the immediate is larger than 512, it can only move into
>>> one specified register R0.
>>>
>>> Like:
>>>
>>> LW  R2  (R1)  #252 ;;  means R2 = Mem(R1 + 255)
>>>
>>> LW R2  (R1)  #508;;   it is wrong. immediate 508 should force into
>>> register first.
>>>
>>>
>>> LW R2  (R1)  #0x500;; it is wrong, immediate 0x500 should force into
>>> register R0 first.
>>>
>>> Now, for immediate movement, it is achieved to move large immediate.
>>> But I don't know how to make the address mode legitimate. Now I try to
>>> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
>>> cc1 still crashed, when the frame size is larger than 255. Do I miss
>>> something?
>>>
>>
>> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
>> TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
>> debug that.
>>
>
> LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this --
> LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific approaches for
> reloading can generate more efficient code than the generic code in reload.
>   The generic code should be producing correct, though potentially
> inefficient code.
>
> I do agree that the target is going to need secondary reload support.
>
> jeff
>


You mean before LEGITIMIZE_RELOAD_ADDRESS, cc1 must generate the
correct RTL code, regardless of whether efficient or not.
Take the immediate load for instance, should  I generate the the right
code in "movm" expander? I mean ,first the larger immediate data will
move into a pseduo register, then I insert a RTL code, first move to
R0, then R0 move to the pseduo register. Right?

Now I just force the larger immedate into a register, and let the
reload to move the immediate into R0 register.

Re: Address mode offset spill

[daniel tian]

Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
before I add the second_reload macro. There are two problems happened.
1. there is a RTL code which move the memory data to another memory
location. RTL extracted  from file *.23.greg :

(insn 128 127 130 7 (set (mem/i:SI (plus:SI (reg/f:SI 14 R14)
                (const_int 28 [0x1c])) [0 nChannels+0 S4 A32])
        (mem:SI (plus:SI (reg/f:SI 14 R14)
                (const_int 11372 [0x2c6c])) [0 iftmp.0+0 S4 A32])) 8
{store_si} (nil)
    (nil))

this is not allowed in my RISC chip. And This doesn't go through the
reload  macro. Is this need to solve in secondary reload?

2. Here is the RTL code in file *.23.greg:
(insn:HI 112 218 105 4 (set (reg:SI 5 R5 [78])
        (plus:SI (reg:SI 7 R7)
            (const_int 2064 [0x810]))) 45 {rice_addsi3}
(insn_list:REG_DEP_TRUE 161 (insn_list:REG_DEP_TRUE 73
(insn_list:REG_DEP_ANTI 79 (nil))))
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 R14)
            (const_int 2076 [0x81c]))
        (nil)))

which is not legal in my risc chip. In MD file, I 've already defined
the addsi instruction pattern which only allows the 2nd operand with
less than 512. I don't know how did this happen. I mean I do know this
RTL comes from gcc optimization combination, but how it , which should
be an unrecognizable RTL, becomes recognizable  RTL. Does it also need
the secondary reload macro to handle?

And last question, resulted from my gcc4.0.2 porting version, there is
still no TARGET_SECONDARY RELOAD target hook existance. So I should
achieve it with the macro SECONDARY_RELOAD_CLASS,
SECONDARY_INPUT/OUTPUT_RELOAD_CLASS.  Can anybody give me a hint about
what 's distinction between SECONDARY_RELOAD_CLASS, and
SECONDARY_INPUT/OUTPUT_RELOAD_CLASS.

Any suggestion is appreciated.

Thank you again for your guys helping me so much.  Thank you.


Daniel. Tian

Re: Address mode offset spill

[Ian Lance Taylor]

daniel tian <daniel.xntian@gmail.com> writes:

> Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
> before I add the second_reload macro. There are two problems happened.
> 1. there is a RTL code which move the memory data to another memory
> location. RTL extracted  from file *.23.greg :
>
> (insn 128 127 130 7 (set (mem/i:SI (plus:SI (reg/f:SI 14 R14)
>                 (const_int 28 [0x1c])) [0 nChannels+0 S4 A32])
>         (mem:SI (plus:SI (reg/f:SI 14 R14)
>                 (const_int 11372 [0x2c6c])) [0 iftmp.0+0 S4 A32])) 8
> {store_si} (nil)
>     (nil))
>
> this is not allowed in my RISC chip. And This doesn't go through the
> reload  macro. Is this need to solve in secondary reload?

This kind of thing will be generated during reload, but should be
cleaned up during reload.  If it is not, it suggests that perhaps you
are not checking REG_OK_STRICT as required, or that your predicates or
constraints are wrong.  Or there may be some other explanation.


> 2. Here is the RTL code in file *.23.greg:
> (insn:HI 112 218 105 4 (set (reg:SI 5 R5 [78])
>         (plus:SI (reg:SI 7 R7)
>             (const_int 2064 [0x810]))) 45 {rice_addsi3}
> (insn_list:REG_DEP_TRUE 161 (insn_list:REG_DEP_TRUE 73
> (insn_list:REG_DEP_ANTI 79 (nil))))
>     (expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 R14)
>             (const_int 2076 [0x81c]))
>         (nil)))
>
> which is not legal in my risc chip. In MD file, I 've already defined
> the addsi instruction pattern which only allows the 2nd operand with
> less than 512. I don't know how did this happen. I mean I do know this
> RTL comes from gcc optimization combination, but how it , which should
> be an unrecognizable RTL, becomes recognizable  RTL. Does it also need
> the secondary reload macro to handle?

The insn was recognized as rice_addsi3, so take a good look at that insn
and make sure the predicates and constraints reject the 2064.


> And last question, resulted from my gcc4.0.2 porting version, there is
> still no TARGET_SECONDARY RELOAD target hook existance. So I should
> achieve it with the macro SECONDARY_RELOAD_CLASS,
> SECONDARY_INPUT/OUTPUT_RELOAD_CLASS.  Can anybody give me a hint about
> what 's distinction between SECONDARY_RELOAD_CLASS, and
> SECONDARY_INPUT/OUTPUT_RELOAD_CLASS.

Yes, in gcc 4.0.2 you need to use SECONDARY_RELOAD_CLASS.  The docs
explain the difference.  I can't recommend using gcc 4.0.2 as a porting
base; newer versions of gcc will generate better code.

Ian

Re: Address mode offset spill

[Jeff Law]

daniel tian wrote:
>
> You mean before LEGITIMIZE_RELOAD_ADDRESS, cc1 must generate the
> correct RTL code, regardless of whether efficient or not.
>   
The compiler should work with or without defining 
LEGITIMIZE_RELOAD_ADDRESS.   It's often difficult to write a correct 
LEGITIMIZE_RELOAD_ADDRESS without knowing the internals of how reload 
works.  Therefore, I strongly recommend first writing the port without 
LEGITIMIZE_RELOAD_ADDRESS -- after the port is working correctly you can 
go back and add LEGITIMIZE_RELOAD_ADDRESS to generate more efficient code.

> Take the immediate load for instance, should  I generate the the right
> code in "movm" expander? I mean ,first the larger immediate data will
> move into a pseduo register, then I insert a RTL code, first move to
> R0, then R0 move to the pseduo register. Right?
>   
I'm not familiar with your port.  So I would have to start with a question.

Does your target require the constant to be loaded into r0, or is r0 a 
scratch register necessary to synthesize the constant into some other 
register?  The difference is subtle, but important for reload.  For the 
former, you will have a secondary reload that is a intermediate 
register, for the latter, the secondary reload will be a scratch register.


> Now I just force the larger immedate into a register, and let the
> reload to move the immediate into R0 register.
>   
It is generally better to force the large constant into a pseudo rather 
than expose R0 early in RTL generation, so you're doing the right thing 
in this regard.  I think the problem is you haven't defined your 
secondary reloads yet.

jeff

Re: Address mode offset spill

[Jeff Law]

Ian Lance Taylor wrote:
> daniel tian <daniel.xntian@gmail.com> writes:
>
>   
>> Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
>> before I add the second_reload macro. There are two problems happened.
>> 1. there is a RTL code which move the memory data to another memory
>> location. RTL extracted  from file *.23.greg :
>>
>> (insn 128 127 130 7 (set (mem/i:SI (plus:SI (reg/f:SI 14 R14)
>>                 (const_int 28 [0x1c])) [0 nChannels+0 S4 A32])
>>         (mem:SI (plus:SI (reg/f:SI 14 R14)
>>                 (const_int 11372 [0x2c6c])) [0 iftmp.0+0 S4 A32])) 8
>> {store_si} (nil)
>>     (nil))
>>
>> this is not allowed in my RISC chip. And This doesn't go through the
>> reload  macro. Is this need to solve in secondary reload?
>>     
>
> This kind of thing will be generated during reload, but should be
> cleaned up during reload.  If it is not, it suggests that perhaps you
> are not checking REG_OK_STRICT as required, or that your predicates or
> constraints are wrong.  Or there may be some other explanation.
>   
Also note that the secondary reload code needs to handle the case where 
it's passed a pseudo that hasn't been allocated a hard register.  I 
think he can get that code of code if he's not handling those cases 
properly.

However, the most likely cause is reload replacing a pseudo with its 
equivalent memory location and the port incorrectly accepting that form 
as valid, either because of a problem with REG_OK_STRICT, operand 
predicate or constraints, LEGITIMIZE_RELOAD_ADDRESS, etc.


>
>   
>> 2. Here is the RTL code in file *.23.greg:
>> (insn:HI 112 218 105 4 (set (reg:SI 5 R5 [78])
>>         (plus:SI (reg:SI 7 R7)
>>             (const_int 2064 [0x810]))) 45 {rice_addsi3}
>> (insn_list:REG_DEP_TRUE 161 (insn_list:REG_DEP_TRUE 73
>> (insn_list:REG_DEP_ANTI 79 (nil))))
>>     (expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 R14)
>>             (const_int 2076 [0x81c]))
>>         (nil)))
>>
>> which is not legal in my risc chip. In MD file, I 've already defined
>> the addsi instruction pattern which only allows the 2nd operand with
>> less than 512. I don't know how did this happen. I mean I do know this
>> RTL comes from gcc optimization combination, but how it , which should
>> be an unrecognizable RTL, becomes recognizable  RTL. Does it also need
>> the secondary reload macro to handle?
>>     
>
> The insn was recognized as rice_addsi3, so take a good look at that insn
> and make sure the predicates and constraints reject the 2064.
>   
Agreed.   There may be cases where reload generates this as well when 
there's pseudos that don't get hard registers and the pseudos have 
equivalent forms.   These may indicate more cases that will need 
secondary reloads.


Jeff

Re: Address mode offset spill

[Jeff Law]

daniel tian wrote:
> PS: there are 16 general registers in my RISC chip, from R0 to R15.
> R14, and R15 are used for FP,SP. R0 register is special.
> Every large immediate, larger than 512, must be moved into R0
> register, which means that R0 is the only register to load large
> immediate.
> This is a thorny problem.
>   
But not terribly uncommon.

Do you need to synthesize large constants?  ie, what code would you 
generate to load the value 0x12345 into a register?

If you need to synthesize large constants, do you need any additional 
scratch registers, or can you do so using just r0?


jeff

Re: Address mode offset spill

[daniel tian]

> But not terribly uncommon.
>
> Do you need to synthesize large constants?  ie, what code would you generate
> to load the value 0x12345 into a register?
>
> If you need to synthesize large constants, do you need any additional
> scratch registers, or can you do so using just r0?
>
Only do using R0.  Like the following with loading 0x12345:

MOVI   0x2345  -L           //To load the lower 16bit data
MOVI   0x1       -H          //Load the up 16bit data

The destination register must only be R0 register, which is determined
by the hardware. R0 is also general register which can be used in all
operation instructions like ADD, Subtract, Multiply and LOAD/STORE.

Now my approach is to define the Macro PREFERRED_RELOAD_CLASS(X,
CLASS), and make sure if the X is const int and larger than 512, it
will return the R0_REG register class.
PS: I think that if I don't define the macro LEGITIMIZE_RELOAD_ADDRESS
which will push reload the larger const int, the
PREFERRED_RELOAD_CLASS won't be called. is  it right?


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: Address mode offset spill

[daniel tian]

>
> The compiler should work with or without defining LEGITIMIZE_RELOAD_ADDRESS.
>   It's often difficult to write a correct LEGITIMIZE_RELOAD_ADDRESS without
> knowing the internals of how reload works.  Therefore, I strongly recommend
> first writing the port without LEGITIMIZE_RELOAD_ADDRESS -- after the port
> is working correctly you can go back and add LEGITIMIZE_RELOAD_ADDRESS to
> generate more efficient code.
>

Do you mean that I should not write any reload code including
secondary reload? And if it is going to work fine, then keep working
on reload part?

You give a direction. I will do it.

^_^

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: Address mode offset spill

[Jeff Law]

daniel tian wrote:
> Only do using R0.  Like the following with loading 0x12345:
>
> MOVI   0x2345  -L           //To load the lower 16bit data
> MOVI   0x1       -H          //Load the up 16bit data
>   
OK. So it appears to me like R0 needs to be an intermediate secondary
reload for register anytime you have a load of a large constant integer
into any class other than R0_REGS (I'm assuming you've put R0 into its
own class, which would normally be named R0_REGS).


> Now my approach is to define the Macro PREFERRED_RELOAD_CLASS(X,
> CLASS), and make sure if the X is const int and larger than 512, it
> will return the R0_REG register class.
>   
That will certainly help, but won't be sufficient to handle all the
cases. You still need to define your secondary reload class
macros/functions.
> PS: I think that if I don't define the macro LEGITIMIZE_RELOAD_ADDRESS
> which will push reload the larger const int, the
> PREFERRED_RELOAD_CLASS won't be called. is  it right?
>   
I don't know offhand. If I remember correctly, PREFERRED_RELOAD_CLASS is
another method for optimizing the code -- which means your port should
work with or without PREFERRED_RELOAD_CLASS defined. It also means
there's no guarantee PREFERRED_RELOAD_CLASS will be honored in all cases.


Jeff

Re: Address mode offset spill

[Jeff Law]

daniel tian wrote:
>> The compiler should work with or without defining LEGITIMIZE_RELOAD_ADDRESS.
>>   It's often difficult to write a correct LEGITIMIZE_RELOAD_ADDRESS without
>> knowing the internals of how reload works.  Therefore, I strongly recommend
>> first writing the port without LEGITIMIZE_RELOAD_ADDRESS -- after the port
>> is working correctly you can go back and add LEGITIMIZE_RELOAD_ADDRESS to
>> generate more efficient code.
>>
>>     
>
> Do you mean that I should not write any reload code including
> secondary reload? And if it is going to work fine, then keep working
> on reload part?
>   
You should write your secondary reload code, but not
LEGITIMIZE_RELOAD_ADDRESS.

After your port is working well, then define LEGITIMIZE_RELOAD_ADDRESS
to optimize the code better.

jeff