[PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass
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
More information about the Gcc-patches