This is the mail archive of the gcc-patches@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: [4.5] [RFC] Move line-map.* to its own library (libloc)


>>>>> "Manuel" == Manuel LÃpez-IbÃÃez <lopezibanez@gmail.com> writes:

Manuel> Line-maps is just the (current) internal working of libloc, we may
Manuel> decide change it in the future. A better interface would define the
Manuel> location-related functions that we need and not simply the functions
Manuel> that line-map provides.

The API could certainly use some love.  It is a bit ugly.

I'm more interested in whether a different encoding could gain us a
user-visible advantage.  I don't think we'd have to change the API to
do this.

Tom> One oddity here is that BUILTINS_LOCATION is not actually
Tom> enforced, or even known about, by line-map.

Manuel> That is a really good point. Also, the location corresponding to 1
Manuel> (COMMAND_LINE_LOCATION?) is not defined there, I will have to look it
Manuel> up or define it. Anyway, COMMANDLINE_LOCATION and BUILTINS_LOCATION
Manuel> could be defined by libloc when a new line-map is built.

Yeah, but not in isolation from the rest of gcc.  If you dig into the
code, each front end has to ensure that the line table is set up
properly so that BUILTINS_LOCATION is correct.  This is bonkers, of
course.  But, I think it is important to fix gcc and line-map before
(or at the same time as) moving the BUILTINS_LOCATION define
elsewhere.  Otherwise we're just making the modularity problem worse
-- at least right now, BUILTINS_LOCATION, although weird, is
consistently just an implementation detail of gcc.

Manuel> In that sense, BUILTINS_LOCATION could be defined in libloc. The point
Manuel> is that this library is meant to be used by GCC and nothing else, so
Manuel> if BUILTINS_LOCATION is (or could be) used by anything that requires
Manuel> libloc, then it doesn't belong in toplev.h or input.h.

Moving BUILTINS_LOCATION, but keeping the current line-map
initialization approach, would, IMO, make modularity worse.  

FWIW, I did rearrange this stuff on the incremental branch a bit.  I
think it is insufficient, though.

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00345.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00346.html

Tom> Why is expand_location a #define now?

Manuel> The old expand_location assumes a global line_table available.

Oh, right.  Thanks.

Manuel> expand_location should take an explicit line_table and all calls
Manuel> should be updated.

I'm all in favor of this kind of thing.  One thing to consider,
though, is where this extra argument is stored, if not in a global.
One attraction of line-maps is that it saves space (compared to the
old, expanded location type); adding a pointer to every location_t
would negate this advantage.

Manuel> BTW, is the incremental compiler using a global line_table also?

Yeah.  This was one (but only one) reason I gave up on multi-threading
gcc.

Still, the incremental compiler has to do something very ugly with
locations, because it is long-running and because it performs many
compilations, not just one:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01786.html

Tom


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