[cfe-dev] macro-expanded/preprocessed string (clangLex) question

[Thompson, John]

Sean,

Why a map instead of just a vector?

Why do you think it should be set up to do stuff in parallel with threads?  I've run the existing version over a fairly large group of headers and it just took a few seconds.

-John

From: Sean Silva [mailto:silvas at purdue.edu]
Sent: Monday, June 24, 2013 2:42 PM
To: Thompson, John
Cc: Argyrios Kyrtzidis; cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] macro-expanded/preprocessed string (clangLex) question



On Fri, Jun 21, 2013 at 1:28 PM, Thompson, John <John_Thompson at playstation.sony.com<mailto:John_Thompson at playstation.sony.com>> wrote:
Argyrios,

Yeah, your comment made me think that perhaps I should just track macro expansions in general, not limiting it to conditional directives, as macro instances anywhere with different values could be problematic as well for modules.  Is that what you meant as well?

What do you think, Sean?

The program structure doesn't change a whole lot.  Instead of storing the condition location and values, I store the macro information.


I think the program structure will have to change a good amount anyway in order to make it clear what the algorithm is doing. Unless it is unable to express the check that is desired (but I think it can), I strongly believe that the pseudocode I suggested is the right approach, which nicely models the problem as:

1) Defining an equivalence relation on macro expansions or preprocessor conditions or whatever (call this type T)
2) Maintaining a map keyed on the physical source file location of the T and having T as values, and using that to ensure that all physical source locations expand to the same thing across TU's.

This approach should work for either of the scenarios. Moreover, it has obvious time and space complexity and it's easy to see how to parallelize it (operate on independent maps in independent threads and at the end perform a "union" operation on the maps).

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130625/43d4c979/attachment.html>