aboutsummaryrefslogtreecommitdiff
path: root/libcpp/lex.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@redhat.com>2011-10-17 09:59:12 +0000
committerDodji Seketeli <dodji@gcc.gnu.org>2011-10-17 11:59:12 +0200
commit92582b753e34fd574b6a5672b2f82979c966187a (patch)
tree372dab78d59e4e58eead8df4f751726cec9b98b4 /libcpp/lex.c
parent46427374e1ffdcb2781d99abc63ebd3ab7af6110 (diff)
downloadgcc-92582b753e34fd574b6a5672b2f82979c966187a.zip
gcc-92582b753e34fd574b6a5672b2f82979c966187a.tar.gz
gcc-92582b753e34fd574b6a5672b2f82979c966187a.tar.bz2
Generate virtual locations for tokens
This second instalment uses the infrastructure of the previous patch to allocate a macro map for each macro expansion and assign a virtual location to each token resulting from the expansion. To date when cpp_get_token comes across a token that happens to be a macro, the macro expander kicks in, expands the macro, pushes the resulting tokens onto a "token context" and returns a dummy padding token. The next call to cpp_get_token goes look into the token context for the next token [which is going to result from the previous macro expansion] and returns it. If the token is a macro, the macro expander kicks in and you know the story. This patch piggy-backs on that macro expansion process, so to speak. First it modifies the macro expander to make it create a macro map for each macro expansion. It then allocates a virtual location for each resulting token. Virtual locations of tokens resulting from macro expansions are then stored on a special kind of context called an "expanded tokens context". In other words, in an expanded tokens context, there are tokens resulting from macro expansion and their associated virtual locations. cpp_get_token_with_location is modified to return the virtual location of tokens resulting from macro expansion. Note that once all tokens from an expanded token context have been consumed and the context and is freed, the memory used to store the virtual locations of the tokens held in that context is freed as well. This helps reducing the overall peak memory consumption. The client code that was getting macro expansion point location from cpp_get_token_with_location now gets virtual location from it. Those virtual locations can in turn be resolved into the different interesting physical locations thanks to the linemap API exposed by the previous patch. Expensive progress. Possibly. So this whole virtual location allocation business is switched off by default. So by default no extended token is created. No extended token context is created either. One has to use -ftrack-macro-expansion to switch this on. This complicates the code but I believe it can be useful as some of our friends found out at http://llvm.org/bugs/show_bug.cgi?id=5610 The patch tries to reduce the memory consumption by freeing some token context memory that was being reused before. I didn't notice any compilation slow down due to this immediate freeing on my GNU/Linux system. As no client code tries to resolve virtual locations to anything but what was being done before, no new test case has been added. Co-Authored-By: Dodji Seketeli <dodji@redhat.com> From-SVN: r180082
Diffstat (limited to 'libcpp/lex.c')
-rw-r--r--libcpp/lex.c41
1 files changed, 34 insertions, 7 deletions
diff --git a/libcpp/lex.c b/libcpp/lex.c
index 75b2b1d..cd6ae9f 100644
--- a/libcpp/lex.c
+++ b/libcpp/lex.c
@@ -1703,6 +1703,38 @@ next_tokenrun (tokenrun *run)
return run->next;
}
+/* Return the number of not yet processed token in the the current
+ context. */
+int
+_cpp_remaining_tokens_num_in_context (cpp_reader *pfile)
+{
+ cpp_context *context = pfile->context;
+ if (context->tokens_kind == TOKENS_KIND_DIRECT)
+ return ((LAST (context).token - FIRST (context).token)
+ / sizeof (cpp_token));
+ else if (context->tokens_kind == TOKENS_KIND_INDIRECT
+ || context->tokens_kind == TOKENS_KIND_EXTENDED)
+ return ((LAST (context).ptoken - FIRST (context).ptoken)
+ / sizeof (cpp_token *));
+ else
+ abort ();
+}
+
+/* Returns the token present at index INDEX in the current context.
+ If INDEX is zero, the next token to be processed is returned. */
+static const cpp_token*
+_cpp_token_from_context_at (cpp_reader *pfile, int index)
+{
+ cpp_context *context = pfile->context;
+ if (context->tokens_kind == TOKENS_KIND_DIRECT)
+ return &(FIRST (context).token[index]);
+ else if (context->tokens_kind == TOKENS_KIND_INDIRECT
+ || context->tokens_kind == TOKENS_KIND_EXTENDED)
+ return FIRST (context).ptoken[index];
+ else
+ abort ();
+}
+
/* Look ahead in the input stream. */
const cpp_token *
cpp_peek_token (cpp_reader *pfile, int index)
@@ -1714,15 +1746,10 @@ cpp_peek_token (cpp_reader *pfile, int index)
/* First, scan through any pending cpp_context objects. */
while (context->prev)
{
- ptrdiff_t sz = (context->direct_p
- ? LAST (context).token - FIRST (context).token
- : LAST (context).ptoken - FIRST (context).ptoken);
+ ptrdiff_t sz = _cpp_remaining_tokens_num_in_context (pfile);
if (index < (int) sz)
- return (context->direct_p
- ? FIRST (context).token + index
- : *(FIRST (context).ptoken + index));
-
+ return _cpp_token_from_context_at (pfile, index);
index -= (int) sz;
context = context->prev;
}