This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Ada, treelang needs to be converted to --enable-mapped-location
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