[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [creduce-dev] unifdef
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
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
On 10/31/15 11:04 AM, Yaron Keren wrote:
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.
2015-10-31 11:05 GMT+02:00 John Regehr <email@example.com
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