Well, any speedup that comes from delayed preprocessing is going to be
highly dependent on the structure of the #includes.
For example I just tried to get some speedup on a 5 KB compilation unit
from compiz that crashes g++ 4.5.
The problem is that this compilation unit contains a single #include
that includes everything else transitively. So of course this #include
cannot be removed by C-Reduce no matter what.
One possible way to deal with this kind of issue would be to expand out
the #includes one level at a time, but that seems ugly.
John
On 07/14/2013 10:03 AM, John Regehr wrote:
If you write a little shell script that preprocesses your program
in-place, C-Reduce can now call it after running its first complete
pass. The phase-ordering is not yet optimal, but it should help us get
a sense if this is useful.
For example:
$ cat preprocess.sh
gcc -E -I/home/regehr/z/csmith/runtime -DCSMITH_MINIMAL small.c > foo
mv foo small.c
Now invoke C-Reduce like this:
$ creduce --cpp ./preprocess.sh ./test1.sh small.c
Obviously, for this to work, you need to make sure that your test1.sh
invokes the compiler with all necessary preprocessor flags.
Another thing you might do before running C-Reduce is to make sure that
the appropriate PCH files exist -- this should speed up the part of
C-Reduce that runs before it invokes the preprocessor.
John
