Add new architechture in gcc build error

[daniel tian]

Hi,
   I have already finished CPU port named RICE.  The previous version
I did is on gcc 4.0.2. it can be compiled.  Now I wanna move it to
v4.3.0.  I added the config script just as the CRX architechture.
   But when run the configure,

export TARGET=rice-elf
export PREFIX=/usr/local/cross/$TARGET
export PATH=$PATH:$PREFIX/bin

rm -fr build-gcc
mkdir build-gcc

cd build-gcc
../rice-gcc-4.3.0/configure --target=$TARGET --prefix=$PREFIX
--enable-languages=c  --without-headers --with-newlib --with-gnu-as
--with-gnu-ld --disable-multilib --disable-libssp

make all 2>&1 | tee build.log



but the error occurred like the following:

checking build system type... i686-pc-linux-gnu
checking host system type... rice-mavrix-elf
checking for rice-elf-ar... /usr/local/cross/rice-elf/rice-elf/bin/ar
checking for rice-elf-lipo... rice-elf-lipo
checking for rice-elf-nm...
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/nm
checking for rice-elf-ranlib... /usr/local/cross/rice-elf/rice-elf/bin/ranlib
checking for rice-elf-strip... /usr/local/cross/rice-elf/rice-elf/bin/strip
checking whether ln -s works... yes
checking for rice-elf-gcc...
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/xgcc
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include
checking for suffix of object files... configure: error: cannot
compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory
`/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug'
make: *** [all] Error 2

I add the script in those files just like the CRX architechture:

I check the config.log, here is error:

configure:2379: $? = 1
configure:2398:
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/xgcc
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include -o conftest -O2 -g
-gdwarf-2 -g3 conftest.c  >&5
conftest.c: In function 'main':
conftest.c:16: internal compiler error: in
compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:2401: $? = 1
configure:2567: checking for suffix of object files
configure:2588:
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/xgcc
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include -c -O2 -g -gdwarf-2 -g3
   conftest.c >&5
conftest.c: In function 'main':
conftest.c:16: internal compiler error: in
compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:2591: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:2605: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

the config.log file is attached in the mail.

Binutils is installed into the computer(Of course it has ported onto RICE).


I search the gcc maillist, but I can't find some useful information.
Can anybody give me some advice.

Thank you very much!


config.log
Description: Binary data

Re: Add new architechture in gcc build error

[daniel tian]

>
> You've got to get in there with gdb and find out why 
> compute_frame_pointer_to_fb_displacement()
> is erroring.  There's no way to avoid this.
>

Thank you.
But I don't know how. I mean which execute file, even I can't find the
"conftest.c" file.

Sorry for asking this simple question.

Re: Add new architechture in gcc build error

[daniel tian]

2009/9/21 sumanth :
> Hi ,
>    Follow this wiki  " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
> debug gcc.
>    As far as I know  compute_frame_pointer_to_fb_displacement is the
> displacement between your
>   frame pointer and the frame base ( mostly stack pointer's location after
> your prologue code - depends on your architecture).
>   You need to tell dwarf how much you are displacing your frame in order to
> fit in your variables and stack pushed registers of a specific function.
>    The above mentioned explanation is my perception ( I am novice too in
> gcc). However  your error might not  be related to it.
>
> The only way you can resolve your issue is by debugging gcc as per the link
> I mentioned.
> Feel free to ask , if any clarifications required.
>  Thanks,
> Sumanth G
>
>

Thank you very much.
I will look into it.  I need to figure out where the "conftest.c" is.
I mean I know how to use the gdb or insight.
But I wonder which execute file I need to run, is the "cc1"?
and to compile the "conftest.c" file with "cc1"?

Any advice is appreciated.

Does everyone port the gcc to a new target alway encounter this
problem, or just the luck hits on me?

Thanks.

Re: Add new architechture in gcc build error

[daniel tian]

2009/9/21 Andrew Haley :
> daniel tian wrote:
>> 2009/9/21 sumanth :
>>> Hi ,
>>>    Follow this wiki  " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
>>> debug gcc.
>>>    As far as I know  compute_frame_pointer_to_fb_displacement is the
>>> displacement between your
>>>   frame pointer and the frame base ( mostly stack pointer's location after
>>> your prologue code - depends on your architecture).
>>>   You need to tell dwarf how much you are displacing your frame in order to
>>> fit in your variables and stack pushed registers of a specific function.
>>>    The above mentioned explanation is my perception ( I am novice too in
>>> gcc). However  your error might not  be related to it.
>>>
>>> The only way you can resolve your issue is by debugging gcc as per the link
>>> I mentioned.
>>
>> Thank you very much.
>> I will look into it.  I need to figure out where the "conftest.c" is.
>
> It's in the first message you sent:
>
> | /* confdefs.h.  */
> |
> | #define PACKAGE_NAME "GNU C Runtime Library"
> | #define PACKAGE_TARNAME "libgcc"
> | #define PACKAGE_VERSION "1.0"
> | #define PACKAGE_STRING "GNU C Runtime Library 1.0"
> | #define PACKAGE_BUGREPORT ""
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
>
>> I mean I know how to use the gdb or insight.
>> But I wonder which execute file I need to run, is the "cc1"?
>> and to compile the "conftest.c" file with "cc1"?
>
> Yes.
>

Thanks.
So it is the simplest program.  I will find the problem..

Thank you again.

Re: Add new architechture in gcc build error

[daniel tian]

Thank you. I fixed the error. it caused by macro:
#define ELIMINABLE_REGS \
{\

 {ARG_POINTER_REGNUM,FRAME_POINTER_REGNUM}, \
 {ARG_POINTER_REGNUM,STACK_POINTER_REGNUM}, \
 {FRAME_POINTER_REGNUM,  STACK_POINTER_REGNUM} \
}

because everytime when gcc check the frame_pointer_need, if it is
false, aim eliminated register is SP.
But in the former array, gcc still got FP. So error accurred.

Now it is OK with the following:
#define ELIMINABLE_REGS \
{\
 {ARG_POINTER_REGNUM,STACK_POINTER_REGNUM}, \
 {ARG_POINTER_REGNUM,FRAME_POINTER_REGNUM}, \
 {FRAME_POINTER_REGNUM,  STACK_POINTER_REGNUM} \
}
just exchange the former two elements.

So thanks for your guys.

libgcc doesn't support my target

[daniel tian]

Hi,

When I build gcc first time this which the configure parameter is like this:

../rice-gcc-4.3.0/configure --target=$TARGET --prefix=$PREFIX
--enable-languages=c  --without-headers --with-newlib --with-gnu-as
--with-gnu-ld --disable-multilib --disable-libssp

Binutils is ok and install in the $PREFIX path.

Error information is like this:

checking for /home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/xgcc
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include option to accept ANSI
C... none needed
checking how to run the C preprocessor...
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/xgcc
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include -E
checking whether decimal floating point is supported... no
checking whether fixed-point is supported... no
*** Configuration rice-mavrix-elf not supported
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory
`/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc'
make: *** [all] Error 2

 rice-mavrix-elf :  rice is my target name.
I search the configure in libgcc, there is no target information. And
I check the CRX port, it also didn't add more information than I did.

Can anybody give me some clue to debug it?

Any suggestion is appreciated.
Thank you very much.


   Daniel.Tian

Re: libgcc doesn't support my target

[daniel tian]

Sorry, I just found and fixed the bug. the config.host file in /libgcc/.
Sorry.

DImode operations

[daniel tian]

Hi:

Do I have to write the DImode operations on my *.md target description file?
Now I build my gcc first, there is an error on libgcc2.c. which is
an __muldi3 function.
The error information is:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function __muldi3:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:557: internal compiler
error: in emit_move_insn, at expr.c:3379

My target is a RISC32 chip. There is no 64bit operations. And now I
don't wanna any 64bit operations in my C programs.
So do I have to finish the DImode operations?

Thank you very much.
Best Wishes.

  daniel.tian

Re: DImode operations

[daniel tian]

Thanks. I am working for it now.
But I have a question about how to debug the cc1 with libgcc1.c.
because if I run the cc1 to build the libgcc2.c, lots of errors
occurred.

Run the cc1 with the command:
./cc1 -g -I../../rice-gcc-4.3.0/gcc
-I../../rice-gcc-4.3.0/gcc/../include
../../rice-gcc-4.3.0/gcc/libgcc2.c

here is the error message:

../../rice-gcc-4.3.0/gcc/libgcc2.c:32:21: error: tconfig.h: No such
file or directory
In file included from ../../rice-gcc-4.3.0/gcc/libgcc2.c:33:
../../rice-gcc-4.3.0/gcc/tsystem.h:47:20: error: stddef.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:48:19: error: float.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:87:20: error: stdarg.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:90:19: error: stdio.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:93:23: error: sys/types.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:96:19: error: errno.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:103:20: error: string.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:104:20: error: stdlib.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:105:20: error: unistd.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:108:20: error: limits.h: No such
file or directory
../../rice-gcc-4.3.0/gcc/tsystem.h:111:18: error: time.h: No such file
or directory
../../rice-gcc-4.3.0/gcc/libgcc2.c:35:16: error: tm.h: No such file or directory
In file included from ../../rice-gcc-4.3.0/gcc/libgcc2.c:65:
../../rice-gcc-4.3.0/gcc/libgcc2.h:37: error: expected declaration
specifiers or '...' before 'size_t'
In file included from ../../rice-gcc-4.3.0/gcc/libgcc2.c:65:
../../rice-gcc-4.3.0/gcc/libgcc2.h:258:3: error: #error "expand the table"

Did I do something wrong?

Please give me some advice.
Thank you very much.

daniel

Re: DImode operations

[daniel tian]

Another problem I found when hacking other port.
Do I need to write SF, DF move operations?
And basic arithmetic insn patterns like ADD, SUB in DImode?

Because in CRX port (as I knew, there is no float point unit in this
cpu),  DI,SF,DF mode have 'move' operation. and there are subtract,
add operations in DImode.

So I mean whether I have to achieve all those operations. because my
target is 32bit RISC chip, no 64bit arithmetic operations and no float
point unit.

It's really tough to build libgcc succeeded.

Can your guys give me some suggestions.
Thank you very much.
Best wishes.

   daniel.

Re: DImode operations

[daniel tian]

HｉDave:
 I add the DI, SF, DFpattern. But when build the libgcc2.c, it
still cause errors.
　　The error information：

../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__muldi3':
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:557: internal compiler
error: in emit_move_insn, at expr.c:3379
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_muldi3.o] Error 1
make[2]: Leaving directory
`/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/rice-elf/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory
`/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc'
make: *** [all] Error 2

the assert:

gcc_assert (mode != BLKmode
  && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode));

in function emit_move_insn cause the error. Because the machine mode
in rtx x, y are different. X is SImode, while y is DImode.

And I hacked the CRX archtechiture, after deleting all patterns about
DI, SF, DF, it can still build successful. So I think the error is not
caused by the DI pattern.

function __muldi3:

