This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Status of rich location work (was Re: [PATCH 06/10] Track expression ranges in C frontend)
- From: Dodji Seketeli <dodji at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org, Richard Biener <richard dot guenther at gmail dot com>
- Date: Fri, 06 Nov 2015 08:12:48 +0100
- Subject: Re: Status of rich location work (was Re: [PATCH 06/10] Track expression ranges in C frontend)
- Authentication-results: sourceware.org; auth=none
- References: <1442957171-22904-1-git-send-email-dmalcolm at redhat dot com> <1445632918-29617-1-git-send-email-dmalcolm at redhat dot com> <1445632918-29617-7-git-send-email-dmalcolm at redhat dot com> <56330AEF dot 7080202 at redhat dot com> <1446491668 dot 2994 dot 84 dot camel at surprise>
> Talking about risks: the reduction of the space for ordinary maps by a
> factor of 32, by taking up 5 bits for the packed range information
> optimization (patch 10):
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02539.html
> CCing Dodji: Dodji; is this reasonable?
FWIW, I am definitely to get this (patch 10/10 of the series) if other
agrees. I just have some minor questions to ask about that patch and
I replied to the patch to ask.
As for the "reduction of the space for ordinary maps by a factor of 32,
by taking up 5 bits for the packed range information" that you mention,
I think it's a trade off I'd live with.
Ultimately, if it shows that we really move out of space with this, we
should probably explore the impact of just moving to a 64 bits size for
source_location.
Until then, a possible mitigation strategy could be to add an option to
disable the range tracking altogether (even at the preprocessor's lexer
level), to provide an escape path to users running low on resources. A
bit what we do with -ftrack-macro-expansion=0.
Cheers,
--
Dodji