DImode operations

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

[Dave Korn]

daniel tian wrote:
> Hi:
> 
>     Do I have to write the DImode operations on my *.md target description file?

  Yes.  movMM must be implemented for all types that you want the compiler to
be able to handle at all; it's the only way it knows to move them around.
(Technically, it's supposed to be able to treat DImode as BLKmode and break it
down by pieces, but this code hasn't always been reliable and is definitely
less efficient than implementing a proper movdi pattern in your backend.)

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

  I think you really should.  Take a look at how other ports handle it;
generally they use a define_expand for movdi, which emits the move as two
separate SI-mode move insns.  (Note in particular how they have to take care
what order to emit the two word moves in, as it's possible for the register
pairs used in input and output operations to overlap.)

  If you insisted, you could probably just hack the *di* routines out of the
libgcc makefile and get through to the end of the build, but I really wouldn't
recommend it, since "long long" is a standard C99 type.  It's not a great deal
of work to add the expander pattern and code that you'll need.

    cheers,
      DaveK

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

[Dave Korn]

daniel tian wrote:
> 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:

> Did I do something wrong?

  Yes, it can't work that simply; the code in libgcc2.c needs a bunch of
macros defined and some other -I paths as well before it will work.  One way
is to

- in the gcc/ subdir of your build directory, delete one of the libgcc .o
files that you want to test your new compiler against
- run "make 2>&1 | tee build.log" to capture the xgcc command that the
makefile generates to rebuild that .o file.
- copy and paste the commandline from the build log and add "-v 2>&1 | tee
rebuild.log" at the end to capture the way the xgcc driver invokes cc1
- copy and paste /that/ commandline, and put "gdb --args" at the front of it
to debug your compiler.

  See also http://gcc.gnu.org/wiki/DebuggingGCC

    cheers,
      DaveK

Re: DImode operations

[Dave Korn]

daniel tian wrote:
> 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.

  I think you can enable soft-fp in your t- target makefile fragment and then
you need only implement trivial register to register fp moves for everything
to basically work, but I haven't checked so I may have remembered wrong.

    cheers,
      DaveK

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 <http://gcc.gnu.org/bugs.html> 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)
{
   //<----------------------------this is the line 557, which error
info shows.
  const DWunion uu = {.ll = u};
  const DWunion vv = {.ll = v};
  DWunion w = {.ll = __umulsidi3 (uu.s.low, vv.s.low)};

  w.s.high += ((UWtype) uu.s.low * (UWtype) vv.s.high
	       + (UWtype) uu.s.high * (UWtype) vv.s.low);

  return w.ll;
}
#endif

Does this mean error occur in argument passing?
I just wanna the gcc build successful first. Then make the
define_insn/pattern DI/SF/DF right.
Can somebody give me some advice?
thanks.

And another question.
If I wanna debug the gcc when build the file libgcc2.c, the command
line the build.log is like this:

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

this is huge. but cc1 does not run in this command. I open the xgcc in
gdb, it is different from cc1.
but run:
run -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
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c

it can be build and the former error shows again. But I just don't
know how to make a break point in emit_move_isn, expr.c. Because the
expr.c file doesn't appear in the xgcc file. (I debug it with
insight.)

So anybody also meet the same problem? and how to slove it.

Thank you very much.


                                 daniel

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.

Re: DImode operations

[Dave Korn]

daniel tian wrote:

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

> make[2]: *** [_muldi3.o] Error 1

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

  Well, you need to establish why this insn is being generated.  Is it coming
from your expanders perhaps?  Now that you've figured out debugging cc1, set a
breakpoint on "internal_compiler_error" and take a look at the backtrace to
see what function has called emit_move_insn; the answer probably lies there.

    cheers,
      DaveK

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.

Re: DImode operations

[Ian Lance Taylor]

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

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

Your operand predicates should accept subregs before reload.  This
will happen automatically if you use register_operand.

Ian

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.