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 = &reg_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

Reply via email to