Problem with new port

Problem with new port

[Alleged Judas]

Hello,

I'm in the process of porting GCC to a new
architecture (of my own devising). I'm sort of
stumbling around in the dark most of the time,
although I have got to the stage where extremely basic
test functions (factorial, strcpy) will sort-of
compile.

Unfortunately I seem to have hit a problem which I'm
finding rather difficult to track down, and I'm
wondering if anyone can shed any light (the manual
isn't much help). Basically, I have the following test
functions:

---
int testfun(int a, int b, int c, int d, int e, int f,
int g)
{
  return a+b+c+d+e+f+g;
}

int infun(int d)
{
  return testfun(d, d+1, d+2, d+3, d+4, d+5, d+6);
}
---

Now, the first function seems to compile OK, but the
second gives this error:

---
jules@erwin:~/gcc-cvs/build$ gcc/xgcc -Bgcc -O2 -S
../foo.c -da
../foo.c: In function `infun':
../foo.c:58: error: insn does not satisfy its
constraints:
(insn 42 20 17 0 (nil) (set (reg:SI 8 r8)
        (reg/f:SI 131 virtual-outgoing-args)) 1
{*movsi_simple} (nil)
    (nil))
../foo.c:58: internal compiler error: in
reload_cse_simplify_operands, at reload1.c:8335
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html>
for instructions.
---

I don't think there should be any reference to
virtual-outgoing-args at this stage. I suspect the
problem might be somewhere in my target description
macros relating to function arguments (FUNCTION_ARG,
the CUMULATIVE_ARG stuff) or else I have missed out a
constraint I need in the movsi pattern (which seems
obvious, but I can't see anything) or else I need
reload_* patterns of some sort, which are currently
absent.

The movsi pattern is defined as:

---
(define_expand "movsi"
  [(set (match_operand:SI 0 "nonimmediate_operand" "")
        (match_operand:SI 1 "dop_not_illegal_const"
""))]
  ""
  "{
    if (GET_CODE(operands[0]) == MEM
        && !register_operand(operands[1], SImode)
        && !no_new_pseudos)
    {
      operands[1] = force_reg(SImode, operands[1]);
    }
  }")

(define_insn "*movsi_simple"
  [(set (match_operand:SI 0 "nonimmediate_operand"
"=r,r,r,m,r,r")
        (match_operand:SI 1 "general_operand"
"r,I,m,r,M,N"))]
  ""
  "@
  mov %0,%1
  mov %0,#%d1
  ldr.w %0,%1
  str.w %1,%0
  mvc.%e1 %0,#%d1
  #")

(and some more...)
---

My architecture is "sort of" similar to the ARM in
that I pass the first four arguments (or first four
words of arguments) in registers, with the rest on the
stack. This appears to be vaguely the area my problem
is in, because function calls with less than four
arguments seem to work correctly (more or less).

Tell me anything else you need to know to be able to
help me!

TIA,

Jules


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: Problem with new port

[Alleged Judas]

Hi,

I've now tracked down the problem I was having with
virtual-outgoing-args -- it turned out to be a macro I
had misdefined:

#define CONSTANT_ADDRESS_P(X) 1

which I changed to (similar to other ports):

#define CONSTANT_ADDRESS_P(X) \
  (GET_CODE(X) == SYMBOL_REF &&
CONSTANT_POOL_ADDRESS_P (X))

I'd like to take the opportunity to thank Dan and
Joern for the help they gave me. I'm sure there'll be
much more I need to know later...

Cheers,

Jules

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: Problem with new port

[Joern Rennecke]

> I don't think there should be any reference to
> virtual-outgoing-args at this stage.

Indeed.  function.c:instantiate_virtual_regs is supposed to
take care of these references.  I suggest to debug cc1 using
gdb, setting a breakpoint where instantiate_virtual_regs
works on the PATTERN of an individual insn,
        instantiate_virtual_regs_1 (&PATTERN (insn), insn, 1);
and conditionalize it on insn->fld[0].rtint == 42 .  Then
you look why this insn ddoesn't get the virtual register
reference replaced.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: Problem with new port

[Dan Towner]

Hi Jules,

I also encountered this problem when porting gcc. To fix it I defined an 
pattern which allowed an address operand (like the virtual-outgoing-args 
operand) to be assigned to a general operand:

(define_insn "*address_calc"
   [(set (match_operand:HI 0 "general_operand" "=r,r")
	(match_operand:HI 1 "address_operand" "p,r"))]
   ""
   "@
      ADD %b1,%o1,%0
      COPY %1,%0")

(Note that the ADD instruction allows a (reg+offset) to be assigned to a 
register).

This may be of help...

Dan.

> I'm in the process of porting GCC to a new
> architecture (of my own devising). I'm sort of
> stumbling around in the dark most of the time,
> although I have got to the stage where extremely basic
> test functions (factorial, strcpy) will sort-of
> compile.
> 
> Unfortunately I seem to have hit a problem which I'm
> finding rather difficult to track down, and I'm
> wondering if anyone can shed any light (the manual
> isn't much help). Basically, I have the following test
> functions:
> 
> ---
> int testfun(int a, int b, int c, int d, int e, int f,
> int g)
> {
>   return a+b+c+d+e+f+g;
> }
> 
> int infun(int d)
> {
>   return testfun(d, d+1, d+2, d+3, d+4, d+5, d+6);
> }
> ---
> 
> Now, the first function seems to compile OK, but the
> second gives this error:
> 
> ---
> jules@erwin:~/gcc-cvs/build$ gcc/xgcc -Bgcc -O2 -S
> ../foo.c -da
> ../foo.c: In function `infun':
> ../foo.c:58: error: insn does not satisfy its
> constraints:
> (insn 42 20 17 0 (nil) (set (reg:SI 8 r8)
>         (reg/f:SI 131 virtual-outgoing-args)) 1
> {*movsi_simple} (nil)
>     (nil))
> ../foo.c:58: internal compiler error: in
> reload_cse_simplify_operands, at reload1.c:8335
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html>
> for instructions.
> ---
> 
> I don't think there should be any reference to
> virtual-outgoing-args at this stage. I suspect the
> problem might be somewhere in my target description
> macros relating to function arguments (FUNCTION_ARG,
> the CUMULATIVE_ARG stuff) or else I have missed out a
> constraint I need in the movsi pattern (which seems
> obvious, but I can't see anything) or else I need
> reload_* patterns of some sort, which are currently
> absent.
> 
> The movsi pattern is defined as:
> 
> ---
> (define_expand "movsi"
>   [(set (match_operand:SI 0 "nonimmediate_operand" "")
>         (match_operand:SI 1 "dop_not_illegal_const"
> ""))]
>   ""
>   "{
>     if (GET_CODE(operands[0]) == MEM
>         && !register_operand(operands[1], SImode)
>         && !no_new_pseudos)
>     {
>       operands[1] = force_reg(SImode, operands[1]);
>     }
>   }")
> 
> (define_insn "*movsi_simple"
>   [(set (match_operand:SI 0 "nonimmediate_operand"
> "=r,r,r,m,r,r")
>         (match_operand:SI 1 "general_operand"
> "r,I,m,r,M,N"))]
>   ""
>   "@
>   mov %0,%1
>   mov %0,#%d1
>   ldr.w %0,%1
>   str.w %1,%0
>   mvc.%e1 %0,#%d1
>   #")
> 
> (and some more...)
> ---
> 
> My architecture is "sort of" similar to the ARM in
> that I pass the first four arguments (or first four
> words of arguments) in registers, with the rest on the
> stack. This appears to be vaguely the area my problem
> is in, because function calls with less than four
> arguments seem to work correctly (more or less).
> 
> Tell me anything else you need to know to be able to
> help me!
> 
> TIA,
> 
> Jules

=============================================================================
Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH, 
BA1 5BG
dant@picochip.com
07786 702589