davidxl added a comment. For the longer term, one possible solution is to make FE based instrumentation only used for coverage testing which can be turned on with -fcoverage-mapping option (currently, -fcoverage-mapping can not be used alone and must be used together with -fprofile-instr-generate). To summarize:
A. Current behavior: -------------------- 1. -fprofile-instr-generate turns on FE based instrumentation 2. -fprofile-instr-generate -fcoverage-mapping turns on FE based instrumentation and coverage mapping data generation. 3. -fprofile-instr-use=<..> assumes profile data from FE instrumentation. B. Proposed new behavior: ------------------------- 1. -fprofile-instr-generate turns on IR late instrumentation 2. -fcoverage-mapping turns on FE instrumentation and coverage-mapping 3. -fprofile-instr-generate -fcoverage-mapping result in compiler warning 4. -fprofile-instr-use=<> will automatically determine how to use the profile data. B.2) above can be done today for improved usability. B.1) needs a transition period before the IR based instrumentation becomes stablized (and can be flipped to the default). During the transition period, the behavior of 1) does not change, but a cc1 option can be used to turn on IR instrumentation (as proposed by Sean). In the real longer term, I think IR based instrumentation can also be used for coverage testing too (by disabling some pre-optimizations and pre-inlining needed for PGO purpose) -- but this is a different topic to be discussed. thanks, David http://reviews.llvm.org/D15829 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
