Alexandre Oliva <aol...@redhat.com> writes: > On Feb 15, 2012, Richard Sandiford <rdsandif...@googlemail.com> wrote: > >> I'm fine with putting it in and seeing what breaks. But I'd really >> prefer if we knew in theory. :-) > > Ok, I dove into the problem without a testcase, and I managed to trigger > it on other platforms after tweaking get_addr a bit so as use loc lists > form canonical values, and to avoid returning other VALUEs if other > alternatives exist. > >> Like I say, my understanding before this patch series went in was that >> cselib values weren't supposed to be cyclic. Now that they are, what >> should consumers like memrefs_conflict_p do to avoid getting stuck? > > I'm now testing the following heuristic: only use an expr instead of a > value if the expr doesn't reference any value whose uid is greater than > that of the value. This worked for libgcc so far; regstrapping now. > > Here's the revised patch that addresses Jakub's and your comments, that > regstrapped on x86_64-linux-gnu and i686-linux-gnu, followed by the > patch I'm testing now on both platforms.
Thanks for tackling this. I agree it looks like the patch should work. I have to admit I still don't like these changes, and it still isn't obvious to me when canonical_cselib_val is supposed to be used. I'd much rather we kept to the original dag. But I realise that probably isn't a useful attitude to take, and I don't know vartracking well enough to understand the constraints, so I'll shut up now. Richard