On Tue, Dec 10, 2013 at 4:17 PM, Claudiu Zissulescu wrote: > Hi, > > Our ARC processor has a multiplication operation that returns a 64 bit result > into a fixed register pair named <mlo,mhi> like this: > > mlo:DI=zero_extend(r159:SI)*sign_extend(r181:SI) > > The GCSE rtl pre step has some difficulties to handle hard register pair > information. To exemplify my problem please see the following example: > > 18: mlo:DI=zero_extend(r159:SI)*sign_extend(r170:SI) > REG_EQUAL zero_extend(r159:SI)*0xffffffffcccccccd > REG_DEAD r170:SI > REG_UNUSED mlo:SI > > 20: r168:SI=mhi:SI 0>>0x3 > REG_DEAD mhi:SI > REG_EQUAL udiv(r159:SI,0xa) > > .... > > 36: mlo:DI=zero_extend(r159:SI)*sign_extend(r181:SI) > REG_EQUAL zero_extend(r159:SI)*0xffffffffcccccccd > REG_DEAD r181:SI > REG_UNUSED mlo:SI > > 38: r179:SI=mhi:SI 0>>0x3 > REG_DEAD mhi:SI > REG_EQUAL udiv(r159:SI,0xa) > > The "reg_avail_info" structure misses information about mhi register. The mlo > information, the first register in the register pair, the information is > correctly computed. Due to the missing mhi information, the instruction 38 > is considered an anticipated expression (due to faulty return of function > oprs_unchanged_p() ). This leads to removal of instruction 38 ( gcse via insn > 20) and all the dependent instructions. > > A possible solution is to check if reg_avail_info holds initialized data in > oprs_unchanged_p() function, avoiding false positive returns, like this: > > --- a/gcc/gcse.c > +++ b/gcc/gcse.c > @@ -881,6 +881,8 @@ oprs_unchanged_p (const_rtx x, const_rtx insn, int > avail_p) > { > struct reg_avail_info *info = ®_avail_info[REGNO (x)]; > > + if (info->last_bb == NULL) > + return 0; > if (info->last_bb != current_bb) > return 1; > if (avail_p) > > > Please let me know if this is an acceptable solution for my issue.
I don't think this is not the right fix for the problem. GCSE doesn't handle expressions containing hard registers, oprs_unchanged_p should never even see expressions involving hard registers. What is the expression that is recorded as anticipated in insn 38? Is it "mho:SI 0>>0x3" or "udiv(r159:SI,0xa)" from the REG_EQUAL note? Ciao! Steven