#ifdef L_muldi3
DWtype
__muldi3 (DWtype u, DWtype v)
{
   //

Re: DImode operations

[daniel tian]

Sorry, Dove, I just gotta the solution to debug the cc1. Dove told me
the link, and I just missed. Now I checked. So sorry, I ask the stupid
question again.

But the former question, I am still puzzled.

Thanks.

GCC debug

[daniel tian]

I follow the instructions from this
website:http://gcc.gnu.org/wiki/DebuggingGCC.
but things is not going to be correct.


bacause when cc1 build libgcc2.c, some error occurred. I have debug
cc1. But If I have to build libgcc2.c,  some complex parameter have to
pass.
I don't know what's xgcc is, but it seems mandatory.  Maybe xgcc will
trigger the cc1, after xgcc processes some preprocessing.
Anyway, I don't know.
Does  anybody have some relevant materials or website, which can give
me an overview.

And this is the debug problem. And hope somebody can give me a clue.
command:
gdb --args $(./xgcc -###
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include -O2 -g -g -O2 -O2  -O2
-g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc
-I../../../rice-gcc-4.3.0/libgcc -I../../../rice-gcc-4.3.0/libgcc/.
-I../../../rice-gcc-4.3.0/libgcc/../gcc
-I../../../rice-gcc-4.3.0/libgcc/../include  -DHAVE_CC_TLS -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c 2>&1 | fgrep cc1)
gdb: `--args' specified but no program specified.

Any body who can help me.

Thank you very much.

 daniel.

Re: GCC debug

[daniel tian]

Thanks.
But how to debug cc1. Because now I port the gcc to my RISC target.
But when build the libgcc2.c.  Some error occurred. So i have to debug
it.
Any advice about how to debug?

gdb --args $(./xgcc -###
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include -O2 -g -g -O2 -O2  -O2
-g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc
-I../../../rice-gcc-4.3.0/libgcc -I../../../rice-gcc-4.3.0/libgcc/.
-I../../../rice-gcc-4.3.0/libgcc/../gcc
-I../../../rice-gcc-4.3.0/libgcc/../include  -DHAVE_CC_TLS -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c 2>&1 | fgrep cc1)
gdb: `--args' specified but no program specified.

Thanks.

Fwd: GCC debug

[daniel tian]

2009/9/28 Basile STARYNKEVITCH :
> daniel tian wrote:
>>
>> Thanks.
>> But how to debug cc1. Because now I port the gcc to my RISC target.
>> But when build the libgcc2.c.  Some error occurred. So i have to debug
>> it.
>> Any advice about how to debug?
>
>
> Start gdb from the build directory (more precisely from $BUILDIR/gcc)
>
> BTW, I am not sure your question belongs to gcc@gcc.gnu.org - it is really a
> beginner's question, and there are several documents about it.
>
> This is why I reply to you only, not to the list.
>
Thanks.
You didn't get my point.
If I just start up gdb to debug cc1, cc1 will return with message that
it did't know the parameter I pass to it.
The parameter should preprocess by xgcc first. then cc1 continue to
go. But I start up with xgcc, I can't debug cc1.
The website in my first letter, some steps mentioned about how to
debug cc1 and xgcc. I could't follow. So I ask the question here.
I am sure there are some guy also seen this problem before.

Thanks.

Re: DImode operations

[daniel tian]

Yeah. You are right. I debuged the cc1 file with insight. It caused by
FUNCTION_VALUE macro which means the error happened in function
return. Because my target always return a SImode. I fixed it.

To debug the cc1 is always a good point to hack the bug.

But there are still other error exist. I still need to fix them.

Thanks for all your guys.
Best regards.

 daniel

Re: DImode operations

[daniel tian]

Hi Dave:

when I build the libgcc2.c, an unrecognizable RTL exist. Its about subreg.
Here is the info:

../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__mulvsi3':
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: error: unrecognizable insn:
(insn 24 26 25 3 ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:165
(set (subreg:SI (reg:DI 47) 0)
(ashiftrt:SI (subreg:SI (reg/v:DI 36 [ w ]) 4)
(const_int 0 [0x0]))) -1 (expr_list:REG_NO_CONFLICT
(reg/v:DI 36 [ w ])
(nil)))
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: internal compiler
error: in extract_insn, at recog.c:1990

I could understand why subreg exist, but gcc supposed to deal with it.
I mean to remove the subreg operations.

Did your guys also meet this problem?

Could you give me some advices?
Now I still debug it.

Thanks.

SUBREG Unrecognizable RTL

[daniel tian]

Hi:

Yeah. You are right. Here is another RTL unrecognized.  It happened
after reload.

(insn 749 156 147 22 (set (reg:HI 5 R5)
(subreg:HI (mem/c:SI (plus:SI (reg/f:SI 15 R15)
(const_int 108 [0x6c])) [19 d0+0 S4 A32]) 0)) -1 (nil))

I traced the lots of functions like: reload, reload_as_needed,
emit_reload_insn, do_input_reload, emit_input_reload_insn in reload1.c
file. But I couldn't get any clue.
the gcc clashed in function: cleanup_subreg_operands. Because you can
see the RTL seems move reg to reg,  actually it load data from memory.
My target didn't accept this kind of RTL. The memory area is the
pseduo register.94. But the reg_renumber[i] < 0 &&
reg_equiv_memory_loc[i], then the pseduo register.94 was replaced with
memory location.

But I 've no idea about why it generates this kind of unrecognized RTL.
I have been hampered this problem for a while.

Any suggestion is appreciated.
Thanks very much.

Re: SUBREG Unrecognizable RTL

[daniel tian]

here are some information from the libgcc2.c.176r.greg. (BTY: the
error happened when cc1 build the libgcc2.c)

Reloads for insn # 147
Reload 0: reload_out (SI) = (reg/v:SI 99 [ __d0 ])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/v:SI 99 [ __d0 ])
reload_reg_rtx: (reg:SI 5 R5)
Reload 1: reload_in (HI) = (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
reload_reg_rtx: (reg:HI 5 R5)

So does it mean when the pseduo register 94 allocated fail, the memory
location will be substitute ?

Re: DImode operations

[daniel tian]

Hi,
   Thanks for your guys advice. Now the gcc is built succeed first
time(without headers).
   Now I have to keep going for newlib.
   Thanks very much.

Re: SUBREG Unrecognizable RTL

[daniel tian]

Yeah. My target do have instructions support load/store HImode. And
the problem is fix. I just don't understand why.  Here is the
information I gotta: http://gcc.gnu.org/ml/gcc/2005-01/msg00788.html.
I defined a predicate function rice_memory_operand which calls the
function memory operand directly, and nothing else it do. I wrote it
because it's convenient to debug. This is the what make the RTL
unrecognizable.

This is weird. I have to hack it later.
Anyway, after fixed it, gcc is build success which means a great
forward step for me.

Thanks for your guys'help.
Best Wishes.

daniel

VOIDmode in ZERO_EXTEND crashed

[daniel tian]

hi, everyone:
 I have ported the gcc to new RISC chip. But when I build the
newlib with it, the gcc crashed in simplify-rtx.c.
 error message is like this:

 ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
function _tzset_r?
 ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:195:
internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1108

 And the code there is simplify-rtx.c 1108:

 case ZERO_EXTEND:
  /* When zero-extending a CONST_INT, we need to know its
 original mode.  */
  gcc_assert (op_mode != VOIDmode);

 I tracked the gcc, It caused by the RTX   (const_int 60). As I
know the CONST_INT is alway being VOIDmode.
 I dumped the rtl tzset_r.c.161r.dce, and I think it caused by the
following rtx(because the there is const_int 60 in this rtx and the
register used is exactly what I saw in rtx which causes the gcc
crash):

  (insn 229 228 230 21
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:78 (set
(reg:SI 181)
(mult:SI (zero_extend:SI (reg:HI 182 [ mm ]))
(zero_extend:SI (const_int 60 [0x3c] 63
{rice_umulhisi3} (expr_list:REG_DEAD (reg:HI 182 [ mm ])
(nil)))

And the problem is I don't know why it lead crashing.
PS: Does gcc have a function which could dump the specified rtx? I
wanna dump the rtx when the crash happening.

Can somebody give me some advice?
Any suggestion is appreciated.

Thanks.

  daniel.

Re: VOIDmode in ZERO_EXTEND crashed

[daniel tian]

2009/10/12 Jon Beniston :
>> PS: Does gcc have a function which could dump the specified rtx?
>> I wanna dump the rtx when the crash happening.
>
> debug_rtx(x);
>
> You can also call this from within GDB, by typing:
>
> call debug_rtx(x)
>
> Cheers,
> Jon
>
Thanks.

I dump the context. Here it is:

(mult:SI (zero_extend:SI (mem/c/i:HI (plus:SI (reg/f:SI 14 R14)
(const_int 46 [0x2e])) [8 mm+0 S2 A16]))
(zero_extend:SI (const_int 60 [0x3c])))


 (zero_extend:SI (const_int 60 [0x3c])) makes the gcc crash. It is
exactly the rtx mentioned in first email:

(insn 228 227 229 21
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:78 (set
(reg:HI 182 [ mm ])
(mem/c/i:HI (plus:SI (reg/f:SI 14 R14)
(const_int 46 [0x2e])) [8 mm+0 S2 A16])) 10 {load_hi} (nil))

(insn 229 228 230 21
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:78 (set
(reg:SI 181)
(mult:SI (zero_extend:SI (reg:HI 182 [ mm ]))
(zero_extend:SI (const_int 60 [0x3c] 63
{rice_umulhisi3} (expr_list:REG_DEAD (reg:HI 182 [ mm ])
(nil)))

You can see gcc just merged the two insn.
But problem is HOW I could avoid this error.

Thanks.

 daniel

Re: VOIDmode in ZERO_EXTEND crashed

[daniel tian]

2009/10/12 Joern Rennecke :
> Quoting daniel tian :
>
>> hi, everyone:
>>     I have ported the gcc to new RISC chip. But when I build the
>> newlib with it, the gcc crashed in simplify-rtx.c.
>>     error message is like this:
>>
>>     ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
>> function _tzset_r?
>>     ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:195:
>> internal compiler error: in simplify_const_unary_operation, at
>> simplify-rtx.c:1108
>>
>>     And the code there is simplify-rtx.c 1108:
>>
>>     case ZERO_EXTEND:
>>          /* When zero-extending a CONST_INT, we need to know its
>>             original mode.  */
>>          gcc_assert (op_mode != VOIDmode);
>>
>>     I tracked the gcc, It caused by the RTX   (const_int 60). As I
>> know the CONST_INT is alway being VOIDmode.
>
> That exactly is the problem.  You can't have a CONST_INT inside a
> ZERO_EXTEND.  That is not valid.
> You'll need a separate pattern to recognize the CONST_INT without a
> ZERO_EXTEND around it.  Unfortunately, this will not give reload
> the freedom it should have.
>


You mean I should remove the const_int (by predicator) in umulhisi3 pattern?
I mean if I remove it,  how to deal with the "reg = const_int * reg"
in umulhisi3 pattern.

Thank you very much.
 daniel.

Re: VOIDmode in ZERO_EXTEND crashed

[daniel tian]

2009/10/12 Paolo Bonzini :
>
>>> That exactly is the problem.  You can't have a CONST_INT inside a
>>> ZERO_EXTEND.  That is not valid.
>>> You'll need a separate pattern to recognize the CONST_INT without a
>>> ZERO_EXTEND around it.  Unfortunately, this will not give reload
>>> the freedom it should have.
>>>
>>
>>
>> You mean I should remove the const_int (by predicator) in umulhisi3
>> pattern?
>> I mean if I remove it,  how to deal with the "reg = const_int * reg"
>> in umulhisi3 pattern.
>
> You follow these steps:
>
> 1) rename the existing pattern to something else than umulhisi3, and make it
> only accept register_operands
>
> 2) create another insn that matches (mult (zero_extend (match_operand
> "register_operand") (const_int))
>
> 3) create a define_expand that checks for a CONST_INT and does not wrap it
> (but wraps REGs and SUBREGs and if applicable MEMs).
>
> This is in general how you deal with too-forgiving predicates during
> expansion.
>
> Paolo
>

It sounds good point. I will try it first
I  would like to accepted only register and force all const_int
operand into register first.
Obviously, this may generate low efficiency code compared with your solution.

I still can't get a clear mind with step3. I may need take a while to
think about it.
I am a newcomer. :)

Thanks for your guys advice.
Best wishes.
daniel.

symbol "#" generated by CPP(c preprocessor)

[daniel tian]

Hi everyone:
I have a problem with the C preprocessor.  I write a assemble code
"setjmp.S". When I built it with gcc which I have ported with the
following command:

   /usr/local/cross/rice-elf/libexec/gcc/rice-elf/4.3.0/cc1 -E
-lang-asm -quiet -v -DHAVE_RENAME -DMISSING_SYSCALL_NAMES -isystem
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-newlib/rice-elf/newlib/targ-include
-isystem 
/home/daniel.tian/gcc_rice_dev/rice-binutils/newlib-1.16.0/newlib/libc/include
../../../../../../newlib-1.16.0/newlib/libc/machine/rice/setjmp.S
-fno-builtin -O2 -fno-directives-only -o /tmp/cctxPKBe.s

 it generate the comment in cctxPKBe.s like this:

# 1 "../../../../../../newlib-1.16.0/newlib/libc/machine/rice/setjmp.S"
# 1 ""
# 1 ""
# 1 "../../../../../../newlib-1.16.0/newlib/libc/machine/rice/setjmp.S"
# 10 "../../../../../../newlib-1.16.0/newlib/libc/machine/rice/setjmp.S"

Here is a problem that '#' is a symbol used in my chip assembler as
prefix before immediate. Like: MOV R0   #0x123.

and the comment symbol is exactly same as C++: "//".  I think the C
preprocessor think the '#' is the beginning of comment line.

So my assembler shows the error at the beginning of the file.

Is there any solution to solve this?
I know the code in function "print_line" (c-ppoutput.c) generated the
symbol "#".
But I don't think to modify the code at this place is a good idea.

Does any body also meet this problem?
Or I have to edit the gas source code.

Thanks for your guys help.


   daniel

gcc ld error

[daniel tian]

Hi, everyone:

 I have ported the gcc, newlib and binutils to my new risc target.
But when I write a simple program helloworld.c:

 #include 
int main(void)
   {
  printf("Hello World!!!\n");
  return 0;
   }

   run the command like this:
   rice-elf-gcc helloworld.c

error occurred from ld which indicates some undefine reloc names.
I just wanna get the argment passed to ld, when I could debug the
ld with gdb.
I run the command the
rice-elf-gcc helloworld.c -v
But I couldn't get the parameter passed to ld.
and I don't know what the relationship between "collect2" and
"ld". It seems they do have some connections between them.

Thanks very much.
Best wishes.

 daniel

Call func address spill out

[daniel tian]

Hi,
 I have a problem about function call insn.
 in "CALL  @LABEL", only can jump backward/forward 32k SPACE. So
if it overflows, the function symbol_ref could move a register, then
"CALL Ri" (i represent 0 ~ 15).

 But the question is gcc doesn't know the function symbol_ref 's
address before ld taking care.
 Now there is only one solution I could choose: to force all the
function call symbol_ref into register and CALL insn calls the
register.
 But I think this will cost more cpu time while routine is less
than 32k space. You know the instruction space is limited, so code
size becomes the key point.
 Can somebody give me some advice?
 Thanks very much.
 Best Wishes!


  daniel.tian

Insn missing in Size optimization(-Os)

[daniel tian]

Hi,
I met a bug in my gcc porting. It work fine when executing with -O0.
But with -Os, there is a insn missed. I dumped the RTL and checked them.
When in movebug.c.175r.lreg, it is fine. But in next phase --
movebug.c.176r.greg, the insn missed.

Here is the simple c program (movebug.c):

void fun() __attribute__((noinline));
void fun()
{
volatile int a=0;
}

int main()
{
int i;
for(i=2; i<16; ++i)
{
fun();
}
return 0;
 }

In *.175r.lreg,  the RTL code is:
   (insn:HI 6 3 8 2 movebug.c:8 (set (reg/v:SI 37 [ i ])
(const_int 2 [0x2])) 2 {constant_load_si} (expr_list:REG_EQUAL
(const_int 2 [0x2])
(nil)))

   (insn:HI 8 6 11 2 movebug.c:12 (set (reg/f:SI 42)
(symbol_ref:SI ("fun") [flags 0x3] )) 15 {symbolic_address_load} (expr_list:REG_EQUIV (symbol_ref:SI
("fun") [flags 0x3] )
(nil)))

   (code_label:HI 11 8 7 3 4 "" [1 uses])

(note:HI 7 11 10 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn:HI 10 7 9 3 movebug.c:10 (set (reg/v:SI 37 [ i ])
(plus:SI (reg/v:SI 37 [ i ])
(const_int 1 [0x1]))) 45 {rice_addsi3} (nil))

(call_insn:HI 9 10 13 3 movebug.c:12 (parallel [
(call (mem:SI (reg/f:SI 42) [0 S4 A32])
(const_int 0 [0x0]))
(clobber (reg:SI 17 LINK))
]) 99 {call} (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))

   The "fun" function address will be first loaded into register, and
then CALL insn will refer this register which means call the function.
   The *.sched1 give the data flow:
;;   ==
;;   -- basic block 2 from 6 to 8 -- before reload
;;   ==

;;0--> 6 r37=0x2   :nothing
;;1--> 8 r42=`fun' :nothing
;;  Ready list (final):
;;   total time = 1
;;   new head = 6
;;   new tail = 8

;;   ==
;;   -- basic block 3 from 9 to 13 -- before reload
;;   ==

changing bb of uid 10
;;0-->10 r37=r37+0x1   :nothing
;;1--> 9 call [r42]:nothing
;;2-->13 pc={(r37!=0x10)?L11:pc}   :nothing
;;  Ready list (final):
;;   total time = 2
;;   new head = 10
;;   new tail = 13

;;   ==
;;   -- basic block 4 from 19 to 25 -- before reload
;;   ==

;;0-->19 R2=0x0:nothing
;;1-->25 use R2:nothing
;;  Ready list (final):
;;   total time = 1
;;   new head = 19
;;   new tail = 25

But in movebug.c.176r.greg, the move function address into a register
insn disappeared. I don't know why the optimization step will take
this insn out of the program, because this will cause a logical error.
(insn:HI 6 3 37 2 movebug.c:8 (set (reg:SI 4 R4)
(const_int 2 [0x2])) 2 {constant_load_si} (expr_list:REG_EQUAL
(const_int 2 [0x2])
(nil)))

(insn 37 6 8 2 movebug.c:8 (set (mem/c:SI (reg/f:SI 15 R15) [3 i+0 S4 A32])
(reg:SI 4 R4)) 8 {store_si} (nil))

(note:HI 8 37 11 2 NOTE_INSN_DELETED)

(code_label:HI 11 8 7 3 4 "" [1 uses])

(note:HI 7 11 38 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 38 7 10 3 movebug.c:10 (set (reg:SI 4 R4)
(mem/c:SI (reg/f:SI 15 R15) [3 i+0 S4 A32])) 11 {load_si} (nil))

(insn:HI 10 38 39 3 movebug.c:10 (set (reg:SI 4 R4)
(plus:SI (reg:SI 4 R4)
(const_int 1 [0x1]))) 45 {rice_addsi3} (nil))

(insn 39 10 9 3 movebug.c:10 (set (mem/c:SI (reg/f:SI 15 R15) [3 i+0 S4 A32])
(reg:SI 4 R4)) 8 {store_si} (nil))

(call_insn:HI 9 39 40 3 movebug.c:12 (parallel [
(call (mem:SI (reg:SI 0 R0) [0 S4 A32])
(const_int 0 [0x0]))
(clobber (reg:SI 17 LINK))
]) 99 {call} (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))

also in movebug.c.194r.sched2, there is an overview of the flowchart:
;;   ==
;;   -- basic block 2 from 41 to 37 -- after reload
;;   ==

;;0-->41 [R15-0x4]=R14 :nothing
;;1-->42 R0=LINK   :nothing
changing bb of uid 44
;;2-->44 R15=R15-0xc   :nothing
;;3-->43 [R14-0x8]=R0  :nothing
changing bb of uid 6
;;4--> 6 R4=0x2:nothing
;;5-->45 R14=R15   :nothing
;;6-->37 [R15]=R4  :nothing
;;  Ready list (final):
;;   total time = 6
;;   new head = 46
;;   new tail = 37

;;   

Re: Insn missing in Size optimization(-Os)

[daniel tian]

Hi,
  Addition information, I just found. It was deleted in function: void
set_insn_deleted (rtx insn), in emit-rtl.c.
  It is called by reload() in reload1.c.
  Here is the code in reload():

/* If a pseudo has no hard reg, delete the insns that made the equivalence.
 If that insn didn't set the register (i.e., it copied the register to
 memory), just delete that insn instead of the equivalencing insn plus
 anything now dead.  If we call delete_dead_insn on that insn, we may
 delete the insn that actually sets the register if the register dies
 there and that is incorrect.  */

  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
{
  if (reg_renumber[i] < 0 && reg_equiv_init[i] != 0)
{
  rtx list;
  for (list = reg_equiv_init[i]; list; list = XEXP (list, 1))
{
  rtx equiv_insn = XEXP (list, 0);

  /* If we already deleted the insn or if it may trap, we can't
 delete it.  The latter case shouldn't happen, but can
 if an insn has a variable address, gets a REG_EH_REGION
 note added to it, and then gets converted into a load
 from a constant address.  */
  if (NOTE_P (equiv_insn)
  || can_throw_internal (equiv_insn))
;
  else if (reg_set_p (regno_reg_rtx[i], PATTERN (equiv_insn)))
delete_dead_insn (equiv_insn);
  else
SET_INSN_DELETED (equiv_insn);
}
}
}

But I don't know why the pseudo register can not be fit into a hard
register. The insn :

 (insn:HI 8 6 11 2 movebug.c:12 (set (reg/f:SI 42)
   (symbol_ref:SI ("fun") [flags 0x3] )) 15 {symbolic_address_load} (expr_list:REG_EQUIV (symbol_ref:SI
("fun") [flags 0x3] )
   (nil)))

is obvious a very useful insn, not a dead one.

So does anybody know why.
Thanks very much.

 daniel.tian

Re: Insn missing in Size optimization(-Os)

[daniel tian]

> When a pseudo which has an equivalent form (via the REG_EQUIV note) fails to
> get a hard register, reload deletes the insn which sets the pseudo and
> instead will reload the equivalent form into a suitable hard register prior
> to use points.
>
> What you want to do is look at the reloads generated for insn #9.  I'd
> hazard a guess one of them loaded the value (symbol_ref ("fun")) into R0.
>  Then for some reason (you'll have to figure that out), the reload insn
> which sets R0 was deleted (or possibly doesn't get emitted because reload
> thought it was unncessary).
>
Yeah. The Move Symbol to R0 register is deleted, which is weird.
And I still can not figure out why. Which means I still need to dig it.
But I found when I used the gcc-4.0.2 version, the Call insn call the
function direction
call the function symbol which is OK.
I mean how gcc determine to call the function directly with the function symbol
or move the function symbol ref into a register then call the register.
Obviously, now the gcc-4.3.0 in my porting is working in the latter one.

Do your guys have any advice?
Thanks very much.
best regards.

  daniel.tian

Re: Insn missing in Size optimization(-Os)

[daniel tian]

> Yeah. The Move Symbol to R0 register is deleted, which is weird.
> And I still can not figure out why. Which means I still need to dig it.
> But I found when I used the gcc-4.0.2 version, the Call insn call the
> function direction
> call the function symbol which is OK.
> I mean how gcc determine to call the function directly with the function 
> symbol
> or move the function symbol ref into a register then call the register.
> Obviously, now the gcc-4.3.0 in my porting is working in the latter one.
>
I found that gcc will choose to call symbol or register according a
TARGET MACRO --
NO_FUNCTION_CSE. Here is the comment in internal document:
Define this macro if it is as good or better to call a constant
   function address than to call an address kept in a register.

Now I defined the macro, the bug disappears. But I still need to know
why gcc delete my insn.

the two insns are in two blocks.
MOV R0   #fun ---in BLOCK 2, this insn is deleted by gcc

CALL R0 ---In Block3

in *.176r.greg:

;; Start of basic block ( 0) -> 2
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(15){ }}
;; lr  in15 [R15]
;; lr  use   15 [R15]
;; lr  def   0 [R0]
;; live  in  15 [R15]
;; live  gen 0 [R0]
;; live  kill   

;; Pred edge  ENTRY [100.0%]  (fallthru)
(note:HI 4 2 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note:HI 3 4 6 2 NOTE_INSN_FUNCTION_BEG)

(insn:HI 6 3 37 2 movebug.c:8 (set (reg:SI 0 R0)
(const_int 0 [0x0])) 2 {constant_load_si} (expr_list:REG_EQUAL
(const_int 0 [0x0])
(nil)))

(insn 37 6 8 2 movebug.c:8 (set (mem/c:SI (reg/f:SI 15 R15) [2 i+0 S4 A32])
(reg:SI 0 R0)) 8 {store_si} (nil))

(note:HI 8 37 11 2 NOTE_INSN_DELETED)
;; End of basic block 2 -> ( 3)
;; lr  out   0 [R0] 15 [R15]
;; live  out 0 [R0] 15 [R15]


;; Succ edge  3 [100.0%]  (fallthru)

;; Start of basic block ( 3 2) -> 3
;; bb 3 artificial_defs: { }
;; bb 3 artificial_uses: { u-1(15){ }}
;; lr  in0 [R0] 15 [R15]
;; lr  use   0 [R0] 15 [R15]
;; lr  def   0 [R0] 1 [R1] 2 [R2] 3 [R3] 4 [R4] 5 [R5] 6 [R6] 7 [R7] 8
[R8] 9 [R9] 10 [R10] 11 [R11] 12 [R12] 13 [R13] 16 [PC] 17 [LINK] 18
[LINK_S] 19 [STACK] 20 [STACK_S] 21 [LOOP] 22 [LOOP_S] 23 [STATUS] 24
[STATUS_S] 25 [GBR] 26 [GBRCNT] 27 [AMR] 28 [SPARE] 29 [DEBUG]
;; live  in  0 [R0] 15 [R15]
;; live  gen 4 [R4]
;; live  kill17 [LINK]

;; Pred edge  3 [93.8%]  (dfs_back)
;; Pred edge  2 [100.0%]  (fallthru)
(code_label:HI 11 8 7 3 2 "" [1 uses])

(note:HI 7 11 38 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 38 7 10 3 movebug.c:10 (set (reg:SI 4 R4)
(mem/c:SI (reg/f:SI 15 R15) [2 i+0 S4 A32])) 11 {load_si} (nil))

(insn:HI 10 38 39 3 movebug.c:10 (set (reg:SI 4 R4)
(plus:SI (reg:SI 4 R4)
(const_int 1 [0x1]))) 45 {rice_addsi3} (nil))

(insn 39 10 9 3 movebug.c:10 (set (mem/c:SI (reg/f:SI 15 R15) [2 i+0 S4 A32])
(reg:SI 4 R4)) 8 {store_si} (nil))

(call_insn:HI 9 39 40 3 movebug.c:12 (parallel [
(call (mem:SI (reg:SI 0 R0) [0 S4 A32])
(const_int 0 [0x0]))
(clobber (reg:SI 17 LINK))
]) 99 {call} (nil)
(nil))

(insn 40 9 13 3 movebug.c:10 (set (reg:SI 4 R4)
(mem/c:SI (reg/f:SI 15 R15) [2 i+0 S4 A32])) 11 {load_si} (nil))

(jump_insn:HI 13 40 14 3 movebug.c:10 (set (pc)
(if_then_else (ne:SI (reg:SI 4 R4)
(const_int 16 [0x10]))
(label_ref:SI 11)
(pc))) 84 {*insn_bne} (expr_list:REG_BR_PROB (const_int
9375 [0x249f])
(nil)))
;; End of basic block 3 -> ( 3 4)
;; lr  out   0 [R0] 15 [R15] 17 [LINK]
;; live  out 0 [R0] 15 [R15]

in *.175r.lreg:
;; Start of basic block ( 0) -> 2
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(14){ }u1(15){ }u2(30){ }}
;; lr  in14 [R14] 15 [R15] 30 [AP]
;; lr  use   14 [R14] 15 [R15] 30 [AP]
;; lr  def   37 42
;; live  in  14 [R14] 15 [R15] 30 [AP]
;; live  gen 37 42
;; live  kill   

;; Pred edge  ENTRY [100.0%]  (fallthru)
(note:HI 4 2 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note:HI 3 4 6 2 NOTE_INSN_FUNCTION_BEG)

(insn:HI 6 3 8 2 movebug.c:8 (set (reg/v:SI 37 [ i ])
(const_int 0 [0x0])) 2 {constant_load_si} (expr_list:REG_EQUAL
(const_int 0 [0x0])
(nil)))

(insn:HI 8 6 11 2 movebug.c:12 (set (reg/f:SI 42)
(symbol_ref:SI ("fun") [flags 0x41] )) 15 {symbolic_address_load} (expr_list:REG_EQUIV (symbol_ref:SI
("fun") [flags 0x41] )
(nil)))
;; End of basic block 2 -> ( 3)
;; lr  out   14 [R14] 15 [R15] 30 [AP] 37 42
;; live  out 14 [R14] 15 [R15] 30 [AP] 37 42


;; Succ edge  3 [100.0%]  (fallthru)

;; Start of basic block ( 3 2) -> 3
;; bb 3 artificial_defs: { }
;; bb 3 artificial_uses: { u3(14){ }u4(15){ }u5(30){ }}
;; lr  in14 [R14] 15 [R15] 30 [AP] 37 42
;; lr  use   14 [R14] 15 [R15] 30 [AP] 37 42
;; lr  def   0 [R0] 1 [R1] 2 [R2] 3 [R3] 4 [R4] 5 [R5] 6 [R6] 7 [R7] 8
[R8] 9 [R9] 10 [R10] 11 [R11] 12 [R12] 13 [R13] 16 [PC] 17 [LINK] 18
[LINK_S] 19 [STACK] 

Re: Insn missing in Size optimization(-Os)

[daniel tian]

>
> You might start by monitoring emit_reload_insns's behavior when it handles
> your insn.
I just debug the source code with your advice. Check the function
emit_reload_insns.

That insn was deleted before entering funcion emit_reload_insns. It
was deleted in reload(...) in reload1.c file just before calling
function reload_as_needed(this function will call emit_reload_insns).
It is sure that the insn is generated, but deleted after reload.

insn was deleted in following code.
/* If a pseudo has no hard reg, delete the insns that made the equivalence.
 If that insn didn't set the register (i.e., it copied the register to
 memory), just delete that insn instead of the equivalencing insn plus
 anything now dead.  If we call delete_dead_insn on that insn, we may
 delete the insn that actually sets the register if the register dies
 there and that is incorrect.  */

  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
{
  if (reg_renumber[i] < 0 && reg_equiv_init[i] != 0)
{
  rtx list;
  for (list = reg_equiv_init[i]; list; list = XEXP (list, 1))
{
  rtx equiv_insn = XEXP (list, 0);

  /* If we already deleted the insn or if it may trap, we can't
 delete it.  The latter case shouldn't happen, but can
 if an insn has a variable address, gets a REG_EH_REGION
 note added to it, and then gets converted into a load
 from a constant address.  */
  if (NOTE_P (equiv_insn)
  || can_throw_internal (equiv_insn))
;
  else if (reg_set_p (regno_reg_rtx[i], PATTERN (equiv_insn)))
delete_dead_insn (equiv_insn);  Call
this function to delete insn.
  else
SET_INSN_DELETED (equiv_insn);
}
}
}

I don't know where the  reg_equiv_init[i], reg_renumber[i] exactly
changed. I knew the init reg_renumber array is to be -1.
where those arrays' value changed and by what criteria.

I mean I don't know where the gcc thinks this insn is dead, and why dead.


Thanks for your advice.

Re: Insn missing in Size optimization(-Os)

[daniel tian]

Hi Jeff:
 I have already fixed the bug. this occurs due to register
allocation failed in function global_alloc. After calling the
find_reg(), the reg_renumber still keep the value -1 in it. So the
reload() in reload1.c delete the insns.
I didn't set any call saved registers which means every register
is call used. So allocating register failed when
allocno[num].calls_crossed is larger than 0.
This is weird in gcc without sending any warning message.

   Anyway, I have to thanks for your guys advice.
   Best Wishes.

   daniel.tian

generate RTL sequence

[daniel tian]

Hi,
I have a problem about RTL sequence.
If I wanna generate the RTL in sequence, and don't let gcc to schedule them.
Like the following(all the variable is rtx):

emit_insn(reg0,  operands[0]);
emit_insn(reg1,  reg0);
emit_insn(operands[0],  reg1);

But gcc will will reorder the three rtl in optimization.
I just wanna the those rtl in one block as a unit, don't let the
gcc disrupt the sequence.
How can I do it?

By the way, what do the function start_sequence and end_sequence do.
I type to call those functions in my prologue and epilogue in my
porting back end. but
 cc1 will crash.  I need to bind some kind of rtl, and make them
stay the sequence as generated.

   Thanks for your guys.

 daniel.tian

Re: generate RTL sequence

[daniel tian]

2009/12/11 Ian Lance Taylor :
> daniel tian  writes:
>
>>     I have a problem about RTL sequence.
>>     If I wanna generate the RTL in sequence, and don't let gcc to schedule 
>> them.
>>     Like the following(all the variable is rtx):
>>
>>     emit_insn(reg0,  operands[0]);
>>     emit_insn(reg1,  reg0);
>>     emit_insn(operands[0],  reg1);
>>
>>     But gcc will will reorder the three rtl in optimization.
>>     I just wanna the those rtl in one block as a unit, don't let the
>> gcc disrupt the sequence.
>>     How can I do it?
>
> Write a single define_insn which emits the instructions you want to
> treat as a unit.
>

Does there any solution in RTL level?
Because I already solve the problem in ASM output level,  exactly the
same solution as you suggest in this email.
I may need do some optimization later. So RTL level will be great!

Thanks for your advice.
Best Regards.

 daniel.tian

Re: generate RTL sequence

[daniel tian]

I think you should do the operation with the functions in emit-rtl.c.
Like the functions:add_insn_after, add_insn_before, df_insn_delete.

You could try those things.


2009/12/11 Jianzhang Peng :
> I'm tring this function, but it have some problems. It seems not link
> the new insn in the double-list.
>
> void merge(rtx insn1,rtx insn2)
> {
>        rtx par, pre,sur, insn;
>
>        par = gen_rtx_PARALLEL (SFmode, rtvec_alloc (2));
>
>        XVECEXP (par, 0, 0) = PATTERN(insn1);
>        XVECEXP (par, 0, 1) = PATTERN(insn2);
>
>        insn = make_insn_raw (par);
>
>        sur = NEXT_INSN(insn1);
>
>        PREV_INSN(insn) = insn1;
>        NEXT_INSN(insn) = sur;
>        delete_insn(insn1);
>
>        delete_insn(insn2);
> }
>
>
> 2009/12/11 daniel tian :
>> 2009/12/11 Ian Lance Taylor :
>>> daniel tian  writes:
>>>
>>>>     I have a problem about RTL sequence.
>>>>     If I wanna generate the RTL in sequence, and don't let gcc to schedule 
>>>> them.
>>>>     Like the following(all the variable is rtx):
>>>>
>>>>     emit_insn(reg0,  operands[0]);
>>>>     emit_insn(reg1,  reg0);
>>>>     emit_insn(operands[0],  reg1);
>>>>
>>>>     But gcc will will reorder the three rtl in optimization.
>>>>     I just wanna the those rtl in one block as a unit, don't let the
>>>> gcc disrupt the sequence.
>>>>     How can I do it?
>>>
>>> Write a single define_insn which emits the instructions you want to
>>> treat as a unit.
>>>
>>
>> Does there any solution in RTL level?
>> Because I already solve the problem in ASM output level,  exactly the
>> same solution as you suggest in this email.
>> I may need do some optimization later. So RTL level will be great!
>>
>> Thanks for your advice.
>> Best Regards.
>>
>>                             daniel.tian
>>
>
>
>
> --
> Jianzhang Peng
>

Re: generate RTL sequence

[daniel tian]

>> Does there any solution in RTL level?
>> Because I already solve the problem in ASM output level,  exactly the
>> same solution as you suggest in this email.
>> I may need do some optimization later. So RTL level will be great!
>
> As far as I know there is no way to do this at the RTL level.  I don't
> know why there would be a way, as it does not strike me as a useful
> feature to have.  If the instructions must stay together at the
> assembly level, use a single define_insn.  If you use multiple
> define_insns, then it's OK for the compiler to move them around.
>
> Ian
>

Ok.  Thanks.

Re: generate RTL sequence

[daniel tian]

Ian:
 By the way, I don't underand the start_sequence and end_sequence.
 What does those function mean.
  I checked the source code in emit-rtl.c.
  I still can't figure out what they do.
 There is a structure sequence_stack, I don't what it does.

Thanks.

memory predicate in RTL pattern

[daniel tian]

Hi,
 I have a problem with load/store pattern. Because in my target,
the load/store memory operand must like this form: (MEM: (REG) ),
(MEM: (REG + CONST_INT)),  (MEM: (REG + REG)).
const_int should less than 256. But in CALL insn, the memory operand
can should be in (MEM: (REG)), (MEM:(SYMBOL_REF)).  I just wanna to
avoid the RTX expression (MEM:(CONST)) ,(MEM:(SYMBOL_REF)),
(MEM:(LABEL_REF))  in load/store from/to memory insns. That's what I
was puzzled.

Now I have already generate the right RTL in "move"
define_expand pattern. when the memory operand is const (whatever
CONST, SYMBOL_REF, LABEL_REF), I will force the constant address into
register first, then generate the memory operand with this register,
and finally, with this memory operand, load/store insns are created:
   reg <--- CONSTANT_ADDRESS
   MEM:(reg)
   SET  REG  MEM
   SET MEM   REG


So I defined the following insn pattern in MD file:

(define_mode_iterator GPR [QI HI SI])

;;store to memory
(define_insn "store_"
[(set (match_operand:GPR 0 "memory_operand" "=m")
;;  [(set (mem:GPR (match_operand:SI 0 "rice_addr_operand" "T"))
  (match_operand:GPR 1 "rice_gpr_operand" "x"))]
"TARGET_RICE"
   {
return rice_output_move (operands, mode);
}
)

;;Load memory
(define_insn "load_"
[(set (match_operand:GPR 0 "rice_gpr_operand" "=x")
;;(mem:GPR (match_operand:SI 1 "rice_addr_operand" "T")))]
  (match_operand:GPR 1 "memory_operand" "m"))]
"TARGET_RICE"
 {
return rice_output_move (operands, mode);
}
[(set_attr "type" "load")]
)

predicate "rice_addr_operand" is defined in rice.c here:

int rice_addr_operand(rtx op, enum machine_mode mode)
{
if(GET_CODE(op) == REG)
{
return REG_OK_FOR_BASE_P(op);
}
if(GET_CODE(op) == PLUS)
{
rtx op1=XEXP(op, 0);
rtx op2=XEXP(op, 1);
if((GET_CODE(op1) == REG && GET_CODE(op2) == CONST_INT))
{
return REG_OK_FOR_BASE_P(op1)
&& Bit8_constant_operand(op2, SImode);
}
if((GET_CODE(op1) == REG && GET_CODE(op2) == REG))
{
return REG_OK_FOR_BASE_P(op1)
&& REG_OK_FOR_INDEX_P(op2);
}
if(GET_CODE(op1) == CONST_INT && GET_CODE(op2) == REG)  
{
return REG_OK_FOR_BASE_P(op2)
&& Bit8_constant_operand(op1, SImode);
}
}
return RICE_NO;
}

constraint "T" is define in target macro "EXTRA_CONSTRAINT"
corresponding to predicate "rice_addr_operand".

((ch) == 'S' ? symbolic_operand(x, GET_MODE(x)) :
(ch) == 'Q' ? CONSTANT_ADDRESS_P(x) :
(ch) == 'Y' ? movi_constant_operand(x, GET_MODE(x)):
(ch) == 'T' ? rice_addr_operand(x, 
GET_MODE(x)): 0);

But cc1 can't compile libgcc2.c successfully.

But the operands can't satisfy operand constraint. Like the following(
it is in libgcc2.c.175r.lreg):

(insn:HI 98 5 22 2 ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:558
(set (reg/f:SI 32 virtual-stack-vars)
(const_int 0 [0x0])) 2 {constant_load_si} (expr_list:REG_EQUAL
(const_int 0 [0x0])
(nil)))

But in libgcc2.c.176r.greg, reload process occurred:

(insn:HI 98 5 103 2
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:558 (set (reg:SI 4 R4)
(const_int 0 [0x0])) 2 {constant_load_si} (expr_list:REG_EQUAL
(const_int 0 [0x0])
(nil)))

(insn 103 98 22 2 ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:558
(set (reg/f:SI 32 virtual-stack-vars)
(reg:SI 4 R4)) 14 {move_regs_si} (nil))

the insn 103 can't be satisfy move_regs_si's constraint. when
reload_completed, the pseduo register should be no longer existed.
But it is, so error happens.

But when I revise the load/store insn pattern in MD file like this:

;;store
(define_insn "store_"
[(set (match_operand:GPR 0 "memory_operand" "=m")
;;  [(set (mem:GPR (match_operand:SI 0 "rice_addr_operand" "T"))
  (match_operand:GPR 1 "rice_gpr_operand" "x"))]
"TARGET_RICE && (!CONSTANT_ADDRESS_P(XEXP(operands[0], 0)))"
   {
return rice_output_move (operands, mode);
}
)

;;Load
(define_insn "load_"
[(set (match_operand:GPR 0 "rice_gpr_operand" "=x")
;;(mem:GPR (match_operand:SI 1 "rice_addr_operand" "T")))]
  (match_operand:GPR 1 "memory_operand" "m"))]
"TARGET_RICE && (!CONSTANT_ADDRESS_P(XEXP(operands[1], 0)))"
 {
return rice_output_move (operands, mode);
}
[(set_attr "type" "load")]
)

gcc works fine.
I just don't know why the former solution can't  work correctly, and
still don'

Re: about emit_move_insn in define_expand

[daniel tian]

(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
  (match_operand:SI 1 "general_operand" "")
)]
""
{
  if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
  {
 if(!no_new_pseudos)
 {
  operands[1]=force_reg(SImode,operands[1]);
 }
  }
  printf("Here1\n");
  emit_move_insn (operands[0],  operands[1]);
  printf("Here2\n");
  DONE;
}
)

I have confirmed it will cause the recursion.  The emit_move_insn will
call emit_move_insn  again. So if the operands are valid in machine
assemble, I need to use gen*-move function, such as gen_load,
gen_store, or just let the define_expand to generate RTL.  Like the
following, It won't cause recursion call:

(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
  (match_operand:SI 1 "general_operand" "")
)]
""
{
  if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
  {
 if(!no_new_pseudos)
 {
  operands[1]=force_reg(SImode,operands[1]);
 }
printf("Here1\n");
emit_move_insn (operands[0],  operands[1]);
printf("Here2\n");
DONE;
  }
  else
   printf("Here3\n");
  }
)

I should read more code in backend to avoid making such problems. ^_^
.  Sorry for  interruptting you.
Thank you very much.

Tian Xiaonan






2008/12/18 Uday P.  Khedker :
> Yes, please keep me updated.
>
>> Hi Dr. Uday Khedker:  I just found a something. I added 'emit_move_insn'
>> function into theoriginal file in spim5.md which was downloaded from your
>> website,everything seems fine. But I added into the file which I
>> havemodified, the cc1 will crash. I wll find the resean. Sorry,  I
>> thinkit's my fault. and I will send the reason to you later.
>>   Thank you.
>> Best wishes.
>>
>> Tian Xiaonan2008/12/18 Uday P.
>> Khedker >> Hi
>> Tian,>> I have an explanation for
>> it but let me first verify and
>> make sure> that the details are
>> correct. Will get back to you in a
>> day or two.>> Uday Khedker.>
>> -->
>> Dr. Uday Khedker> Associate
>> Professor> Department of Computer
>> Science & Engg.> IIT Bombay,
>> Powai, Mumbai 400 076, India.>
>> email   : u...@cse.iitb.ac.in>
>> homepage:
>> http://www.cse.iitb.ac.in/~uday>
>> phone   : Office - 91 (22) 2576
>> 7717>  Res.   - 91 (22)
>> 2576 8717, 91 (22) 2572 0288>
>> -->>>
>> > Hello, Dr. Uday Khedker:> >I
>> just found that emit_move_insn
>> function can't be used in> >
>> define_expand pattern in the spim
>> gcc4.0.2 platform. It will cause
>> the> > Segmentation Fault.
>> Something like recursion
>> happened.> >I changed the
>> define_expand "movsi" from:> >> >
>> (define_expand "movsi"> >
>> [(set (match_operand:SI 0
>> "nonimmediate_operand" "")> >
>>(match_operand:SI 1
>> "general_operand" "")> >   )]>
>> >   ""> > {> >
>> if(GET_CODE(operands[0])==MEM &&
>> GET_CODE(operands[1])!=REG)> >
>> {> >
>> if(!no_new_pseudos)> >
>> {> >
>> operands[1]=force_reg(SImode,operands[1]);>
>> >}> > }> >
>> }> > )> >> >  to :> >> >
>> (define_expand "movsi"> >
>> [(set (match_operand:SI 0
>> "nonimmediate_operand" "")> >
>>(match_operand:SI 1
>> "general_operand" "")> >   )]>
>> >   ""> > {> >
>> if(GET_CODE(operands[0])==MEM &&
>> GET_CODE(operands[1])!=REG)> >
>> {> >
>> if(!no_new_pseudos)> >
>> {> >
>> operands[1]=force_reg(SImode,operands[1]);>
>> >}> > }> >
>> printf("Here1\n");> >
>> emit_move_insn (operands[0],
>> operands[1]);> >
>> printf("Here2\n");> >
>> DONE;> > }> > )> >> >  The
>> string 'Here2' nerver come out.
>> Before Segmentation fault
>> occurred,> > cc1 prints lots of
>> the 'Here1'. So I guess the
>> function emit_move_insn> > caused
>> the recursion. But I checked the
>> mips md files. Mips also used the>
>> > emit_move_insn function in
>> define_expand "movsi" pattern. So
>> I guess> > whether I missed
>> something in md file. Can you give
>> me any advices?> >> > Thank you
>> very much.> >> > Best Wishes.> >
>>
>> Tian Xiaonan> >> >> >
>> --- On Tue, 12/9/08, Uday P.
>> Khedker 
>> wrote:> >> >> From: Uday P.
>> Khedker > >>
>> Subject: Re: redundancy code> >>
>> To: tianxiaonan2...@yahoo.com.cn>
>> >> Date: Tuesday, December 9,
>> 2008, 12:25 PM> >> Hi Tian,> >>>
>> >> The goal of our machine
>> descriptions has been to identify>
>> >> the> >> minimal and hence
>> essential parts of machine
>> descriptions> >> in> >> order to
>> generate correct code. Improving
>> the code quality> >> has> >> not
>> been addressed in these
>> descriptions. In due course of> >>
>> time,> >> we should be able to
>> devise methodology for developin

About Hazard Recognizer:DFA

[daniel tian]

Hi Dr. Uday Khedker:
   Happy New Year!
   I met hazard problem. And I have debuged  this error for  a few
days. I wrote DFA to avoid load hazard, but still it exists. I wonder
whether in default the command './cc1 hazard.c' doesn't compile the
file with DFA. And in default without any optimization there is no
'NOP' instruction after the 'LOAD' instruction. Oh, I didn't write
Relative Costs of operations and Adjusting the instruction scheduler
functions and macros, also instruction length attribute wasn't
defined. Did those things influence to generate correct code? I mean
to avoid hazard with or without optimization.  Any advices will be
appreciated.
   Here is the DFA decription, I think it 's ok for my aim machine. I
assume that load result new a instruction clock delay which means
latency clock is 2.

   (define_automaton "rice")
   (define_cpu_unit "rice_load" "rice")

   (define_insn_reservation "generic_load" 2 (eq_attr "type" "load")
"rice_load, nothing")
  C sources code is below:
  C Code:
int load_delay(int *p, int num)
{
int a, b, c, d, result;

result = 0;
c = *(p + 2) + 1;
b = *(p + 1) + 9;
a = *p + 2;
result = a + b;
result += c;
d = c + 3;
result += d;

return result;
}

Here is the assemble which the cc1 generated:

.code
load_delay: 
LOADW   R9  (R4)  #0  -PRI
LOADW   R10 (R4) #8  -PRI//If this line can exchange
with the next line, then the hazard will disappear.
LOADW   R2  (R4) #4  -PRI//Here is data dependency
between the next line, the reg R2 can't be used in next instruction.
ADD R2  R2  R9//Hazard
ADD R2  R2  R10
ADD R2  R2  R10
ADD R2  R2  #16
RETURN  -D0
mult_mac:   MOV R2 #274
RETURN  -D0

There is hazard in the assemble code.

   Please give me some advices.
   Thank you very much.
   Best Wishes.



  Xiaonan Tian

load large immediate

[daniel tian]

hello,
there is a 'movm' problem that puzzled me. In my target machine,
to load a large immediate data, can only move into zero register "R0".
but R0 is a generally register. I defined the the way in the
following:

if the immediate data (op1) is larger than 1024
 then do
 {
 emit_move_insn(r0_reg_rtx, gen_rtx_CONST_INT(SImode, op1));
//Move the immediate data into R0 register
 emit_move_insn(force_reg (mode, operands[0]), r0_reg_rtx);
  //move  r0 to default register.
 }

I have tested the way , it works. But while in optimization, it
causes some redundency codes. like the following c code,(iFrequency is
byte globel data, common_reg, DiffReg are byte globel arrays)

int i = 0;
BYTE*   pDiffPair = common_reg + (COMMON_REG_WRITE << 1), *pData = 
DiffReg;

   *(pDiffPair + 1) = *(pData + iFrequency);

pData = pData + 36;

*(pDiffPair + 5) = *(pData + iFrequency);

pData = pData + 36;

*(pDiffPair + 7) = *(pData + iFrequency);

pData = pData + 36;

*(pDiffPair + 11) = *(pData + iFrequency);

pData = pData + 36; 

*(pDiffPair + 15) = *(pData + iFrequency);

pData = pData + 36;

*(pDiffPair + 17) = *(pData + iFrequency);

 the address label "common_reg " used many times. I think it will
load one time. But after optimized with '-Os' or '-O2', it still loads
the label "common_reg " six times..
 I guess it definitely caused  by  "move large immediate" insns.
 I don't know how to solve this problem.
 Does the macro "PREFERRED_RELOAD_CLASS" handle it?
 Any advice is appreciated.
 Thank you very much.



daniel.tian

Re: load large immediate

[daniel tian]

2009/2/26 Joern Rennecke :
>> the address label "common_reg " used many times. I think it will
>> load one time. But after optimized with '-Os' or '-O2', it still loads
>> the label "common_reg " six times..
>
> Previously, you could define LEGITIMIZE_ADDRESS and
> LEGITIMIZE_RELOAD_ADDRESS
> to get reasonable code.  However, that no longer works in gcc 4.4, see
> PR38785.
>
> I have a patch set; if you like, I can it to you.  Note, however, that it is
> not known if the FSF have a relevant valid Copyright assignment on file.
>

I port the gcc with 4.0.2 version. But How to add the code in
LEGITIMIZE_RELOAD_ADDRESS. Do you have any example? Thank you very
much.

Re: load large immediate

[daniel tian]

2009/2/26 Dave Korn :
> daniel tian wrote:
>
>>     there is a 'movm' problem that puzzled me. In my target machine,
>> to load a large immediate data, can only move into zero register "R0".
>> but R0 is a generally register. I defined the the way in the
>> following:
>>
>>     if the immediate data (op1) is larger than 1024
>>      then do
>>      {
>>          emit_move_insn(r0_reg_rtx, gen_rtx_CONST_INT(SImode, op1));
>> //Move the immediate data into R0 register
>>          emit_move_insn(force_reg (mode, operands[0]), r0_reg_rtx);
>>                               //move  r0 to default register.
>>      }
>
>  When/where/how are you calling this code?

while in "define_expand movsi" pattern, It will call this code, and if
the source operand is larget immediate, it will emit the two RTLs. So
if the destination reg is 49 (pseudo reg num), my solution will move
the symbol or large immediate into R0, then move the R0 into pseudo
register 49. I mean whether there is any way let the gcc know to set a
default distination reg being R0 while reloading symbol or large
immediate.

>
>>      the address label "common_reg " used many times. I think it will
>> load one time. But after optimized with '-Os' or '-O2', it still loads
>> the label "common_reg " six times..
>
>  I wonder if you're generating it too late for the optimisers to do anything?

I dumped  the *.00.expand and *.21.sched file.  I think it generates
the RTL before optimiser working. But I doubt whether the code like
this is optimized in RTL, maybe  before.

*.00.expand (part of it, the integral one is too long):

(insn 22 21 23 1 (set (reg:SI 0 R0)
(const:SI (plus:SI (symbol_ref:SI ("common_reg") [flags 0x2]
)
(const_int 69 [0x45] -1 (nil)
(nil))

(insn 23 22 24 1 (set (reg/f:SI 49)
(reg:SI 0 R0)) -1 (nil)
(expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI
("common_reg") [flags 0x2] )
(const_int 69 [0x45])))
(nil)))

(insn 24 23 25 1 (set (reg:SI 0 R0)
(symbol_ref:SI ("DiffReg") [flags 0x2] )) -1 (nil)
(nil))

(insn 25 24 26 1 (set (reg/f:SI 50)
(reg:SI 0 R0)) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref:SI ("DiffReg") [flags 0x2]
)
(nil)))

(insn 26 25 27 1 (set (reg:QI 51)
(mem:QI (plus:SI (reg:SI 47 [ D.1073 ])
(reg/f:SI 50)) [0 S1 A8])) -1 (nil)
(nil))

(insn 27 26 29 1 (set (mem/s:QI (reg/f:SI 49) [0 common_reg+69 S1 A8])
(reg:QI 51)) -1 (nil)
(nil))

(insn 29 27 30 1 (set (reg:SI 0 R0)
(const:SI (plus:SI (symbol_ref:SI ("common_reg") [flags 0x2]
)
(const_int 73 [0x49] -1 (nil)
(nil))

(insn 30 29 31 1 (set (reg/f:SI 52)
(reg:SI 0 R0)) -1 (nil)
(expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI
("common_reg") [flags 0x2] )
(const_int 73 [0x49])))
(nil)))

(insn 31 30 32 1 (set (reg:SI 0 R0)
(const:SI (plus:SI (symbol_ref:SI ("DiffReg") [flags 0x2]
)
(const_int 36 [0x24] -1 (nil)
(nil))

(insn 32 31 33 1 (set (reg/f:SI 53)
(reg:SI 0 R0)) -1 (nil)
(expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("DiffReg")
[flags 0x2] )
(const_int 36 [0x24])))
(nil)))

(insn 33 32 34 1 (set (reg:QI 54)
(mem:QI (plus:SI (reg:SI 47 [ D.1073 ])
(reg/f:SI 53)) [0 S1 A8])) -1 (nil)
(nil))

(insn 34 33 36 1 (set (mem/s:QI (reg/f:SI 52) [0 common_reg+73 S1 A8])
(reg:QI 54)) -1 (nil)
(nil))
   ..
   Does the load two labels "common_reg"", "DiffReg" interlaced caused
the optimization confused?
   I mean there are two label need to load, then after load one, move
the value in R0 to another register, and then load another label. So
It will only load every label one time.

   Here is the *.21.sched file:
;;   ==
;;   -- basic block 0 from 20 to 70 -- before reload
;;   ==

;;0--> 20   r48=[`iFrequency'] :rice_load,nothing
;;1--> 24   R0=`DiffReg'   :nothing
;;2--> 21   r47=zxn(r48)   :nothing
;;3--> 25   r50=R0 :nothing
;;4--> 26   r51=[r47+r50]  :rice_load,nothing
;;5--> 31   R0=r50+0x24:nothing
;;6--> 27   [const(`common_reg'+0x45)]=r51 :nothing
;;7--> 33   r54=[r47+R0]   :rice_load,nothing
;;8--> 38   R0=r50+0x48:nothing
;;9--> 34   [const(`c

Re: load large immediate

[daniel tian]

2009/2/27 Joern Rennecke :
> Quoting daniel tian :
>
>> 2009/2/26 Joern Rennecke :
>>>>
>>>> the address label "common_reg " used many times. I think it will
>>>> load one time. But after optimized with '-Os' or '-O2', it still loads
>>>> the label "common_reg " six times..
>>>
>>> Previously, you could define LEGITIMIZE_ADDRESS and
>>> LEGITIMIZE_RELOAD_ADDRESS
>>> to get reasonable code.  However, that no longer works in gcc 4.4, see
>>> PR38785.
>>>
>>> I have a patch set; if you like, I can it to you.  Note, however, that it
>>> is
>>> not known if the FSF have a relevant valid Copyright assignment on file.
>>>
>>
>> I port the gcc with 4.0.2 version. But How to add the code in
>> LEGITIMIZE_RELOAD_ADDRESS. Do you have any example? Thank you very
>> much.
>
> Yes, there are a number of examples in config/*/*.h - just doing a
> grep should give you a goo selection.  The port where this macro
> has been added first, in order to avoid unnecessary repetition of
> stack slot address additions, was the SH port.
> The SFmode part is a later addition, which is different because the
> SH3E (and the later 32 bit SH family members with hardware floating
> point) don't have REG+offset addressing for floating point registers,
> but they have REG+index addressing.
> The basic operation of the macro is explained in doc/tm.texi .
> In order to handle pseudos that are equivalent to a constant,
> you need to allow registers that are not suitable as a base
> for REG_OK_STRICT_P (because pseudos aren't), which have
> reg_equiv_constant set.
> You'll have to take the value in reg_equiv_constant and
> do necessary arithmetic with plus_constant in order to compute
> the value to be used in push_reload.
>
Thank you for your reply.
I read some documents.
That seems to solving a address mode problem. My problem is that while
loading a large immediate data or SYMBOL_REF,  the destination is a
specified general register (register 0:R0). So I don't how to let the
define_expand "movsi" pattern to generate destination register in R0.
I read some document about "reload" which was a issue that I missed in
former working. Does this problem obstruct the problem ?
Your guys give me some greate advices. I will keep working. Thank you
very much  again.

Re: load large immediate

[daniel tian]

2009/2/27 Dave Korn :
> daniel tian wrote:
>
>> That seems to solving a address mode problem. My problem is that while
>> loading a large immediate data or SYMBOL_REF,  the destination is a
>> specified general register (register 0:R0). So I don't how to let the
>> define_expand "movsi" pattern to generate destination register in R0.
>
>  Well, the RTL that you emit in your define_expand has to match an insn
> pattern in the end, so you could make an insn for it that uses a predicate and
> matching constraint to enforce only accepting r0.  If you use a predicate that
> only accepts r0 you'll get better codegen than if you use a predicate that
> accepts general regs and use an r0-only constraint to instruct reload to place
> the operand in r0.

Well, I have already done this. There is insn pattern that the
predicate limits the operand in R0. But if in define_expand "movsi" do
not put the register in R0, the compiler will  crashed because of the
unrecognized RTL(load big immediate or Symbol). Like the below:
(define_insn "load_imm_big"
[(set (match_operand:SI 0 "zero_register_operand" "=r")
  (match_operand:SI 1 "rice_imm32_operand" "i"))
  (clobber (reg:SI 0))]
"TARGET_RICE"
{
return rice_output_move (operands, SImode);
}
)

PS:rice_output_move  is function to output assemble code.

Thanks.

Re: load large immediate

[daniel tian]

2009/2/27 daniel tian :
> 2009/2/27 Dave Korn :
>> daniel tian wrote:
>>
>>> That seems to solving a address mode problem. My problem is that while
>>> loading a large immediate data or SYMBOL_REF,  the destination is a
>>> specified general register (register 0:R0). So I don't how to let the
>>> define_expand "movsi" pattern to generate destination register in R0.
>>
>>  Well, the RTL that you emit in your define_expand has to match an insn
>> pattern in the end, so you could make an insn for it that uses a predicate 
>> and
>> matching constraint to enforce only accepting r0.  If you use a predicate 
>> that
>> only accepts r0 you'll get better codegen than if you use a predicate that
>> accepts general regs and use an r0-only constraint to instruct reload to 
>> place
>> the operand in r0.
>
> Well, I have already done this. There is insn pattern that the
> predicate limits the operand in R0. But if in define_expand "movsi" do
> not put the register in R0, the compiler will  crashed because of the
> unrecognized RTL(load big immediate or Symbol). Like the below:
> (define_insn "load_imm_big"
>        [(set (match_operand:SI 0 "zero_register_operand" "=r")
>              (match_operand:SI 1 "rice_imm32_operand" "i"))
>              (clobber (reg:SI 0))]
>        "TARGET_RICE"
>        {
>                return rice_output_move (operands, SImode);
>        }
> )
>
> PS:rice_output_move  is function to output assemble code.
>
> Thanks.
>

Hello, Dave, Rennecke :
  I defined the PREFERRED_RELOAD_CLASS macro, but this cc1 doesn't
go through it.
  #define PREFERRED_RELOAD_CLASS(X, CLASS)
rice_preferred_reload_class(X, CLASS)

  And rice_preferred_reload_class(X, CLASS) is:

  enum reg_class rice_preferred_reload_class (rtx x, enum reg_class class)
 {
printf("Come to rice_preferred_reload_class! \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)
{
return R0_REG;
}
return class;
  }

 I run the cc1 file with command "./cc1 test_reload.c  -Os". But
the gcc never goes through this function. Did I missed something?
 Thank you very much.

Re: load large immediate

[daniel tian]

2009/3/2 daniel tian :
> 2009/2/27 daniel tian :
>> 2009/2/27 Dave Korn :
>>> daniel tian wrote:
>>>
>>>> That seems to solving a address mode problem. My problem is that while
>>>> loading a large immediate data or SYMBOL_REF,  the destination is a
>>>> specified general register (register 0:R0). So I don't how to let the
>>>> define_expand "movsi" pattern to generate destination register in R0.
>>>
>>>  Well, the RTL that you emit in your define_expand has to match an insn
>>> pattern in the end, so you could make an insn for it that uses a predicate 
>>> and
>>> matching constraint to enforce only accepting r0.  If you use a predicate 
>>> that
>>> only accepts r0 you'll get better codegen than if you use a predicate that
>>> accepts general regs and use an r0-only constraint to instruct reload to 
>>> place
>>> the operand in r0.
>>
>> Well, I have already done this. There is insn pattern that the
>> predicate limits the operand in R0. But if in define_expand "movsi" do
>> not put the register in R0, the compiler will  crashed because of the
>> unrecognized RTL(load big immediate or Symbol). Like the below:
>> (define_insn "load_imm_big"
>>        [(set (match_operand:SI 0 "zero_register_operand" "=r")
>>              (match_operand:SI 1 "rice_imm32_operand" "i"))
>>              (clobber (reg:SI 0))]
>>        "TARGET_RICE"
>>        {
>>                return rice_output_move (operands, SImode);
>>        }
>> )
>>
>> PS:rice_output_move  is function to output assemble code.
>>
>> Thanks.
>>
>
> Hello, Dave, Rennecke :
>      I defined the PREFERRED_RELOAD_CLASS macro, but this cc1 doesn't
> go through it.
>      #define PREFERRED_RELOAD_CLASS(X, CLASS)
> rice_preferred_reload_class(X, CLASS)
>
>      And rice_preferred_reload_class(X, CLASS) is:
>
>      enum reg_class rice_preferred_reload_class (rtx x, enum reg_class class)
>     {
>        printf("Come to rice_preferred_reload_class! \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)
>        {
>                return R0_REG;
>        }
>        return class;
>      }
>
>     I run the cc1 file with command "./cc1 test_reload.c  -Os". But
> the gcc never goes through this function. Did I missed something?
>     Thank you very much.
>

Hello, I resolved the problem. The key is the macro
LEGITIMIZE_RELOAD_ADDRESS, and GO_IF_LEGITIMATE_ADDRESS, and
PREFERRED_RELOAD_CLASS. And the predicate "zero_register_operand".
Here is the thing I learnt. If I did something wrong,  let me know. :)

LEGITIMIZE_RELOAD_ADDRESS: in this macro, I should push the invalid
the rtx like large immeidate, symbol_rel, label_rel, into the function
push_reload which will call macro PREFERRED_RELOAD_CLASS.

GO_IF_LEGITIMATE_ADDRESS: this macro will have two mode, strict or
non_strict, the former used in reload process, the latter used in
before reload. I made a mistake in this macro, defined the two mode
exactly in the same way( I defined the large immeidate, SYMBOL_REL,
LABEL_REL, CONST is valid in two mode ). So it nerver call macro
LEGITIMIZE_RELOAD_ADDRESS. The function find_reloads_address in
reloads.c will call GO_IF_LEGITIMATE_ADDRESS first, if rtx is a valid
address, it will nerver goto macro LEGITIMIZE_RELOAD_ADDRESS.

PREFERRED_RELOAD_CLASS: this macro is in function push_reload which
was mentioned above.

and the predicate "zero_register_operand", I defined the rtx with the
register NO. being 0. So Everytime, cc1 will abort with information
like "rtl unrecognize". Because pseudo register are allocated before
reload. I revised the predicate which register NO should be 0 or
pseudo.

Now It is Ok. But it still has some redundency code. I will keep going.
Your guys are so kind. Thank you very much.
Thank you for your help again!

Best Regards!


  Daniel.Tian

logical error with 16bit arithmatic operations

[daniel tian]

Hello,
  I am porting gcc to a 32bit RISC chip, and  I met a logical
error with 16bit arithmetic operations in generating assemble code.
the error is between two 16bit data movement(unsigned short).
While like A = B,  A, and B are all unsigned short type.  B is a
result of a series of computation, which may have value in high 16bit.
Because A , B are both HImode, so the move insn doesn't take zero
extend operation, so A will have value in high 16bit which will caused
a wrong result in computation. Like the following CRC calculation.

 There is a comment added with "//" in logical error position.


Here is the .sched2 script:
;;   ==
;;   -- basic block 0 from 10 to 92 -- after reload
;;   ==

;;0--> 10   R3=R4  :nothing
;;1--> 11   R7=R5  :nothing
;;2--> 89   R0=`x25_crc_table' :nothing
;;3--> 92   pc=L58 :nothing
;;  Ready list (final):
;;   total time = 3
;;   new head = 10
;;   new tail = 92

;;   ==
;;   -- basic block 1 from 25 to 53 -- after reload
;;   ==

;;0--> 25   R6=[post_modify]   :rice_load,nothing
;;1--> 57   R7=R7-0x1  :nothing
;;2--> 26   R4=R6 0>>0x4   :nothing
;;3--> 27   R4=zxn(R4) :nothing
;;4--> 28   R4=R5^R4   :nothing
;;5--> 32   R4=zxn(R4) :nothing
;;6--> 35   R4=R4+R4   :nothing
;;7--> 37   R5=[R4+R0] :rice_load,nothing
;;8--> 42   R6=zxn(R6) :nothing
;;9--> 38   R5=R5^R13  :nothing
;;   10--> 40   R4=R5 0>>0xc   :nothing
;;   11--> 43   R4=R4^R6   :nothing
;;   12--> 47   R4=zxn(R4) :nothing
;;   13--> 48   R4=R4&0xf  :nothing
;;   14--> 50   R4=R4+R4   :nothing
;;   15--> 52   R4=[R4+R0] :rice_load,nothing
;;   16--> 46   R5=R5<<0x4 :nothing
;;   17--> 53   R6=R5^R4   :nothing
;;  Ready list (final):
;;   total time = 17
;;   new head = 25
;;   new tail = 53

;;   ==
;;   -- basic block 2 from 23 to 62 -- after reload
;;   ==

;;0--> 87   R2=zxn(R6) :nothing


;;1--> 23   R5=R6 0>>0xc   :nothing
 //R5 and R6 are both unsigned short type. But R6 will
have it's value in high 16bit because of series of logical operations
(AND, OR, XOR and so on). Doing it like this way will cause R5 also
being valued in high 16bit. This will cause a wrong value. The correct
one is : R5 = R2 0 >> 0xC. because R2 did zero extend in former insn
from R6. But How I let gcc know it.


;;2--> 31   R13=R2<<0x4:nothing
;;3--> 62   pc={(R7>0x0)?L20:pc}   :nothing
;;  Ready list (final):
;;   total time = 3
;;   new head = 87
;;   new tail = 62

;;   ==
;;   -- basic block 3 from 100 to 100 -- after reload
;;   ==

;;0--> 100  return :nothing
;;  Ready list (final):
;;   total time = 0
;;   new head = 100
;;   new tail = 100



PS, I compile the c code with -Os command. Here is C code:

static  const unsigned short  x25_crc_table[16] =
{
  0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
  0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF
};

/*
** FUNCTION:crc_X25
**
** DESCRIPTION: This function generates a crc on from the data given
**  using the X 25 CRC lookup table.
**
**
** PARAMETERS:  Data to check:
**  Array of data:  UTINY *
**  Length of data in array:LONG
**  CRC initial value:  USHORT
**
** RETURNS: USHORT, The CRC calculated.
**
*/
unsigned short crc_X25(unsigned char *data, long length, unsigned short crc_reg)
{
  unsigned short temp;


  /* Use 4 bits out of the data/polynomial at a time */
  while (length > 0)
  {   /* step through the data */
temp = crc_reg;

temp >>= 12u;
temp ^= (*data) >> 4u;  /* xor data (MS 4 bits) with the MS 4 bits */
temp &= 0xf;/* of the CRC reg to be used as index in array */
temp = crc_reg = (unsigned short )((crc_reg << 4u) ^ x25_crc_table[temp]);

/* Now do sec

Re: logical error with 16bit arithmatic operations

[daniel tian]

Thank you for your advice. Compared RICE (my processor name) RTL and
MIPS RTL,  I found the problem. Because of the subreg operations which
I missed to add support in my RTL. I noticed the mips rtl code which
will convert the QImode and HI mode to SImode operations. Like the
following:

(insn 28 26 29 2 (set (reg:QI 198)
(mem:QI (reg/v/f:SI 193 [ data ]) [0 S1 A8])) -1 (nil)
(nil))

(insn 29 28 30 2 (set (reg:SI 191 [ D.1099 ])
(zero_extend:SI (reg:QI 198))) -1 (nil)
(nil))

(insn 30 29 31 2 (set (reg:SI 199)
(lshiftrt:SI (reg:SI 191 [ D.1099 ])
(const_int 4 [0x4]))) -1 (nil)
(nil))

But in my port, the rtl code is like this:

(insn 25 23 26 2 (set (reg:QI 45 [ D.1059 ])
(mem:QI (reg/v/f:SI 47 [ data ]) [0 S1 A8])) -1 (nil)
(nil))

(insn 26 25 27 2 (set (reg:QI 50)
(lshiftrt:QI (reg:QI 45 [ D.1059 ])
(const_int 4 [0x4]))) -1 (nil)
(nil))

If I extend the QI operands, then do the shift operations,  the logic
will be right.
But the question is how I make the gcc know to extend every smaller
mode to SImode. Now I check the MIPS port, maybe I can find some clue.

Thank you for your guys.


daniel.tian


2009/3/27 Ian Lance Taylor :
> daniel tian  writes:
>
>>       I am porting gcc to a 32bit RISC chip, and  I met a logical
>> error with 16bit arithmetic operations in generating assemble code.
>> the error is between two 16bit data movement(unsigned short).
>> While like A = B,  A, and B are all unsigned short type.  B is a
>> result of a series of computation, which may have value in high 16bit.
>> Because A , B are both HImode, so the move insn doesn't take zero
>> extend operation, so A will have value in high 16bit which will caused
>> a wrong result in computation.
>
> The relevant types in your code are "unsigned short".  I assume that on
> your processor that is a 16 bit type.  An variable of an unsigned 16 bit
> type can hold values from 0 to 0x, inclusive.  There is nothing
> wrong with having the high bit be set in such a variable.  It just means
> that the value is between 0x8000 and 0x.
>
>
>> ;;      1--> 23   R5=R6 0>>0xc                       :nothing
>>              //R5 and R6 are both unsigned short type. But R6 will
>> have it's value in high 16bit because of series of logical operations
>> (AND, OR, XOR and so on). Doing it like this way will cause R5 also
>> being valued in high 16bit. This will cause a wrong value. The correct
>> one is : R5 = R2 0 >> 0xC. because R2 did zero extend in former insn
>>>From R6. But How I let gcc know it.
>
> No.  0>> means a logical right shift, not an arithmetic right shift
> (LSHIFTRT rathre than ASHIFTRT).  When doing a logical right shift, the
> sign bit is moved right also; it is not sticky.  This instruction is
> fine.  Perhaps there is a problem in your implementation of LSHIFTRT.
>
> Ian
>

Re: logical error with 16bit arithmatic operations

[daniel tian]

Yes. You are right. I fixed the problem.
I checked the macro in INTERNAL docment,  and I copied the mips
definition of PROMOTE_MODE:

#define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \
  if (GET_MODE_CLASS (MODE) == MODE_INT \
  && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \
{   \
   (MODE) = Pmode;   \
}
Now it runs ok now.

Thank you very much.
Best regards!


2009/3/31 Ian Lance Taylor :
> daniel tian  writes:
>
>> But the question is how I make the gcc know to extend every smaller
>> mode to SImode. Now I check the MIPS port, maybe I can find some clue.
>
> Maybe PROMOTE_MODE.
>
> Ian
>

internal compiler error: in reload_combine_note_use, at postreload.c:1093

[daniel tian]

I have ported gcc4.0.2  to 32bit RISC chip. But internal compiler
error happened: in reload_combine_note_use, at postreload.c:1093 . I
tracked the code with insight.  error occurred in "CASE REG", when the
register number is larger than FIRST_PSEUDO_REGISTER. Does this mean
the reload register allocation failed?  What I know is that there is
no pseudo register used after reload completed (Is this right?).

Can anyone give me some advice?

Any suggestion is appreciated.
Thank you very much.


 Daniel.Tian

Re: internal compiler error: in reload_combine_note_use, at postreload.c:1093

[daniel tian]

Thank you for your advice.

Yes. I checked the MD file and relative machine.h/.c, there are some
places which call the ''force_reg' unconditionally. I modified the it
in "movm" insn pattern, the error still exists. And I also check the
mips/arm, they also call 'force_reg' unconditional in some places.

Anything I missed?

2009/5/13 Dave Korn :
> daniel tian wrote:
>> I have ported gcc4.0.2  to 32bit RISC chip. But internal compiler
>> error happened: in reload_combine_note_use, at postreload.c:1093 . I
>> tracked the code with insight.  error occurred in "CASE REG", when the
>> register number is larger than FIRST_PSEUDO_REGISTER. Does this mean
>> the reload register allocation failed?  What I know is that there is
>> no pseudo register used after reload completed (Is this right?).
>
>  Yes, this is correct.
>
>> Can anyone give me some advice?
>
>  It is most likely one of the expanders or other patterns in your MD file is
> unconditionally calling a function such as force_reg() without checking the
> reload_completed / reload_in_progress flags.  If this pattern gets invoked
> post-reload, that will allocate a pseudo and then fail later.
>
>    cheers,
>      DaveK
>
>
>

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

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

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

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

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

About machine.md in insight-gdb debug

[daniel tian]

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?

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