This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: cse_process_notes_1 issue ?
- From: Aurelien Buhrig <aurelien dot buhrig dot gcc at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 22 Oct 2012 14:05:03 +0200
- Subject: Re: cse_process_notes_1 issue ?
- References: <50800EBF.1070706@gmail.com> <71090460.Pp6SukKGkc@polaris>
>> In the following RTL, the hardware (reg:HI r2), whose natural mode is
>> HImode, is set to 0, but when analysing the REG_EQUAL notes of the MULT
>> insn during CSE pass, the (reg:SI r2) is computed to be equivalent to 0,
>> which is wrong (the target is big endian).
>>
>> (insn 51 9 52 3 (set (reg:HI 2 r2)
>> (const_int 0 [0])) gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
>> (expr_list:REG_DEAD (reg:HI 31)
>> (expr_list:REG_EQUAL (const_int 0 [0])
>> (nil))))
>>
>> (insn 52 51 12 3 (set (reg:HI 3 r3 [orig:2+2 ] [2])
>> (reg/v:HI 20 [ number_of_digits_to_use ]))
>> gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
>> (expr_list:REG_DEAD (reg/v:HI 20 [ number_of_digits_to_use ])
>> (nil)))
>>
>> (insn 12 52 13 3 (set (reg:SI 0 r0)
>> (const_int 3321928 [0x32b048]))
>> gcc.c-torture/execute/pr27364.c:5 19 {movsi}
>> (nil))
>>
>> (insn 13 12 16 3 (parallel [
>> (set (reg:SI 0 r0)
>> (mult:SI (reg:SI 2 r2)
>> (reg:SI 0 r0)))
>> (clobber (reg:SI 2 r2))
>> ]) gcc.c-torture/execute/pr27364.c:5 54 {*mulsi3_call}
>> (expr_list:REG_EQUAL (mult:SI (reg:SI 2 r2)
>> (const_int 3321928 [0x32b048]))
>> (expr_list:REG_DEAD (reg:HI 3 r3)
>> (expr_list:REG_UNUSED (reg:SI 2 r2)
>> (nil)))))
>>
>>
>> I think a mode size check is missing when processing REG code in
>> cse_process_notes_1. Adding such a check prevents the CSE pass from
>> elimintating the MULT instruction.
>
> It looks like such a check is indeed missing in cse_process_notes_1 (and
> probably equiv_constant as well). There is one in insert_regs with a comment
> explaining the issue with hard registers.
>
OK. I will file a bug and propose a patch ASAP.
>> But then this MULT insn is simplified during the combine pass:
>>
>> Trying 12 -> 13:
>> ...
>> Successfully matched this instruction:
>> (set (reg:SI 0 r0)
>> (const_int 0 [0]))
>> deferring deletion of insn with uid = 12.
>> deferring deletion of insn with uid = 52.
>> modifying insn i3 13 r0:SI=0
>> deferring rescan insn with uid = 13.
>>
>>
>> So double middle-end bug or do I miss something?
>
> Probably a similar issue. I guess the code expects to have subregs of pseudos
> here and isn't prepared for (arithmetic) operations on double-word hard regs.
>
I will try to track this one down too.
Thank you for your reply.
Aurélien