[PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass

Jeff Law law@redhat.com
Tue Sep 2 03:28:00 GMT 2014


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.

jeff



More information about the Gcc-patches mailing list