gcc port to StarCore

gcc port to StarCore

[David Livshin]

Hi,

I am working on the port of the gcc version 3.0.1 to the StarCore
architecture ( DSP from Motorola/Agere ). The compiler works fine and
produces correct StarCore code that passes all the validations ( I have ).
However there are cases where it can do better job:

1. no constant propagation:

compiling with '-O3'

x = 10;
y = 100;
if ( x > y )
 return 0;
....

generates code to actually compare 'x' and 'y' disregarding the fact that
comparison always produces the same result.

This is not done in other versions of gcc, so what may be wrong in my
implementation that prevents compiler from performing necessary
optimizations? I don't think this problem relates to implementation of
integer comparison, as e.g.

x = 10;
y = 100;
z = y/x;

generates code to perform the division.

2. loop handling

my port generates weird an unoptimal code for loops. The body of the loop is
often has jumps to it ( as in the example below ) and consist of the
disjoint blocks that are spread over the generated code. The best looking
loop I seen gcc generates is for the code ( compiled with -O3 ):

for ( i = 0; i < 100; i++ )
sum += i;

 moveu.l #0,d3
 bra __L_L__8
__L_L__5:
 add d3,d0,d0
 add #1,d3
__L_L__8:
 moveu.l #99,d1
 sxt.l d3
 sxt.l d1
 cmpgt d1,d3
 bf __L_L__5

