Dummy questions on GCC internals

Dummy questions on GCC internals

[Alexander Aganichev]

Hi!

I have some dummy questions:-)

Is there a guide with GCC internal errors explanation? I'm in
progress of defining z80.md file and receive various
complaints like "Unrecognizable insn". How can I determine
what's wrong?

Another problem is "Internal error: abort in
find_matching_operand" in genrecog. I'm sure it's my fault,
but is there easy way to find it out?

Also, what is the major difference between define_insn and
define_expand ending with DONE?

Thanks in advance.

--
Alexander Aganichev

url: http://aaganichev.narod.ru
e-mail: aaganichev@yandex.ru
gsm: +7-095-786-1339

Re: Dummy questions on GCC internals

[Eric Christopher]

On Tue, 2003-05-20 at 22:25, Alexander Aganichev wrote:
> Hi!
> 
> I have some dummy questions:-)
> 
> Is there a guide with GCC internal errors explanation? I'm in
> progress of defining z80.md file and receive various
> complaints like "Unrecognizable insn". How can I determine
> what's wrong?
> 

This means that the compiler is attempting to generate a particular
pattern. Unfortunately you don't have one defined that matches it. You
either need to fix this, or find a way to stop that pattern from
generating out of the backend.

> Another problem is "Internal error: abort in
> find_matching_operand" in genrecog. I'm sure it's my fault,
> but is there easy way to find it out?
> 

Find the last bit of source code you modified? :)

> Also, what is the major difference between define_insn and
> define_expand ending with DONE?
> 

This is in the gcc internals manual, gccint.texi or available on the
documentation page on the gcc.gnu.org website.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Dummy questions on GCC internals

[Alexander Aganichev]

Eric,

>> Another problem is "Internal error: abort in
>> find_matching_operand" in genrecog. I'm sure it's my fault,
>> but is there easy way to find it out?

>Find the last bit of source code you modified? :)

I wrote whole .md from the scratch ;-) Though I found the line
by splitting file...

>> Also, what is the major difference between define_insn and
>> define_expand ending with DONE?
>This is in the gcc internals manual, gccint.texi or available on the
>documentation page on the gcc.gnu.org website.

Thanks.

One more question: what's meant under the "insn does not satisfy its
constraints"? I have addhi3 defined as:

(define_insn "addhi3"
  [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r")
        (plus:HI (match_operand:HI 1 "general_operand" "0,0")
                 (match_operand:HI 2 "general_operand" "ri,m")))]
  ""
  "@
  addhi3\t%2,%0
  addhi3\t(%2),%0")

and receive the following error:

z80-test/test.c: In function `m':
z80-test/test.c:12: error: insn does not satisfy its constraints:
(insn/f 55 54 56 0x0 (set (reg/f:HI 8 ix)
        (plus:HI (reg/f:HI 8 ix)
            (reg/f:HI 10 sp))) 8 {addhi3} (nil)
    (nil))
z80-test/test.c:12: internal compiler error: in final_scan_insn, at final.c:2722

Is it the problem in addhi3 definition or something else may influence
on this?

--
Alexander Aganichev

url: http://aaganichev.narod.ru
e-mail: aaganichev@yandex.ru
gsm: +7-095-786-1339

Re: Dummy questions on GCC internals

[DJ Delorie]

> One more question: what's meant under the "insn does not satisfy its
> constraints"? I have addhi3 defined as:
> 
> (define_insn "addhi3"
>   [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r")

The important thing to realize is that the predicate determines what
types of operands gcc will give to this insn, and the constraints do
*not*.  Thus, it is critically important that every type of operand
that the predicate allows be able to match at least one of the
constraints, or at least that the predicate reject any operand that
won't match any of the constraints.

In this case, a nonimmediate_operand allows memory references, which
do not match the "r" constraint.  You probably need a register_operand
predicate instead.

Note that you'll find yourself writing lots of target-specific (and
often insn-specific) predicates eventually.

Re: Dummy questions on GCC internals

[Eric Christopher]

> One more question: what's meant under the "insn does not satisfy its
> constraints"? I have addhi3 defined as:
> 

This means that the insn below doesn't match the pattern for addhi3.

> (define_insn "addhi3"
>   [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r")
>         (plus:HI (match_operand:HI 1 "general_operand" "0,0")
>                  (match_operand:HI 2 "general_operand" "ri,m")))]
>   ""
>   "@
>   addhi3\t%2,%0
>   addhi3\t(%2),%0")
> 
> and receive the following error:
> 
> z80-test/test.c: In function `m':
> z80-test/test.c:12: error: insn does not satisfy its constraints:
> (insn/f 55 54 56 0x0 (set (reg/f:HI 8 ix)
>         (plus:HI (reg/f:HI 8 ix)
>             (reg/f:HI 10 sp))) 8 {addhi3} (nil)
>     (nil))
> z80-test/test.c:12: internal compiler error: in final_scan_insn, at final.c:2722
> 
> Is it the problem in addhi3 definition or something else may influence
> on this?

Register classes can also affect this, though I'm not sure how 'r' would
interact off the top of my head since it's a general constraint. My
guess would be that for some reason it doesn't believe that sp is part
of 'r'. Not having the rest of the port... :)

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Dummy questions on GCC internals

[Ulrich Weigand]

DJ Delorie wrote:

>The important thing to realize is that the predicate determines what
>types of operands gcc will give to this insn, and the constraints do
>*not*.  Thus, it is critically important that every type of operand
>that the predicate allows be able to match at least one of the
>constraints, or at least that the predicate reject any operand that
>won't match any of the constraints.

Actually, as long as reload knows how to fix the insn up, the 
predicate may certainly accept operands that do not literally 
match any constraint.  In particular, reload knows how to load
an operand from memory into a register, and hence a combination
of a "nonimmediate_operand" predicate with an "r" constraint is
perfectly valid (even though it may or may not be more efficient
overall to use "register_operand" in that case).

In particular, in the original poster's case of 

(insn/f 55 54 56 0x0 (set (reg/f:HI 8 ix)
        (plus:HI (reg/f:HI 8 ix)
            (reg/f:HI 10 sp))) 8 {addhi3} (nil)
    (nil))

the operands *are* all in registers.  If this still doesn't match
the constraints, I can only assume that something is weird with
the register classes here (are those hard regs all in the class
GENERAL_REGS?).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de