Manuel López-Ibáñez wrote: > 2008/8/25 Paolo Bonzini <[EMAIL PROTECTED]>: >>>> Even if you do not use line-map.o, the middle-end does, so you still >>>> have the duplication. >>> Right, this is the only part that is indeed shared and for which Ada >>> requires >>> libcpp. >> There are exactly 6 uses of linemap functions in libcpp. They could be >> replaced with a handful of function pointers, moving line-map.c to gcc. > > You have to count all uses of: > > SOURCE_LINE, SOURCE_COLUMN, MAIN_FILE_P, LAST_SOURCE_LINE, > LAST_SOURCE_LINE_LOCATION, and LINEMAP_POSITION_FOR_COLUMN > > which are all macros.
Yes, but libcpp could still provide the *interface* of line-map.h (the macros), and leave the actual implementation of the data structure to the client. > Also, line-map functions seem to be in the > critical path, so the extra dereferencing may be noticeable. That's true. Unless we lexed everything up front, in which case one could hope that the indirect branches would be predicted well. In fact, I'm curious about how good/bad the branch predictor works for GCC. My wild guess: awfully. > Sure about that? line-map.h seems pretty important to handle the include > stack. As far as I could see, all the dependency stuff is in mkdeps.c; maybe it could use the line-map infrastructure more. Of course, in that case moving line-map.c out of libcpp would mean moving mkdeps.c too -- and not in gcc/, but rather in its own library so that makedepend can use it... at which point you wonder if it was really a good idea... Paolo
