Could not split insn

Could not split insn

[Petar Penchev]

Hello all,
I have define "iorsi3" instruction in my .md file as follows :

(define_insn_and_split "iorsi3"
   [(set (match_operand:SI 0 "nonimmediate_nonstack_operand"		"=b,  o")
	(ior:SI (match_operand:SI 1 "nonimmediate_nonstack_operand"	"%0,  0")
		  (match_operand:SI 2 "general_operand"				"boi, boi")))
    (clobber (match_scratch:HI 3							"=X,  &r"))]
   ""
   "#"
   "reload_completed"
   [(const_int 0)]
   "split_logical(HImode, IOR, operands);
    DONE;"
)

Where constraint 'b' is general-purpose register, which supports SImode.
I tried to compile newlib with optimization -O1 and I have got folowing  
message:

../../../../../newlib_src/newlib/libc/stdlib/mprec.c: In function  
`_lshift':
../../../../../newlib_src/newlib/libc/stdlib/mprec.c:515: error: could not  
split insn
(insn 222 278 279 (parallel [
             (set (reg:SI 0 A)
                 (ior:SI (reg:SI 0 A)
                     (const_int 0 [0x0])))
             (clobber (scratch:HI))
         ]) 62 {iorsi3} (insn_list 96 (nil))
     (expr_list:REG_UNUSED (scratch:HI)
         (nil)))
../../../../../newlib_src/newlib/libc/stdlib/mprec.c:515: internal  
compiler error: in final_scan_insn, at final.c:2429

Register A is accessible in SImode.
But it seems to me that pattern should be matched by the split.


Does anybody have met the same problem ?



-- 
Regards
Petar Penchev

Re: Could not split insn

[Hans-Peter Nilsson]

On Mon, 13 Sep 2004, Petar Penchev wrote:
>
> Hello all,
> I have define "iorsi3" instruction in my .md file as follows :
>
> (define_insn_and_split "iorsi3"
>    [(set (match_operand:SI 0 "nonimmediate_nonstack_operand"		"=b,  o")
> 	(ior:SI (match_operand:SI 1 "nonimmediate_nonstack_operand"	"%0,  0")
> 		  (match_operand:SI 2 "general_operand"				"boi, boi")))
>     (clobber (match_scratch:HI 3							"=X,  &r"))]
>    ""
>    "#"
>    "reload_completed"
>    [(const_int 0)]
>    "split_logical(HImode, IOR, operands);
>     DONE;"
> )
>
> Where constraint 'b' is general-purpose register, which supports SImode.
> I tried to compile newlib with optimization -O1 and I have got folowing
> message:
>
> ../../../../../newlib_src/newlib/libc/stdlib/mprec.c: In function
> `_lshift':
> ../../../../../newlib_src/newlib/libc/stdlib/mprec.c:515: error: could not
> split insn
> (insn 222 278 279 (parallel [
>              (set (reg:SI 0 A)
>                  (ior:SI (reg:SI 0 A)
>                      (const_int 0 [0x0])))
>              (clobber (scratch:HI))
>          ]) 62 {iorsi3} (insn_list 96 (nil))
>      (expr_list:REG_UNUSED (scratch:HI)
>          (nil)))
> ../../../../../newlib_src/newlib/libc/stdlib/mprec.c:515: internal
> compiler error: in final_scan_insn, at final.c:2429
>
> Register A is accessible in SImode.
> But it seems to me that pattern should be matched by the split.

That depends entirely on the splitter code in split_logical(),
which you didn't show.

Besides, the constraint "o" seems wrong: it allows any
offsettable operand, which includes stack operands, supposedly
refused by nonimmediate_nonstack_operand.  You must not allow
operands in a constraint that are disallowed by the predicate.

> Does anybody have met the same problem ?

<evil>
I suppose you mean generally, bugs in an initial port?  You bet.
You *really* have to debug this on your own; sending port
snippets will not work.  Luckily, all the source code is there.
</evil>

;-)

brgds, H-P

Re: Could not split insn

[Hans-Peter Nilsson]

On Mon, 13 Sep 2004, Hans-Peter Nilsson wrote:
> That depends entirely on the splitter code in split_logical(),
> which you didn't show.

Sorry, I wasn't really correct.  What it does depend on is that
register 0 (operand 0 in your output) is in the regclass
corresponding to "b".  If it isn't, then your split_logical may
(still) be responsible.  Or it may be that some of the regclass
stuff in your port is wrong.  Bugs in a GCC port do not always
show themselves in an easy-to-find way.

brgds, H-P

Re: Could not split insn

[James E Wilson]

Petar Penchev wrote:
> ../../../../../newlib_src/newlib/libc/stdlib/mprec.c:515: error: could 
> not  split insn

Grep gcc to find where the error comes from, and then run cc1 under gdb 
and put a breakpoint there so you can step through the code.  Hint, this 
is a try_split call in final.c.

I would guess the bug is in split_logical, and since we don't have a 
copy of that function, we can't help you much.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Could not split insn

[Petar Penchev]

