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

[Geert Bosch]

On Sep 29, 2004, at 22:09, Per Bothner 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.)

There seems to be a severe abstraction inversion here. It's none
of the back end's business how the front end parses source files.
For all it cares, the front end might parse files back-to-front.
Also, the whole notion of "include" nesting is front end related.
Ada, for example, has no notion of includes, but uses a module
system. How this is represented in source files is a choice of
the front end implementation, and the back end has nothing to
do with it.

> 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.

It seems to me that the "locus" should be an opaque 32-bit type,
with accessor functions to retrieve file, line and column information.
Front ends implement these accessor functions, and the back end
doesn't care how the information is stored.

The C front ends, and maybe others, can use the new mapped location
approach using the interface you described to create a new locus.
Front ends for which this approach is not a good fit, can implement
the much simpler accessor functions for loci.

>> 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 ...

For Ada, processing a single compilation unit might require parsing 
hundreds
of files. This is much more common than with other languages, since Ada 
allows
cross-unit inlining, which requires not only parsing all 
specifications, but
also bodies of units with potentially inlined subprograms.

Apart from this, it is bad practice to litter the parser with calls into
the back end to produce duplicate line number information. It's really
wrong for the back end to be so intermingled with the front end.
The way forward for GCC is to decouple the front ends more from the
back ends. Going to tree-ssa with GENERIC and GIMPLE are good steps
forward, but this location business seems a clear step back.

> 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.

I think the ideal approach is to view the locus as private to the front 
ends.
Then we just use the Ada "Sloc" as locus and provide the necessary
functions to map this locus to file, line, column information.

   -Geert