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 LEGITIMI
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 anyt
>
> 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 --
> 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 R
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 thorn
Ian Lance Taylor wrote:
daniel tian 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 *.
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 with
daniel tian 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 12
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:
2009/6/16 Jeff Law :
> Ian Lance Taylor wrote:
>>
>> daniel tian 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
>>>
>
> 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 'v
daniel tian 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_lis
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_lo
Ian Lance Taylor wrote:
Jeff Law 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
Jeff Law 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 spec
Ian Lance Taylor wrote:
daniel tian 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, i
daniel tian 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
>
On Jun 14, 2009, daniel tian 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 la
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 reg
19 matches
Mail list logo