Thanks a lot,
The problem is in split_logigal. In this particular case gcc tries to  
generate code for X or 0, which has no sense.Thats why
split_logical does not emit any insns and the split returns NULL and that  
in final.c is interpreted as failure.

Regards Petar

RE: Could not split insn

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Hans-Peter Nilsson
> Sent: 14 September 2004 02:34

> Besides, the constraint "o" seems wrong: it allows any
> offsettable operand, which includes stack operands, supposedly
> refused by nonimmediate_nonstack_operand.  You must not allow
> operands in a constraint that are disallowed by the predicate.


  I know about the requirement that you must not allow operands through a
predicate that aren't accepted by at least one constraint, but this reverse
condition I'm surprised by, and I can't see anything in gccint that makes it
obvious to me what the consequences would be..... was this just a thinko, or is
there actually a problem both ways round?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

RE: Could not split insn

[Hans-Peter Nilsson]

On Tue, 14 Sep 2004, Dave Korn wrote:
> > -----Original Message-----
> > From: gcc-owner On Behalf Of Hans-Peter Nilsson
> > Sent: 14 September 2004 02:34
>
> > Besides, the constraint "o" seems wrong: it allows any
> > offsettable operand, which includes stack operands, supposedly
> > refused by nonimmediate_nonstack_operand.  You must not allow
> > operands in a constraint that are disallowed by the predicate.
>
>
>   I know about the requirement that you must not allow operands through a
> predicate that aren't accepted by at least one constraint,

Not exactly, it's ok as long as it can be fixed-up to fit at
least one constraint alternative.  You can say
"nonimmediate_operand" + "ro" and a non-offsettable memory
operand would always get successfully fixed-up to fit either "r"
or "o", but not as early as an immediate operand, which would
IIRC be loaded in a register *before* register allocation.
It's likely (but I didn't check) that there are a lot of
patterns that just use "general_operand", where e.g.
"nonimmediate_operand" would make more sense (and supposedly
give GCC/reload a better start).

> but this reverse
> condition I'm surprised by, and I can't see anything in gccint that makes it
> obvious to me what the consequences would be.....

I believe it'd be ICE or worse. :-)

> was this just a thinko, or is
> there actually a problem both ways round?

Quoteth the FM:

"The constraints allow you to fine-tune matching within the set
of operands allowed by the predicate"

...

"Thus the predicate must always recognize any objects allowed by
the constraint."

brgds, H-P

RE: Could not split insn

[Dave Korn]

> -----Original Message-----
> From: Hans-Peter Nilsson [mailto:hp@bitrange.com] 
> Sent: 14 September 2004 16:42

> > > Besides, the constraint "o" seems wrong: it allows any
> > > offsettable operand, which includes stack operands, supposedly
> > > refused by nonimmediate_nonstack_operand.  You must not allow
> > > operands in a constraint that are disallowed by the predicate.
> >
> >   I know about the requirement that you must not allow 
> operands through a
> > predicate that aren't accepted by at least one constraint,
> 
> Not exactly, it's ok as long as it can be fixed-up to fit at
> least one constraint alternative.  You can say
> "nonimmediate_operand" + "ro" and a non-offsettable memory
> operand would always get successfully fixed-up to fit either "r"
> or "o", but not as early as an immediate operand, which would
> IIRC be loaded in a register *before* register allocation.
> It's likely (but I didn't check) that there are a lot of
> patterns that just use "general_operand", where e.g.
> "nonimmediate_operand" would make more sense (and supposedly
> give GCC/reload a better start).

  My thanks, to both you and Richard Sandiford who sent me an off-list
explanation; I think I've just grokked something I didn't get before, which
is that recog and reload approach the insn pattern from opposite directions:
in recog the predicate is the first and most important thing that filters
down the possibilities, and then the constraints are best to match up with
what the predicate allows, whereas in reload the constraints drive the
process, and the result chosen had better be allowed by the predicate.  Is
that a reasonable way to look at it?

> > but this reverse
> > condition I'm surprised by, and I can't see anything in 
> gccint that makes it
> > obvious to me what the consequences would be.....
> 
> I believe it'd be ICE or worse. :-)

  /me shudders at the thought that anything could be worse than an ICE!
 
> > was this just a thinko, or is
> > there actually a problem both ways round?
> 
> Quoteth the FM:
> 
> "The constraints allow you to fine-tune matching within the set
> of operands allowed by the predicate"
> 
> ...
> 
> "Thus the predicate must always recognize any objects allowed by
> the constraint."

  Ah, gotcha.  I was looking at (well, remembering) the bit just below
that....

"   If the operand's predicate can recognize registers, but the constraint
does not permit them, it can make the compiler crash.  "

and perhaps mis-extrapolating it to a more general belief that if the
predicate permitted anything that there wasn't a suitable constraint
alternative for, the same would happen.  But I see now that that's actually
a very specific consequence of the fact that reload fixes things up by
loading them into registers, and by that stage it's far too late for
anything mid-end to try and rearrange it if the insn can't accept registers.

"  When this operand happens to be a register, the reload pass will be
stymied, because it does not know how to copy a register temporarily into
memory. "

  Right; this means that it's only the mid-end that knows about things like
spilling temporaries into stack slots, I think?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....