This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, Richard Earnshaw <rearnsha at arm dot com>, Bin Cheng <bin dot cheng at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 2 Sep 2014 13:17:56 +0800
- Subject: Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass
- Authentication-results: sourceware.org; auth=none
- References: <000a01cfc1de$cac1c230$60454690$ at arm dot com> <53FDB440 dot 5030904 at arm dot com> <CAHFci28BS75pySKVtLTeY8BQsYupJHvXs73ZdYq1RkfHLbXocQ at mail dot gmail dot com> <5401680D dot 60907 at redhat dot com> <20140831121844 dot GA8949 at gate dot crashing dot org> <5404A1C7 dot 4060304 at redhat dot com> <20140901191555 dot GB6643 at gate dot crashing dot org> <54053949 dot 5090800 at redhat dot com>
On Tue, Sep 2, 2014 at 11:28 AM, Jeff Law <law@redhat.com> wrote:
> On 09/01/14 13:15, Segher Boessenkool wrote:
>>
>> On Mon, Sep 01, 2014 at 10:41:43AM -0600, Jeff Law wrote:
>>>
>>> On 08/31/14 06:18, Segher Boessenkool wrote:
>>>>
>>>> On Fri, Aug 29, 2014 at 11:58:37PM -0600, Jeff Law wrote:
>>>>>
>>>>> One could argue that this mess is a result of trying to optimize a reg
>>>>> that is set more than once. Though I guess that might be a bit of a
>>>>> big hammer.
>>>>
>>>>
>>>> It works fine in other cases, and is quite beneficial for e.g.
>>>> optimising
>>>> instruction sequences that set a fixed carry register twice.
>>>
>>> How common is that?
>>
>>
>> I meant once setting the reg, and then using and clobbering it in another
>> insn. This is quite common -- on some targets the add-with-carry insns
>> are used for scc things too. You could say all cases where combine can
>> do something with this should have been optimised earlier, but that is
>> not the case today.
>>
>>> While we don't have any formal SSA-like properties in RTL, we're
>>> certainly better off if we can avoid unnecessary cases where a single
>>> pseudo is set more than once
>>
>>
>> Note that in this case we're talking about a hard register, not a pseudo.
>
> I was referring to r84 in Bin's message, not the condition code register.
> Unless I missed something it's set at the start of the sequence to the value
> 0, then later to -ltu(flags,cc,0).
>
> There's no good reason I can see why we're reusing a pseudo like that. I
> suspect that if we go back, fix whatever's creating that lame sequence and
> simply reject combinations involving a pseudo set more than once it won't
> affect code in any real way. If we wanted to be anal about it, we'd put in
> some kind of debugging note and someone could do some wider scale testing.
For this specific case, I think the reuse of r84 comes from coalescing
during expanding, and this is necessary to remove redundant reg-moves.
Then we need to fix this in coming passes?
Thanks,
bin
>
> jeff
>