Ada, treelang needs to be converted to --enable-mapped-location

[Per Bothner]

Geert Bosch wrote:

> Excuse me for my ignorance, but this seems a very convoluted way to
> gather some simple information.

You're right.

> Probably I am missing some higher
> level description of what information the back end needs, and why.

The issue is not *gathering* the information, but *representing* it
(encoding it) compactly.

Using a 32-bit source_location is more efficient than a 64/128-bit
(filename, line[, column]) pair/triple.  (It also keeps track of
"include" nesting, though we don't make full use of that.)

Currently, the "middle end" adds to each expression a "locus", which
is a pointer to a ggc-allocated (filename, line)-pair, using this
indirection to improve sharing.  Using the line_table is a cleaner more
centralized more efficient way to do the sharing.

> Currently, parsing is fast. Why should we be calling an extra function for
> every line parsed?

Huh?  Except for comments and white space (which you can ignore for
linemap_line_start) you're going to do *many* function calls for every
line parsed by the time gcc is done with it ...

Anyway, do function calls really matter on modern cpus?  Cache misses
are what counts ...

? Basically, the Ada model is to first build an entire
> Ada parse tree of the Ada source and expand/lower it to a level where
> Ada constructs like generic instantiations and tasks have disappeared.
> That tree gets then lowered to GENERIC. Currently we have about a
> dozen places in Gigi (the GNAT to GCC tree translator) where we call
> a routine Sloc_to_locus, which converts an Ada source location
> into a location_t. I would assume that there would be a way that
> we can change this routine to hand the back end the new information,
> including column number.

That may be possible.  However, the line-map data structure is not
optimized for handing out source_location integers in random order,
so if successive calls to Sloc_to_locus jump around too much you'll
get an excessive number of line_map entries.  In practice, it may be
ok to jump around as long as you don't need to allocate a new line_map
entry: same filename, column number no bigger than the max_column_hint,
and the line number not less than or too much bigger than given by the
most recent (explicit or implicit) linemap_add.  And if not, the code
will allocate a new line_map entry, which is no big deal.  The point
is if you're allocating line_map entries too frequently, you're losing
the space-saving benefit of the line_table data structure, and just
getting extra overhead.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/