This is the mail archive of the gcc@gcc.gnu.org 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


Richard Kenner wrote:

    My suggestion that one option is to create thr Source_Ptr ->
    source_location mapping (i.e. data structures to make the mapping
    reasonably efficient) be done more-or-less at the same time as the
    source file is read into a Source_Buffer and Source_Ptr mapping is
    updated.

The problem is that that code is not dependent on the back-end being GCC.

As Zack and have I've patiently tried to explain: line-map.[ch] is not part of or dependent on GCC or its back-end.

So it's the wrong place to put callbacks into routines that are in the
GCC hierarchy.

Thus it is not a call-back. Using line-map.[ch] is like using say a regular expression package. It's a utility package that happens to be written in C and reside in libcpp; neither of which should prevent it from being used from Ada code.

The right place for any such code is in ada/trans.c:Sloc_to_locus.  Indeed
I believe that might be the *only* routine that needs to be modified.

Can you take a close look at that function and suggest needed changes to it?

No. As I've explained, I don't think that is the right way to go about it. If you think it is the right way, then you should be able to do it.

    Yes, but that doesn't preclude using the line_map structure, even with
    non- GCC back-ends.  There is no reason why the Ada front-end can't use
    line_map for a program that say just does analysis and never touches a
    tree or an rtx.

Yes, there is because the Ada front end is also used with back-ends other
than GCC.

Sigh. I don't know how to explain again why that is irrelevant.


Geert Bosch wrote:

> As I understand, Fortran also has a private line map already and may
> not require the overhead of maintaining a duplicate data structure.

Yet it was fairly straightforward to modify the Fortran front-end to
use the *standard* line-map.[ch] data structure.  Java was more
complicated, mainly because I used the opportunity to streamline the
lexer.  Why is it such a problem for Ada?

> As I see it, the interface between front end and back end now
> only consists of the few simple accessor functions/macros,
> instead of the much, much more complicated line-map.h interface.
> If you look at all dependencies between front end and back end
> as a graph, the goal is to be able to partition this graph with
> cutting as few edges as possible.

Exactly.  If the Ada front-end uses line-map.[ch] it is a simple
case of the front-end calling a utility library, albeit one written
in C rather than Ada.  There are no call-backs.  On the other hand
if we make source_location depend on the front-end, then then back-end
will need call-backs into the front-end to so the latter can "take
apart" a source_location for the former.

Your own concern favors Zack's and my position.

> During the entire parsing and analysis
> of the Ada sources, we never call into any of the C part of GCC.
> The only code executed is the Ada code in the gcc/ada subdirectory.

I assume you end up calling C libraries for I/O.

> This is ideal from a maintenance point of view, since the separation
> between front end and back end matters is localized in just a few
> files comprising Gigi.

Error reporting is another example of a facility where the front-end
*should* be calling into shared code, for consistency of error handling
between front-end and back-end errors.  I'm guessing Ada uses its own
routines for diagnostics (as to some extent does Java); this may
need to change at some point.  At which point Ada using its own line
number representation may be a disadvantage.

Your approach is to keep the Ada front-end as self-contained and "pure
Ada" as possible.  That may be in conflict with what to us are more
important goals:  consistency between languages in things like option
handling, and diagnostic handling.  These things are important to
higher-level tools, such as IDEs.

> As GCC will implement more languages over time, such a separation is
> even more necessary. Just think of a GCC with 20 different front ends.
> If every change to a data structure, such as the line map, would
> require changes throughout these front ends, maintenance would be
> a nightmare.

Well, the line map data structure is fairly opaque.  There are basically
5 functions and 1 macro.  (A few more functions and macros are only
used by cpp.)

> How the front end generates its trees should be of no concern.
> My objection against using the line-map.[ch] "library" is that
> its "specification" makes so many assumptions on how its callers
> are structured, that it ends up specifying how to implement
> a front end instead of just providing a way of to build a mapping
> from locus to file, line and column.

Well, the main asseumption is that somebody reads a source file in
forwards order to lex/parse it; while doing so that somebody once
in a while makes a request to "this is the current file/line/column -
give me a cookie so I can remember that."

The library has been designed for the case that cookie requests
are done in forwards order.  This is obviously straight-forward to
do if cookie requests are done using lexing.  Giving that lexing
has to be done in forwards order, this is not much of a constraint.

Note that Source_Ptr cookies are managed not too differently, except
they are "allocated" when a file is read into a Source_Buffer rather
then when it is lexed.  No big difference.  The advantage of the
Source_Ptr approach is a little less overhead dusing lexing; the
disadvantage is that you must keep the text of all the source files
in memory to decode the Source_Ptr, plus doing so appears to require
more work.  On balance, I think the source_location approach is
preferable.

I mentioned that it may be possible to assign allocate cookies
differently, before lexing, or after lexing.  You do have those
options, though I don't recommend them.

> I see three solutions, listing in order of preference:
>   -  Allow front ends to specify the mapping from "Locus" to
>      file/line/col. The locus is just an abstract type encoded
>      in a 32-bit value, and front ends provide hoods to get
>      file/line/column information. This would fit well with
>      Ada and Fortran front ends, and completely eliminates
>      the need for any extra overhead of the line-map data
>      structure.

Fortran is fine with source_location.

I'd have more sympathy with your suggestion if either:
(a) there was something special about Ada or its front-end
needing special hook, or
(b) the Source_Ptr encoding is more efficient or flexible (at
least for Ada) than the one in line-map.[ch].
Neither appears to be the case.

>   -  Make the line-map interface a bit more flexible, so that
>      mappings can be created in arbitrary order without large
>      performance penalties.

We'd need a concrete design.  It would have to not measurably hurt
performance for other front-ends.

>   -  Add an extra pass to Gigi, which sorts all loci by original
>      source order and then uses the somewhat clumsy interface of
>      line-map to generate the required data.

My recommended solution:

- Reimplement the Source_Ptr type to be the same as line-map.[ch]'s
source_location.  Have Ada's lexical scanner get source_location
cookies from line-map.[ch].  Whenever it currently remembers a
Source_Ptr, it would instead remember a source_location.

This should not be a lot of work.  It is changing the implementation
of an opaque data type to use an existing library.  This does *not*
prevent or even complicate use of non-GCC backends, except that they
need to link in with libcpp.

If you think I'm mistaken about the difficulty of this, I'll willing
to do the work for a modest fixed fee, with no cost to GNAT if I fail.
(Not that I'm hungry for this business - I have more intersting work
I'm behind on.  I'm just tired of arguing about this, and would
prefer to avoid what I think are inferior over-complicated solutions.)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


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