http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
--- Comment #34 from Dodji Seketeli <dodji at gcc dot gnu.org> 2010-11-25
23:38:09 UTC ---
I have worked on decreasing the memory consumption of this patchset and I could
decrease it quite a bit, even though there is still room for improvement. On a
testcase of mine, I started with a patchset for which the
-ftrack-macro-expansion option was consuming 6 times more memory for
preprocessing than the initial preprocessor. Now the patchset consumes 1.6
times more memory with -ftrack-macro-expansion than the initial (non-patched)
preprocessor. On a full compilation of the test I have,
-ftrack-macro-expansion increases memory consumption of ~ 13%. In my quest to
further decrease memory consumption I made -ftrack-macro-expansion take
parameters 0, 1, or 2. * 0 means -ftrack-macro-expansion is de-activated. * 1
means the macro location tracking feature runs in a "degraded" mode that
saves even more memory by making all argument tokens of a function-like
macro have the same location; e.g: #define IDENT(X) X
IDENT(1+2) would then be expanded to tokens 1+2, tokens '1', '2' and '3' all
have the same location, just like if their locations were folded into the
location of the '1'. This can save a lot of memory. * 2 means the full feature
where all locations of all tokens are tracked. A part from that the patchset
bootstraps and passes regression tests of C and C++ FEs without
-ftrack-macro-expansion. So now I am back to working on the user facing
aspects of the patch again. Belows is a quick status of what the patch does.
It's slightly different from the status I gave earlier. [do...@adjoa gcc]$ cat
-n test.c 1 #define OPERATE(OPRD1, OPRT, OPRD2) \ 2 OPRD1
OPRT OPRD2; 3 4 #define SHIFTL(A,B) \ 5 OPERATE
(A,<<,B) 6 7 #define MULT2(A) \ 8 SHIFTL (A,1)
9 10 void 11 g () 12 { 13 MULT2 (1.0);/* 1.0
<< 1;*/ 14 } So let's see what an un-patched compiler tells us:
[do...@adjoa gcc]$ ./cc1 -quiet test.c test.c: In function ‘g’: test.c:13:3:
error: invalid operands to binary << (have ‘double’ and ‘int’) Note how the
location given is the locus of the expansion point of the macro. There is no
information about where the '<<' token mentionned in the message comes from. In
other words, the spelling location of the '<<' is lost. Now let's see what a
patched compiler tells us: [do...@adjoa gcc]$ ./cc1 -ftrack-macro-expansion=2
-quiet test.c While expanding macro OPERATE at test.c:2:9 While expanding macro
SHIFTL at test.c:5:14 While expanding macro MULT2 at test.c:13:13 test.c: In
function 'g': test.c:5:14: error: invalid operands to binary << (have 'double'
and 'int') The location mentionned in the error message (test.c:5:14) is now
the spelling location of the token '<<' mentionned in the error message. The
context of the error message (the lines starting with "While expanding macro")
unwinds the stack of nested macro expansions that led to "instantiating" the
token mentionned in the error message. The topmost element of the stack of
macro expansion is the macro that most directly contains the token mentionned
in the error message. The lowest element of the stack is the macro first macro
that actually got expanded and in turn led to the nested macro expansion stack
we have. Note how the location mentioned for this lowest stack element is the
location of the /expansion point/ of the macro, whereas locations mentioned for
the higher elements are the instantiation locations of the relevant tokens. In
other words, the location of the point where SHIFT is expanded inside MULT2 is
not interesting. So we don't mention it. But the location of the point where
MULT2 is expanded inside the function g is interesting. So it is mentioned.
Hopefuly this can be a starting point for further discussion. The patchset can
be browsed from: http://seketeli.net/git/~dodji/gcc.git/log/?h=PR7263-dodji
You can grab the code by doing: git clone git://seketeli.net/~dodji/gcc.git
gcc.git cd gcc.git git checkout -b PR7263-dodji
