This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR52001] too many cse reverse equiv exprs (take2)
Alexandre Oliva <aoliva@redhat.com> writes:
> On Feb 15, 2012, Richard Sandiford <rdsandiford@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