This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]