On Tue, Sep 2, 2014 at 11:28 AM, Jeff Law <l...@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 >