This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rtl]: Do not generate insns with mismatched REG_EQUAL mode for multiword MULT RTXes.
On Thu, Aug 5, 2010 at 12:00 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>>>> (insn 56 55 57 920501-6.c:17 (set (reg:DI 108)
>>>> ? ? ? ?(reg:DI 108)) -1 (expr_list:REG_EQUAL (mult:DI (reg/v:DI 87 [ acc ])
>>>> ? ? ? ? ? ?(const_int 2 [0x2]))
>>>> ? ? ? ?(nil)))
>>>>
>>>> This fixes ICE on my private (unreleased) target. I didn't find the
>>>> testcase that would trigger on FSF targets, but the solutions should
>>>> be obvious from the above analysis.
>>>
>>> What happens with the REG_EQUAL note on the dummy move when the move
>>> is deleted? I wouldn't be surprised if this REG_EQUAL note is lost
>>> after the first DCE pass (which is probably a fast_dce run), because
>>> the dummy move looks like a noop_move_p move and these are removed
>>> unconditionally.
>>
>> Hm, I don't know, but force_opreand in <case alg_add_factor> creates
>> the same dummy move at the end (so REG_NOTE attaches without problems
>> there):
>
> I'm not saying attaching the REG_NOTE causes problems, but I am quite
> sure that note also gets lost when the dummy move is removed.
>
> It looks like the first pass that may remove noop_move_p insns is the
> first rtl_dce pass. Is your REG_NOTE still there if you look at the
> .dce1 rtl dump?
Ugh, you are right. REG_EQUAL notes on noop moves are removed just
after vreg pass (I'm testing this on gcc-4.5), so it looks to me that
the whole business with REG_EQUAL notes in expmed.c/expand_mult_const
() is flawed...
Perhaps we should generate a new insn that would survive optimization passes?
Uros.