* Could not split insn @ 2004-09-13 9:55 Petar Penchev 2004-09-14 2:02 ` Hans-Peter Nilsson 2004-09-14 3:05 ` James E Wilson 0 siblings, 2 replies; 8+ messages in thread From: Petar Penchev @ 2004-09-13 9:55 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Could not split insn 2004-09-13 9:55 Could not split insn Petar Penchev @ 2004-09-14 2:02 ` Hans-Peter Nilsson 2004-09-14 2:09 ` Hans-Peter Nilsson ` (2 more replies) 2004-09-14 3:05 ` James E Wilson 1 sibling, 3 replies; 8+ messages in thread From: Hans-Peter Nilsson @ 2004-09-14 2:02 UTC (permalink / raw) To: Petar Penchev; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Could not split insn 2004-09-14 2:02 ` Hans-Peter Nilsson @ 2004-09-14 2:09 ` Hans-Peter Nilsson 2004-09-14 10:22 ` Petar Penchev 2004-09-14 13:40 ` Dave Korn 2 siblings, 0 replies; 8+ messages in thread From: Hans-Peter Nilsson @ 2004-09-14 2:09 UTC (permalink / raw) To: Petar Penchev; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Could not split insn 2004-09-14 2:02 ` Hans-Peter Nilsson 2004-09-14 2:09 ` Hans-Peter Nilsson @ 2004-09-14 10:22 ` Petar Penchev 2004-09-14 13:40 ` Dave Korn 2 siblings, 0 replies; 8+ messages in thread From: Petar Penchev @ 2004-09-14 10:22 UTC (permalink / raw) To: Hans-Peter Nilsson, James E Wilson; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Could not split insn 2004-09-14 2:02 ` Hans-Peter Nilsson 2004-09-14 2:09 ` Hans-Peter Nilsson 2004-09-14 10:22 ` Petar Penchev @ 2004-09-14 13:40 ` Dave Korn 2004-09-14 16:54 ` Hans-Peter Nilsson 2 siblings, 1 reply; 8+ messages in thread From: Dave Korn @ 2004-09-14 13:40 UTC (permalink / raw) To: 'Hans-Peter Nilsson', 'Petar Penchev'; +Cc: gcc > -----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.... ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Could not split insn 2004-09-14 13:40 ` Dave Korn @ 2004-09-14 16:54 ` Hans-Peter Nilsson 2004-09-14 17:52 ` Dave Korn 0 siblings, 1 reply; 8+ messages in thread From: Hans-Peter Nilsson @ 2004-09-14 16:54 UTC (permalink / raw) To: Dave Korn; +Cc: 'Petar Penchev', gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Could not split insn 2004-09-14 16:54 ` Hans-Peter Nilsson @ 2004-09-14 17:52 ` Dave Korn 0 siblings, 0 replies; 8+ messages in thread From: Dave Korn @ 2004-09-14 17:52 UTC (permalink / raw) To: 'Hans-Peter Nilsson'; +Cc: 'Petar Penchev', gcc > -----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.... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Could not split insn 2004-09-13 9:55 Could not split insn Petar Penchev 2004-09-14 2:02 ` Hans-Peter Nilsson @ 2004-09-14 3:05 ` James E Wilson 1 sibling, 0 replies; 8+ messages in thread From: James E Wilson @ 2004-09-14 3:05 UTC (permalink / raw) To: Petar Penchev; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-09-14 16:54 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-13 9:55 Could not split insn Petar Penchev 2004-09-14 2:02 ` Hans-Peter Nilsson 2004-09-14 2:09 ` Hans-Peter Nilsson 2004-09-14 10:22 ` Petar Penchev 2004-09-14 13:40 ` Dave Korn 2004-09-14 16:54 ` Hans-Peter Nilsson 2004-09-14 17:52 ` Dave Korn 2004-09-14 3:05 ` James E Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).