[1/2] libcpp: Avoid unnecessary ad-hoc uses for large source files

When debugging PR c++/68819 I noticed an inefficiency during
the handling of locations > LINE_MAP_MAX_LOCATION_WITH_COLS.
When combining ranges for locations with
  start == caret == finish (with a NULL data ptr)
get_combined_adhoc_loc was always building an ad-hoc entry
rather than simply returning the location.

Normally can_be_stored_compactly_p returns true for such triples,
but it returns false for locations above
LINE_MAP_MAX_LOCATION_WITH_COLS (as the range-packing code isn't
designed to handle the latter).  There's a followup test within
get_combined_adhoc_loc for detecting the start == caret == finish
case, but I'd conditionalized it on the location being one of the
two reserved locations:
   locus < RESERVED_LOCATION_COUNT

That condition has been there since I introduced range-packing
(as part ofr230331).  I believe at the time I didn't realize there
was any other way for such a location triple to fail
can_be_stored_compactly_p.

These location triples occur a lot where we're in this mode:
every token, and every expression that fits on one line,
so this is wasteful.

Removing the locus < RESERVED_LOCATION_COUNT part of the
condition allows us to avoid using the ad-hoc table for these
cases.

Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu
in combination with the following patch.

libcpp/ChangeLog:
	* line-map.c (get_combined_adhoc_loc): Remove condition
	on locus < RESERVED_LOCATION_COUNT when considering
	whether a caret == start == finish location can be
	simply stored as the caret location.
---
 libcpp/line-map.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

On 12/18/2015 01:21 PM, David Malcolm wrote:
> When debugging PR c++/68819 I noticed an inefficiency during
> the handling of locations > LINE_MAP_MAX_LOCATION_WITH_COLS.
> When combining ranges for locations with
>    start == caret == finish (with a NULL data ptr)
> get_combined_adhoc_loc was always building an ad-hoc entry
> rather than simply returning the location.
>
> Normally can_be_stored_compactly_p returns true for such triples,
> but it returns false for locations above
> LINE_MAP_MAX_LOCATION_WITH_COLS (as the range-packing code isn't
> designed to handle the latter).  There's a followup test within
> get_combined_adhoc_loc for detecting the start == caret == finish
> case, but I'd conditionalized it on the location being one of the
> two reserved locations:
>     locus < RESERVED_LOCATION_COUNT
>
> That condition has been there since I introduced range-packing
> (as part ofr230331).  I believe at the time I didn't realize there
> was any other way for such a location triple to fail
> can_be_stored_compactly_p.
>
> These location triples occur a lot where we're in this mode:
> every token, and every expression that fits on one line,
> so this is wasteful.
>
> Removing the locus < RESERVED_LOCATION_COUNT part of the
> condition allows us to avoid using the ad-hoc table for these
> cases.
>
> Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu
> in combination with the following patch.
>
> libcpp/ChangeLog:
> 	* line-map.c (get_combined_adhoc_loc): Remove condition
> 	on locus < RESERVED_LOCATION_COUNT when considering
> 	whether a caret == start == finish location can be
> 	simply stored as the caret location.
OK.
jeff