The jump  "bra __L_L__8" is not necessary ( may be this relates to the first
problem I described ) but even if it is necessary to determine if loop is
executed, what may prevent gcc from doing it before entering the body of the
loop ( like it is done in other implementations of gcc )?
In addition to disallowing many loop optimizations ( e.g. motion of the loop
invariant "moveu.l #99,d1" that sets the register "d1' to 99, out of loop ),
it seems that such a structure of a loop prevents the compiler to utilize
"decrement_and_branch_until_zero" and "doloop_begin/end" found in the md
file.

Thank you in advance,

David Livshin
dlivshin@internet-zahav.net
Tel:      +972 - 8 - 935 - 4597
Mobile: +972 - 67 - 290 - 998
Laskov 11/31
Rehovot, 76654
Israel

Re: gcc port to StarCore

[Alan Lehotsky]

At 3:23 PM +0200 5/1/02, David Livshin wrote:
>Hi,
>
>I am working on the port of the gcc version 3.0.1 to the StarCore
>architecture ( DSP from Motorola/Agere ). The compiler works fine and
>produces correct StarCore code that passes all the validations ( I have ).
>However there are cases where it can do better job:
>
>1. no constant propagation:


	My "guess" would be that you don't allow CONST_INT's as operands
	to the "cmpsi" patterns.

	Can you post the define_expand and/or define_insn for these?

>.....
.....
-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

Re: gcc port to StarCore

[David Livshin]

----- Original Message -----
From: Alan Lehotsky <apl@alum.mit.edu>
To: David Livshin <dlivshin@zahav.net.il>
Cc: <gcc@gcc.gnu.org>
Sent: Wednesday, May 01, 2002 3:00 PM
Subject: Re: gcc port to StarCore


> At 3:23 PM +0200 5/1/02, David Livshin wrote:
> >Hi,
> >
> >I am working on the port of the gcc version 3.0.1 to the StarCore
> >architecture ( DSP from Motorola/Agere ). The compiler works fine and
> >produces correct StarCore code that passes all the validations ( I
have ).
> >However there are cases where it can do better job:
> >
> >1. no constant propagation:
>
>
> My "guess" would be that you don't allow CONST_INT's as operands
> to the "cmpsi" patterns.
>
> Can you post the define_expand and/or define_insn for these?
>

You are right - the pattern is:


( define_expand "cmpsi"
  [ ( set ( cc0 )
      ( compare ( match_operand:SI 0 "drREG_operand" "d,z" )
                ( match_operand:SI 1 "drREG_operand" "d,z" )
      )
    )
  ]
  ""
  "
  {
   StarCore_DefineExpand_cmp( operands, FALSE, FALSE );
   DONE;
  }"
)

where "drREG_operand" is a predicate that excepts d ( constraint letter
'd' ) and r ( constraint letter 'z' ) registers.

However this doesn't seem to be the reason for the problem I have because
the pattern:


( define_expand "cmpsi"
  [ ( set ( cc0 )
      ( compare ( match_operand:SI 0 "general_operand" "" )
                ( match_operand:SI 1 "general_operand" "" )
      )
    )
  ]
  ""
  "
  {
   StarCore_DefineExpand_cmp( operands, FALSE, FALSE );
   DONE;
  }"
)

produces the same code for the program I mentioned.

Re: gcc port to StarCore

[Richard Henderson]

On Thu, May 02, 2002 at 08:38:23AM +0200, David Livshin wrote:
> However this doesn't seem to be the reason for the problem I have because
> the pattern:
> 
> ( define_expand "cmpsi"

No, the define_expand is irrelevant.  It's the define_insn 
that matters here.


r~

Re: gcc port to StarCore

[David Livshin]

----- Original Message -----
From: Richard Henderson <rth@redhat.com>
To: David Livshin <dlivshin@zahav.net.il>
Cc: Alan Lehotsky <apl@alum.mit.edu>; <gcc@gcc.gnu.org>
Sent: Thursday, May 02, 2002 8:22 AM
Subject: Re: gcc port to StarCore


> On Thu, May 02, 2002 at 08:38:23AM +0200, David Livshin wrote:
> > However this doesn't seem to be the reason for the problem I have
because
> > the pattern:
> >
> > ( define_expand "cmpsi"
>
> No, the define_expand is irrelevant.  It's the define_insn
> that matters here.
>
>
> r~

Are you saying that in order to benefit from constant propagation in the:

x = 10;
y = 100;
if ( x > y )
...

'define_expand "cmpsi"' may not be used?

Would you please direct me to a material ( source code and/or document )
that may clarify the way this optimization is implemented by the GNU
compiler. Right now I even cant guess what it might be. For example I tried
in md:

( define_insn "addsi3"
  [ ( set
      ( match_operand:SI 0 "register_operand"             "" )
      ( plus:SI ( match_operand:SI 1 "general_operand"   "" )
                ( match_operand:SI 2 "general_operand" "" )
      )
    )
  ]
....

and then compiled:

x = 10;
y = 100;
z = x + y;
...

It seems from the resulting code:

 moveu.l #10,d0
 move.l d0,_x
 moveu.l #100,d2
 move.l d2,_y
 add #10,d2,d2
 move.l d2,_z

that compiler understands that 'x' is equal to 10 but misses the fact that
'y' is also a constant and 'z' is always equal to 110( or something inside
the compiler forces the generation of the add instruction ). Just in-case
you are wondering: description of "movsi"  in my md file allows load of any
constant to any register.

Thank you,

David

Re: gcc port to StarCore

[Alan Lehotsky]

At 8:38 AM +0200 5/2/02, David Livshin wrote:
>
>  > Can you post the define_expand and/or define_insn for these?
>>
>
>You are right - the pattern is:
>
>
>( define_expand "cmpsi"
>   [ ( set ( cc0 )
>       ( compare ( match_operand:SI 0 "drREG_operand" "d,z" )
>                 ( match_operand:SI 1 "drREG_operand" "d,z" )
>       )
>     )
>   ]
>   ""
>   "
>   {
>    StarCore_DefineExpand_cmp( operands, FALSE, FALSE );
>    DONE;
>   }"
>)


Well, this would prevent the initial generation of compares with 
literals as operands - but for most ports, the compiler will 
initially "load" literals into pseudo-registers ANYWAY and let the 
various optimization passes figure out which things are better off as 
immediate values.

I should have just asked for your DEFINE_INSN that matches the 
compare patterns.   Also, you
use a function to actually generate the RTL - so I can't see what 
sort of RTL you're really producing
or consuming!

How about posting:

	1/ The rtl dump for your simple example - the first one, and 
possibly the
	     combine dump.

	2/ the DEFINE_INSNs for compares



-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

Re: gcc port to StarCore

[Alan Lehotsky]

At 3:16 PM +0200 5/2/02, David Livshin wrote:
>.....
>
>Are you saying that in order to benefit from constant propagation in the:
>
>x = 10;
>y = 100;
>if ( x > y )
>...
>
>'define_expand "cmpsi"' may not be used?


Not to put words in Richard's mouth.....but.....

What he's saying is that the DEFINE_EXPAND just produces the initial 
RTL, and as I mentioned earlier, the compiler will normally decide to 
load immediates to pseudos when it initially generates code.  You
HAVE to use the "cmpsi" pattern otherwise, you'd never generate any 
compare RTL (although I think it may be the case that the compiler 
can generate calls to the runtime library to do compares out-of-line)


>Would you please direct me to a material ( source code and/or document )
>that may clarify the way this optimization is implemented by the GNU
>compiler. Right now I even cant guess what it might be. For example I tried
>in md:
>
>( define_insn "addsi3"
>   [ ( set
>       ( match_operand:SI 0 "register_operand"             "" )
>       ( plus:SI ( match_operand:SI 1 "general_operand"   "" )
>                 ( match_operand:SI 2 "general_operand" "" )
>       )
>     )
>   ]
>....

Okay.  This pattern is missing all constraints.  (The characters 
inside the last "" on each match_operand)
I'm not certain that would prevent constant folding (in fact I can't 
imagine how it could), but you should fix that before looking for 
other problems....

The other thing that occurs to me is whether you've defined the 
various COSTS macros (CONST_COSTS, ADDRESS_COST and RTX_COST).  Also 
check your LEGITIMATE_CONSTANT_P macro is reasonable....


>and then compiled:
>
>x = 10;
>y = 100;
>z = x + y;
>...
>
>It seems from the resulting code:
>
>  moveu.l #10,d0
>  move.l d0,_x
>  moveu.l #100,d2
>  move.l d2,_y
>  add #10,d2,d2
>  move.l d2,_z
>
>that compiler understands that 'x' is equal to 10 but misses the fact that
>'y' is also a constant and 'z' is always equal to 110( or something inside
>the compiler forces the generation of the add instruction ). Just in-case
>you are wondering: description of "movsi"  in my md file allows load of any
>constant to any register.

An RTL dump would be a good thing to see, just to insure that the RTL 
you generated isn't munged in some unpredictable fashion.

>Thank you,
>
>David


-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

Re: gcc port to StarCore

[David Livshin]

----- Original Message -----
From: Alan Lehotsky <apl@alum.mit.edu>
To: David Livshin <dlivshin@zahav.net.il>
Cc: <gcc@gcc.gnu.org>
Sent: Thursday, May 02, 2002 2:20 PM
Subject: Re: gcc port to StarCore


> At 8:38 AM +0200 5/2/02, David Livshin wrote:
> >
> >  > Can you post the define_expand and/or define_insn for these?
> >>
> >
> >You are right - the pattern is:
> >
> >
> >( define_expand "cmpsi"
> >   [ ( set ( cc0 )
> >       ( compare ( match_operand:SI 0 "drREG_operand" "d,z" )
> >                 ( match_operand:SI 1 "drREG_operand" "d,z" )
> >       )
> >     )
> >   ]
> >   ""
> >   "
> >   {
> >    StarCore_DefineExpand_cmp( operands, FALSE, FALSE );
> >    DONE;
> >   }"
> >)
>
>
> Well, this would prevent the initial generation of compares with
> literals as operands - but for most ports, the compiler will
> initially "load" literals into pseudo-registers ANYWAY and let the
> various optimization passes figure out which things are better off as
> immediate values.
>
> I should have just asked for your DEFINE_INSN that matches the
> compare patterns.   Also, you
> use a function to actually generate the RTL - so I can't see what
> sort of RTL you're really producing
> or consuming!

StarCore_DefineExpand_cmp( operands, FALSE, FALSE );

is just saving operands and data about comapre ( e.g. is it FloatingPoint
compare ):


void StarCore_DefineExpand_cmp( rtx *operands, bool Is_FP, bool Is_TST )
 {

  StarCore_cmp.op0 = operands[0];
  StarCore_cmp.op1 = operands[1];
  StarCore_cmp.IsFP = Is_FP;
  StarCore_cmp.IsTST = Is_TST;

 }    /*    StarCore_DefineExpand_cmp    */


>
> How about posting:
>
> 1/ The rtl dump for your simple example - the first one, and
> possibly the
>      combine dump.

Will gladly do that if my guess ( that follows ) is wrong.

>
> 2/ the DEFINE_INSNs for compares

after expanding "cmpsi" as described above I expand conditional jumps ( e.g.
"bgt" ) emitting, among other things,

     emit_insn( gen_cmpsiEXPANDED( StarCore_cmp.op0, StarCore_cmp.op1,
                                    GEN_INT( ( int )cndt_code ),
                                    gen_reg_rtx( SImode ) ) );

where:


( define_insn "cmpsiEXPANDED"
  [ ( parallel [ ( unspec:SI [ ( match_operand:SI 0 "drREG_operand" "d,z" )
                               ( match_operand:SI 1 "drREG_operand" "d,z" )
                               ( match_operand:SI 2 "immediate_operand" "" )
                             ]
                             UNSPEC_CMPsi
                 )
                 ( set ( cc0 ) ( match_operand:SI 3 "" "" ) )
               ]
    )
  ]
  ""
  "* return (char *)StarCore_DefineInsn_cmpsi( operands, insn );"
)

with StarCore_DefineInsn_cmpsi being routine that just emits StarCore
machine code.

Is "unspec' what is preventing constant holding in compare?

Re: gcc port to StarCore

[Alan Lehotsky]

BINGO.  The RTL dump would have shown us an UNSPEC in the chain AND 
the compiler doesn't know
ANYTHING about UNSPECs.  [Gee, it might be a good thing to add a 
"remark" to the Porting guide near the definition and examples of 
UNSPEC to warn people about this - I remember it biting me about 5 
years ago while working on the SHARC port.]

You really don't want to use UNSPEC for things that have any 
"reasonable" semantic meaning
that can be expressed in the standard RTL.


At 5:36 PM +0200 5/2/02, David Livshin wrote:
>......
>  > 2/ the DEFINE_INSNs for compares
>
>after expanding "cmpsi" as described above I expand conditional jumps ( e.g.
>"bgt" ) emitting, among other things,
>
>      emit_insn( gen_cmpsiEXPANDED( StarCore_cmp.op0, StarCore_cmp.op1,
>                                     GEN_INT( ( int )cndt_code ),
>                                     gen_reg_rtx( SImode ) ) );
>
>where:
>
>
>( define_insn "cmpsiEXPANDED"
>   [ ( parallel [ ( unspec:SI [ ( match_operand:SI 0 "drREG_operand" "d,z" )
>                                ( match_operand:SI 1 "drREG_operand" "d,z" )
>                                ( match_operand:SI 2 "immediate_operand" "" )
>                              ]
>                              UNSPEC_CMPsi
>                  )
>                  ( set ( cc0 ) ( match_operand:SI 3 "" "" ) )
>                ]
>     )
>   ]
>   ""
>   "* return (char *)StarCore_DefineInsn_cmpsi( operands, insn );"
>)
>
>with StarCore_DefineInsn_cmpsi being routine that just emits StarCore
>machine code.
>
>Is "unspec' what is preventing constant holding in compare?


-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

Re: gcc port to StarCore

[David Livshin]

Alan,

Thank you very much for your help and assistance!

Do you think that poor quality of the code for loops, generated by my port
( that I reported earlier ), may be caused by the way I am ( currently )
handling integer compare?

I hope I will be able to improve generated code based of your advice.

Thanks again.

Regards,

David Livshin
dlivshin@internet-zahav.net
Tel:      +972 - 8 - 935 - 4597
Mobile: +972 - 67 - 290 - 998
Laskov 11/31
Rehovot, 76654
Israel

http://www.dalsoft.esmartweb.com/


----- Original Message -----
From: Alan Lehotsky <apl@alum.mit.edu>
To: David Livshin <dlivshin@zahav.net.il>
Cc: <gcc@gcc.gnu.org>
Sent: Thursday, May 02, 2002 5:01 PM
Subject: Re: gcc port to StarCore


> BINGO.  The RTL dump would have shown us an UNSPEC in the chain AND
> the compiler doesn't know
> ANYTHING about UNSPECs.  [Gee, it might be a good thing to add a
> "remark" to the Porting guide near the definition and examples of
> UNSPEC to warn people about this - I remember it biting me about 5
> years ago while working on the SHARC port.]
>
> You really don't want to use UNSPEC for things that have any
> "reasonable" semantic meaning
> that can be expressed in the standard RTL.
>
>
> At 5:36 PM +0200 5/2/02, David Livshin wrote:
> >......
> >  > 2/ the DEFINE_INSNs for compares
> >
> >after expanding "cmpsi" as described above I expand conditional jumps (
e.g.
> >"bgt" ) emitting, among other things,
> >
> >      emit_insn( gen_cmpsiEXPANDED( StarCore_cmp.op0, StarCore_cmp.op1,
> >                                     GEN_INT( ( int )cndt_code ),
> >                                     gen_reg_rtx( SImode ) ) );
> >
> >where:
> >
> >
> >( define_insn "cmpsiEXPANDED"
> >   [ ( parallel [ ( unspec:SI [ ( match_operand:SI 0 "drREG_operand"
"d,z" )
> >                                ( match_operand:SI 1 "drREG_operand"
"d,z" )
> >                                ( match_operand:SI 2 "immediate_operand"
"" )
> >                              ]
> >                              UNSPEC_CMPsi
> >                  )
> >                  ( set ( cc0 ) ( match_operand:SI 3 "" "" ) )
> >                ]
> >     )
> >   ]
> >   ""
> >   "* return (char *)StarCore_DefineInsn_cmpsi( operands, insn );"
> >)
> >
> >with StarCore_DefineInsn_cmpsi being routine that just emits StarCore
> >machine code.
> >
> >Is "unspec' what is preventing constant holding in compare?
>
>
> --
>     Quality Software Management
> http://home.earthlink.net/~qsmgmt
>           apl@alum.mit.edu
>           (978)287-0435 Voice
>           (978)808-6836 Cell
>
> Software Process Improvement / Management Consulting
>      Language Design / Compiler Implementation

Re: gcc port to StarCore

[David Livshin]

----- Original Message -----
From: Alan Lehotsky <apl@alum.mit.edu>
To: David Livshin <dlivshin@zahav.net.il>
Cc: Richard Henderson <rth@redhat.com>; <gcc@gcc.gnu.org>
Sent: Thursday, May 02, 2002 2:42 PM
Subject: Re: gcc port to StarCore


> At 3:16 PM +0200 5/2/02, David Livshin wrote:
> >.....
> >
> >Are you saying that in order to benefit from constant propagation in the:
> >
> >x = 10;
> >y = 100;
> >if ( x > y )
> >...
> >
> >'define_expand "cmpsi"' may not be used?
>
>
> Not to put words in Richard's mouth.....but.....
>
> What he's saying is that the DEFINE_EXPAND just produces the initial
> RTL, and as I mentioned earlier, the compiler will normally decide to
> load immediates to pseudos when it initially generates code.  You
> HAVE to use the "cmpsi" pattern otherwise, you'd never generate any
> compare RTL (although I think it may be the case that the compiler
> can generate calls to the runtime library to do compares out-of-line)
>

I meant to ask if I have to use 'define_insn "cmpsi"' instead of
'define_expand "cmpsi"'

>
> >Would you please direct me to a material ( source code and/or document )
> >that may clarify the way this optimization is implemented by the GNU
> >compiler. Right now I even cant guess what it might be. For example I
tried
> >in md:
> >
> >( define_insn "addsi3"
> >   [ ( set
> >       ( match_operand:SI 0 "register_operand"             "" )
> >       ( plus:SI ( match_operand:SI 1 "general_operand"   "" )
> >                 ( match_operand:SI 2 "general_operand" "" )
> >       )
> >     )
> >   ]
> >....
>
> Okay.  This pattern is missing all constraints.  (The characters
> inside the last "" on each match_operand)
> I'm not certain that would prevent constant folding (in fact I can't
> imagine how it could), but you should fix that before looking for
> other problems....
>
> The other thing that occurs to me is whether you've defined the
> various COSTS macros (CONST_COSTS, ADDRESS_COST and RTX_COST).  Also
> check your LEGITIMATE_CONSTANT_P macro is reasonable....

I will check it out and if wouldn't find any problems I will send you RTL
dump as you requested.

Thank you,

David

>
>
> >and then compiled:
> >
> >x = 10;
> >y = 100;
> >z = x + y;
> >...
> >
> >It seems from the resulting code:
> >
> >  moveu.l #10,d0
> >  move.l d0,_x
> >  moveu.l #100,d2
> >  move.l d2,_y
> >  add #10,d2,d2
> >  move.l d2,_z
> >
> >that compiler understands that 'x' is equal to 10 but misses the fact
that
> >'y' is also a constant and 'z' is always equal to 110( or something
inside
> >the compiler forces the generation of the add instruction ). Just in-case
> >you are wondering: description of "movsi"  in my md file allows load of
any
> >constant to any register.
>
> An RTL dump would be a good thing to see, just to insure that the RTL
> you generated isn't munged in some unpredictable fashion.
>

Re: gcc port to StarCore

[Alan Lehotsky]

At 12:21 PM +0200 5/3/02, David Livshin wrote:
>Alan,
>
>Thank you very much for your help and assistance!

Just returning a fraction of the favors I've received from the other 
readers of this list.

>Do you think that poor quality of the code for loops, generated by my port
>( that I reported earlier ), may be caused by the way I am ( currently )
>handling integer compare?

There's a very good chance of that.  The UNSPEC confuses attempts to 
"reason about" the
loop behavior, I'd guess.

>I hope I will be able to improve generated code based of your advice.
>
>Thanks again.
>

At 12:33 PM +0200 5/3/02, David Livshin wrote:
>  >
>
>I meant to ask if I have to use 'define_insn "cmpsi"' instead of
>'define_expand "cmpsi"'

No. using named DEFINE_INSNs is just a shortcut for the common case 
where the RTL expansion
done by the front-end (which uses the named patterns like "addsi3" or 
"cmpsi") is the trivial
pattern provided in the DEFINE_xxx.  In those cases, you don't need a 
DEFINE_EXPAND _AND_
a DEFINE_INSN - the DEFINE_INSN provides both pieces of functionality 
- the conversion from tree
to RTL and the conversion of RTL to assembly-language instructions.

>......
>  > The other thing that occurs to me is whether you've defined the
>>  various COSTS macros (CONST_COSTS, ADDRESS_COST and RTX_COST).  Also
>>  check your LEGITIMATE_CONSTANT_P macro is reasonable....
>
>I will check it out and if wouldn't find any problems I will send you RTL
>dump as you requested.
>

I'm pretty sure that your biggest problem is using the UNSPECs.. 
You'll want to do those
other things, because it will help you generate better code (by 
identifying WHEN it's better
to load a common sub-expression into a register, for example), but 
those are second-order
kinds of improvements and the compiler typically does almost the 
right thing by default.....

-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

Re: gcc port to StarCore

[Richard Henderson]

On Fri, May 03, 2002 at 12:33:07PM +0200, David Livshin wrote:
> I meant to ask if I have to use 'define_insn "cmpsi"' instead of
> 'define_expand "cmpsi"'

No.



r~

Re: gcc port to StarCore

[Ian Lance Taylor]

David Livshin <david.livshin@dalsoft.com> writes:

> >> x.c: In function ‘bar’:
> >> x.c:13: error: unrecognizable insn:
> >> (jump_insn 26 25 27 2 (set (pc)
> >>         (reg:SI 52)) -1 (nil)
> >>     (nil))
> >> x.c:13: internal compiler error: in extract_insn, at recog.c:2084
> >>
> >>
> >> The .md file defines ( mandatory ) "indirect_jump" which allows ( a certain kind of ) register as parameter.
> >> What is missing?
> >>
> >
> > Either the pattern doesn't match indirect_jump, or the instruction
> > predicate returns zero, or the operand predicate returns zero.
> >
> > Beyond that we don't have enough information to say.
> >
> > Ian
> >
> Is there a way to find out what was the pattern?

There is no automatic way to find the pattern.  But for this simple
pattern you should hopefully just be able to look into the MD file to
see which one looks like (set (pc) (match_operand ...)).

> And if the operand
> predicate fails, shouldn't gcc attempt to reassign the ( register ,
> "(reg:SI 52)" ) operand in order to satisfy the predicate?

No.  The operand predicate must match or the insn won't match.  Then,
for any operand for which the predicate matches, there must be a
constraint which reload can use for the operand.  That is, given that
the operand predicate matches, reload will modify the operand to
satisfy the constraints.

Ian

Re: gcc port to StarCore

[David Livshin]

Ian Lance Taylor wrote:
> David Livshin <david.livshin@dalsoft.com> writes:
>
>   
>> x.c: In function ‘bar’:
>> x.c:13: error: unrecognizable insn:
>> (jump_insn 26 25 27 2 (set (pc)
>>         (reg:SI 52)) -1 (nil)
>>     (nil))
>> x.c:13: internal compiler error: in extract_insn, at recog.c:2084
>>
>>
>> The .md file defines ( mandatory ) "indirect_jump" which allows ( a certain kind of ) register as parameter.
>> What is missing?
>>     
>
> Either the pattern doesn't match indirect_jump, or the instruction
> predicate returns zero, or the operand predicate returns zero.
>
> Beyond that we don't have enough information to say.
>
> Ian
>   
Is there a way to find out what was the pattern? And if the operand 
predicate fails, shouldn't gcc attempt to reassign the ( register , 
"(reg:SI 52)" ) operand in order to satisfy the predicate?

-- 
David Livshin

http://www.dalsoft.com

Re: gcc port to StarCore

[Ian Lance Taylor]

David Livshin <david.livshin@dalsoft.com> writes:

> x.c: In function ‘bar’:
> x.c:13: error: unrecognizable insn:
> (jump_insn 26 25 27 2 (set (pc)
>         (reg:SI 52)) -1 (nil)
>     (nil))
> x.c:13: internal compiler error: in extract_insn, at recog.c:2084
> 
> 
> The .md file defines ( mandatory ) "indirect_jump" which allows ( a certain kind of ) register as parameter.
> What is missing?

Either the pattern doesn't match indirect_jump, or the instruction
predicate returns zero, or the operand predicate returns zero.

Beyond that we don't have enough information to say.

Ian

gcc port to StarCore

[David Livshin]

Hi,

I am converting my StarCore port of the gcc version 3.2 to the current version 4.1.1.
The following program ( part of the gcc's testsuite )

void bar(int *pc) {
  static const void *l[] = {&&lab0, &&end};

  foo(0);
  goto *l[*pc];
 lab0:
  foo(0);
  pc++;
  goto *l[*pc];
 end:
  return;
}


successfully compiled under 3.2 but under 4.1.1 I am getting the following error:


x.c: In function ‘bar’:
x.c:13: error: unrecognizable insn:
(jump_insn 26 25 27 2 (set (pc)
        (reg:SI 52)) -1 (nil)
    (nil))
x.c:13: internal compiler error: in extract_insn, at recog.c:2084


The .md file defines ( mandatory ) "indirect_jump" which allows ( a certain kind of ) register as parameter.
What is missing?

Thank you in advance,

David


-- 
David Livshin

http://www.dalsoft.com

Re: gcc port to StarCore

[Richard Henderson]

On Mon, May 20, 2002 at 07:48:35AM +0200, David Livshin wrote:
> Should I submit the original mail as a bug report?

Um, only if you provide enough to actually reproduce
the problem.


r~

Re: gcc port to StarCore

[David Livshin]

----- Original Message ----- 
From: Richard Henderson <rth@redhat.com>
To: David Livshin <dlivshin@zahav.net.il>
Cc: <gcc@gcc.gnu.org>
Sent: Friday, May 17, 2002 10:58 PM
Subject: Re: gcc port to StarCore


> On Fri, May 17, 2002 at 01:26:07PM +0200, David Livshin wrote:
> > (insn 17 32 11 (set (cc0)
> >         (compare (reg:SI 3 d3 [43])
> >             (reg:SI 2 d2 [44]))) 63 {cmpsiEXPANDED} (nil)
> >     (nil))
> > ;; End of basic block 0, registers live:
> >  23 [r7] 32 [sp]
> > 
> > ( jump instruction being deleted ).
> > 
> > Is that correct?
> 
> Nope.
> 
> > What could be wrong in my implementation?
> 
> Probably nothing.
> 
> 
> r~

Should I submit the original mail as a bug report?

Re: gcc port to StarCore

[Richard Henderson]

On Fri, May 17, 2002 at 01:26:07PM +0200, David Livshin wrote:
> (insn 17 32 11 (set (cc0)
>         (compare (reg:SI 3 d3 [43])
>             (reg:SI 2 d2 [44]))) 63 {cmpsiEXPANDED} (nil)
>     (nil))
> ;; End of basic block 0, registers live:
>  23 [r7] 32 [sp]
> 
> ( jump instruction being deleted ).
> 
> Is that correct?

Nope.

> What could be wrong in my implementation?

Probably nothing.


r~

gcc port to StarCore

[David Livshin]

Hi,

I am working on the port of the gcc version 3.0.1 to the StarCore
architecture ( DSP from Motorola/Agere ). Compiling ( without
optimizations ):

foo()
{
 int i;

 switch (i)
  case 1:
   break;
}

compiler generates the following pattern:
  ...

(insn 17 32 18 (set (cc0)
        (compare (reg:SI 3 d3 [43])
            (reg:SI 2 d2 [44]))) 63 {cmpsiEXPANDED} (nil)
    (nil))

(jump_insn 18 17 29 (set (pc)
        (if_then_else (eq (cc0)
                (const_int 0 [0x0]))
            (label_ref 21)
            (pc))) 52 {beqEXPANDED} (nil)
    (nil))
;; End of basic block 0, registers live:
 23 [r7] 32 [sp]

;; Start of basic block 1, registers live: 23 [r7] 32 [sp]
  ...

which stays valid till flow analysis ( last seen in ".postpreload" dump ).
In ".flow2" dump the above pattern is transformed into:


(insn 17 32 11 (set (cc0)
        (compare (reg:SI 3 d3 [43])
            (reg:SI 2 d2 [44]))) 63 {cmpsiEXPANDED} (nil)
    (nil))
;; End of basic block 0, registers live:
 23 [r7] 32 [sp]

( jump instruction being deleted ).

Is that correct? Documentation states that "GCC always generates a pair of
consecutive RTL insns, possibly separated by note insns, one to set the
condition code and one to test it, and _keeps the pair inviolate until the
end_."

While handling compare I am calling "next_cc0_usr" which in this case
returned 0; In addition to that I tried "find_reg_note (insn, REG_UNUSED,
cc0_rtx)" but it also failed. If the observed behavior of gcc is correct,
how should I treat this situation ( e.g. not generate code for compare )?

I checked my implementation of NOTICE_UPDATE_CC and it performed
CC_STATUS_INIT before handling compare ( as required ).

What could be wrong in my implementation?

Thank you in advance,

David Livshin
dlivshin@internet-zahav.net
Tel:      +972 - 8 - 935 - 4597
Mobile: +972 - 67 - 290 - 998
Laskov 11/31
Rehovot, 76654
Israel

http://www.dalsoft.esmartweb.com/