[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [creduce-dev] unifdef



Yaron, thanks!

I wonder if you could tell me a bit more about why you reduce non-preprocessed Boost code? Is it common for compiler bugs to go away after preprocessing?

I'm just curious about this.

Another thing about #includes: I've noticed that reduced non-preprocessed code often ends up containing chains of trivial includes. We can do three things about this:

- ignore it, since it's no big deal

- add a pass that replaces and #include directive with the included file

- add a pass that only replaces an #include when the included file is below some size threshold

John


On 10/31/15 11:04 AM, Yaron Keren wrote:
Hi John,

This sounds great!
For nonprocessed code it's sometimes also useful to try and remove
includes, see attached pass.
While pass_lines would eventually get rid of them, experience reducing
boost examples suggests it's much more efficient to go for the includes
as first pass, usually most of them are not required, typically repeats
for five-ten levels of nested includes. Maybe this should be merged into
unidef or added as its own pass.

Yaron


2015-10-31 11:05 GMT+02:00 John Regehr <regehr@cs.utah.edu
<mailto:regehr@cs.utah.edu>>:

    I just merged the new pass that does partial resolution of ifdefs.

    For the 196 transitive include files that come from a C++ hello
    world on OS X (not making this up) the unifdef pass by itself gives
    a 57% reduction (in 352 seconds) if we choose -D first and -U second
    for each CPP symbol.  Reduction is only 45% for -U first (in 518
    seconds).  I have no idea if this generalizes but I'm going with -D
    first for now.

    Also I'm putting the unifdef and comment removal passes right up at
    the front of the phase ordering on the idea that they work well for
    non-preprocessed code and terminate very quickly if there aren't any
    ifdefs / comments to remove.  We can revisit this if my idea isn't
    right.

    John