This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]