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
