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