This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Speed up var-tracking on various KDE sources (PR debug/41371)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Richard Guenther <rguenther at suse dot de>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Jan 2010 14:40:45 +0100
- Subject: Re: [PATCH] Speed up var-tracking on various KDE sources (PR debug/41371)
- References: <20100113102630.GF16723@hs20-bc2-1.build.redhat.com> <orljfu2uwx.fsf@livre.localdomain>
On Tue, Jan 19, 2010 at 12:31 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jan 13, 2010, Jakub Jelinek <jakub@redhat.com> wrote:
>
>> Ok for trunk?
>
>> 2010-01-13 ?Jakub Jelinek ?<jakub@redhat.com>
>
>> ? ? ? PR debug/41371
>> ? ? ? * var-tracking.c (values_to_unmark): New variable.
>> ? ? ? (find_loc_in_1pdv): Clear VALUE_RECURSED_INTO of values in
>> ? ? ? values_to_unmark vector. ?Moved body to...
>> ? ? ? (find_loc_in_1pdv_1): ... this. ?Don't clear VALUE_RECURSED_INTO,
>> ? ? ? instead queue it into values_to_unmark vector.
>> ? ? ? (vt_find_locations): Free values_to_unmark vector.
>
> I know you've already checked this in, but this much simpler patch
> should have a similar effect, without requiring an additional vector.
> The effect should be similar because we'd then be looking for values in
> a star-canonicalized table, and the star shape is designed precisely to
> avoid the kind of repetitive walks that you observed. ?It was a mistake
> to merge tables the way we did; we should have always done it the other
> way round.
>
> Thoughts? ?Should this go in? ?Should the other patch be backed out?
Ok if it bootstraps & tests ok. The other patch should be backed
out if that doesn't show regressions on the KDE testcases.
Thanks,
Richard.