Steve Ellcey <[EMAIL PROTECTED]> writes: > I noticed that gcc.dg/sms-antideps.c is failing on my IA64 Linux and > HP-UX platforms. The failure is: > > x.c: In function 'foo': > x.c:25: internal compiler error: in gen_sub2_insn, at optabs.c:4640 > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://gcc.gnu.org/bugs.html> for instructions. > > When I enter gen_sub2_insn the operands I have are: > > (reg:DI 332 ar.lc) and (const_int 0 [0x0]) > > It is generate_prolog_epilog (called by sms_schedule) in modulo-sched.c > that is trying to generate this subtract. First off: why am I > subracting zero? Shouldn't generate_prolog_epilog skip the subtraction > if last_stage is zero? > > I wind up dying because count_reg in this case is "ar.lc" (application > register, loop counter) and this register on the IA64 does not allow the > subtraction operation on it. All I can do with this register is to do a > move into it to initialize it and then use and decrement it in counted > loops (the doloop_end insn). How do I explain to the modulo scheduler > that it cannot do this optimization? Not doing the subtract when > last_stage is zero might make this one test case work but it would leave > open the larger problem of possibly generating a subtract instruction on > a register (count_reg) that does not allow that operation.
I think the modulo scheduler code is making some bad assumptions about the doloop pattern. The doloop insn is permitted to be special, and the register it uses is permitted to be special. Ian
