On Tue, Sep 2, 2014 at 9:40 PM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > On Tue, Sep 02, 2014 at 02:10:32PM +0200, Ulrich Weigand wrote: >> In any case, this test in can_combine_p rejects a combination for *two* >> different issues. One is the earlyclobber problem, which is what that >> 2004 thread was about, and which my patch back then relaxed for fixed >> hard register. >> >> However, this doesn't seem to apply to the example above; that is really >> about the second problem: don't substitute into a clobber. > > Right. > >> I understand the reason why this particular substitution is rejected is >> simply that if it weren't, we'd be substituting flags:CC=cmp(r84:SI,0x1) >> into clobber flags:CC, resulting in clobber cmp(r84:SI,0x1), which is >> invalid RTL. > > I checked, and that is indeed what combine does. How silly. > >> Now I guess this check could be relaxed if somewhere else in combine we'd >> recognize the substitution into a clobber and simply omit it in that case. > > Yeah. > > In the testcase, combine tries combining 76,77 (77 is that clobbering > insn) and refuses it; then it tries 32,76,77 and refuses it; and then > it tries 32,76,77,43 and allows it (it doesn't do this check at all, > 77 is not i3, combine omits the clobber completely). Which is inconsistent.
I guess it makes sense because this way it doesn't introduce any invalid instructions. But yes, how combine handles the clobber in this way may help combine the three instructions? Thanks, bin > > What a mess. Thanks for looking! > > > Segher
