<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jun 1, 2016, at 1:46 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, May 31, 2016 at 6:02 PM, Frédéric Riss<span> </span><span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On May 24, 2016, at 5:21 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, May 24, 2016 at 3:41 PM, Vedant Kumar<span> </span><span dir="ltr"><<a href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>> On May 23, 2016, at 8:56 PM, Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>> wrote:<br>><br>> On Mon, May 23, 2016 at 8:23 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br>> Jake and I have been integrating IRPGO on PS4, and we've identified 3 remaining work items.<br>><br>> Sean, thanks for the write up. It matches very well with what we think as well.<br><br></span>+ 1<br><span><br><br>> - Driver changes<br>><br>> We'd like to make IRPGO the default on PS4. We also think that it would be beneficial to make IRPGO the default PGO on all platforms (coverage would continue to use FE instr as it does currently, of course). In previous conversations (e.g.<span> </span><a href="http://reviews.llvm.org/D15829" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15829</a>) it has come up that Apple have requirements that would prevent them from moving to IRPGO as the default PGO, at least without a deprecation period of one or two releases.<br><br></span>Sean pointed out the problematic scenario in D15829 (in plan "C"):<br><br>```<br>All existing user workflows continue to work, except for workflows that attempt to llvm-profdata merge some old frontend profile data (e.g. they have checked-in to version control and represents some special workload) with the profile data from new binaries.<br>```<br><br>We can address this issue by (1) making sure llvm-profdata emits a helpful warning when merging an FE-based profile with an IR-based one, and (2) keeping an option to use FE instrumentation for PGO. Having (2) helps people who can't (or don't want) to switch to IR PGO.<br><span><br><br>> I'd like to get consensus on a path forward.<br>> As a point of discussion, how about we make IRPGO the default on all platforms except Apple platforms.<br><br></span>I'd really rather not introduce this inconsistency. I'm worried that it might lead to Darwin becoming a second-tier platform for PGO.<br><br>Fred (CC'd) is following up with some of our internal users to check if we can change the default behavior of -fprofile-instr-generate. He should be able to chime in on this soon.<br></blockquote></div></div></blockquote><div><br></div></span><div>Sorry it took me so long.</div></div></div></blockquote><div><br></div><div><div>Hi Fred,</div><div><br></div><div>My understanding is that you were specifically investigating whether Apple needed compatibility for merging indexed profiles. Is that compatibility needed? The only compelling argument I have heard to continue to expose FEPGO is that Apple may have a compatibility requirement for merging indexed profiles from previous compiler versions.</div></div></div></div></blockquote><div><br></div></span><div><span style="font-family:Menlo-Regular">Sorry no, my comment had nothing to do with merging profiles. I understand that this will break, and it might very well be an issue for us, but I think there is a more fundamental issue with the proposed plan. As you bring it up though, this is a user visible breakage that shouldn’t be disregarded completely.</span></div></div></div></blockquote><div><br></div><div>Merging with existing indexed profiles is the only user-visible breakage AFAIK (this was discussed at length in <a href="http://reviews.llvm.org/D15829" rel="noreferrer" style="font-size:12.8px" target="_blank">http://reviews.llvm.org/D15829</a> and the corresponding email thread). Please provide concrete examples where things would break.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>Even if this is a requirement, then I still intend to make IRPGO the default and only PGO going forward, at least on PS4. I think that doing the same for all platforms in the upstream compiler probably makes sense as well, since an internal Apple vendor compatibility requirement should not penalize all users of the open source project.</div></div></blockquote><div><br></div></span><div><span style="font-family:Menlo-Regular">Again, I’m not expressing an Apple requirement, just trying to discuss the specifics of the proposed implementation. My goal is not to hinder anything, and I want our platforms to be able to use IRPGO reliably if users see the need for it.</span></div></div></div></blockquote><div><br></div><div>What I'm saying is that besides reduced training overhead (and the inability to merge with older indexed profiles, which AFAIK is the only actual potential requirement that would need a deprecation period for FEPGO), IRPGO is basically "just a better PGO", so adding a frontend one (except as something purely during a deprecation period) is pointless. "just a better PGO" is what IRPGO is for my users. I don't want to have to have them deal with (and I don't want to support) FEPGO.</div><div><br></div><div>Anything that will cause the existing flag to continue to produce FEPGO on PS4 is not something that I'm really okay with. The reduced overhead of IRPGO is really important on PS4 (i.e. the difference between the instrumented game being playable or not). I really don't want to have to test the triple to determine the meaning of `-fprofile-instr-generate` (without `-fcoverage-mapping`).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>I’ve discussed the change in behavior quiet extensively, and I after having changed my mind a couple times, I would argue in favor of keeping the current behavior for the existing flags. I think adding a new switch for IRPGO is a better option. The argument that weighted most on my opinion is the proposed interaction with -fcoverage-mapping, and it is not at all platform specific. With the proposed new behavior, turning coverage on and off in your build system will generate a binary with different performance characteristics and this feels really wrong.</div></div></div></blockquote><div><br></div><div>Bob already mentioned in the other thread that `-fprofile-instr-generate -fcoverage-mapping` was sufficiently different from `-fprofile-instr-generate` that `-fprofile-instr-generate -fcoverage-mapping` was not an acceptable workaround that could be used for enabling FEPGO during a transitionary period, so I'm not convinced that your argument here makes sense.</div></div></div></blockquote><div><br></div></span><div><font face="Menlo-Regular">I’m not sure what you’re referring to here, and I have a hard time parsing the sentence. I suppose “was not an acceptable” should read “was an acceptable”? I would be surprised that Bob ever agreed to completely transition away from FEPGO. I didn’t even understand that getting rid of FEPGO was on table as you seem to imply bellow. </font></div></div></div></blockquote><div><br></div><div>No, it is written as intended. The backstory is in <a href="http://reviews.llvm.org/D15829" rel="noreferrer" style="font-size:12.8px" target="_blank">http://reviews.llvm.org/D15829</a> (and the corresponding email thread). The paragraph starting with "The coverage mapping adds considerable cost.".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>I also share David's opinion that this is not going to be an issue in practice. I think it makes sense for PGO and coverage to have different overheads. Coverage inherently has to trace all locations at source level, while PGO has more freedom.</div></div></div></blockquote><div><br></div></span><div><span style="font-family:Menlo-Regular">I’m sorry if I wasn’t clear, but I’m not talking about instrumentation overhead, I’m talking about the performance of the binary generated using the profiles. If we go the route of making the meaning of -fprofile-instr-generate depend on whether -fcoverage-mapping gets passed, then we change the kind of instrumentation and thus the input to the optimizations behind the user’s back. I wouldn’t be surprised that using profiles generated by FEPGO and IRPGO give you a final executable with measurably different performance characteristics.</span></div></div></div></blockquote><div><br></div><div>I think the point is that given the effort being put into IRPGO, the IRPGO version will always be a faster final executable. Why provide a "worse" PGO option?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><span style="font-family:Menlo-Regular"> If you’re tracking your performance, this can be really painful. Recently we wasted days investigating performance regressions that were due to buggy profiles. I strongly believe having an option seemingly unrelated to PGO change this behavior is wrong and can cause actual pain for our end users.</span></div></div></div></blockquote><div><br></div><div>After a deprecation period we can force `-fprofile-instr-generate` and `-fcoverage-mapping` to be mutually exclusive if necessary. Does this solve your problem?</div><div><br></div><div>Actually, I think it makes a lot of sense in some respects for `-fprofile-instr-generate` and `-fprofile-instr-generate -fcoverage-mapping` to be IRPGO and FEPGO/coverage. The difference from a user's perspective is basically "is the instrumentation inserted by the compiler constrained to have source-level coverage, or does the compiler not have this restriction". Although as I've said, I'm not a fan of supporting FEPGO in the long-term due to maintenance issues.</div><div><br></div><div>Also note that things like the context-sensitivity obtained through pre-inlining (see Rong's original RFC) is simply not obtainable within a source-level instrumentation paradigm (even if we did something like the counter fusion discussed in "[llvm-dev] RFC: Pass to prune redundant profiling instrumentation" to reduce the overhead to that of IRPGO with pre-inlining). Thus FEPGO a.k.a. "coverage-level PGO" would nonetheless be at an inherent disadvantage.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>Also, David's point about redundant work on FEPGO is a good one. We don't want to continue maintaining two different PGO’s.</div></div></blockquote><div><br></div></span><div><div style="font-family:Menlo-Regular">Are you implying that LLVM should drop FEPGO? It’s a totally sensible thing to do to use your tests as training data for your profile generation. It’s also a very valid thing to do to use your tests to do coverage. Xcode does both of these things. I would see it a a big regression to not support doing both at the same time (this would mean doubling compile+testing time for users of both).</div></div></div></div></blockquote><div><br></div><div>As David pointed out, training runs for PGO and coverage have different goals. I'm very skeptical of any testing that tries to do both at the same time, but this will continue to work (albeit without benefitting from any of the effort being put into IRPGO).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div style="font-family:Menlo-Regular">As the instrumentation needs to stay there for coverage anyway, I expect FEPGO to stay there and maintained (we care a lot about coverage). I’m not saying that all the work going into IRPGO should be duplicated in FEPGO, but what’s there and working should keep working.</div></div></div></div></blockquote><div><br></div><div>For my users the reduced overhead of IRPGO is an important feature, and making it the default is important for that reason. Since most of the effort going into PGO is focused on IRPGO, this will lead to users using FEPGO ending up as a second-tier PGO, which Vedant said he specifically wanted to avoid. The only option to avoid this is for users to not be using FEPGO.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div style="font-family:Menlo-Regular">Also, FEPGO has a lot of nice characteristics like resilience to IRGEN changes. If you have archived profiles, then when you switch compilers your performance shouldn’t degrade with FEPGO (modulo optimization bugs), while it’s much more likely to degrade with IRPGO.</div></div></div></div></blockquote><div><br></div><div>Note that this use case continues to work. I.e. we continue to apply existing frontend profiles correctly. including frontend profiles generated with -fcoverage-mapping, so that collecting coverage and PGO at the same time (although not advisable) still works. The only use case that breaks is merging existing indexed profiles, which is why we are specifically waiting for an answer on whether this is a requirement for you guys at Apple, which will determine what kind of deprecation period etc. will be needed before we can default it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div style="font-family:Menlo-Regular"> It overall looks like a much better option for people who do not need the lower instrumentation overhead.</div></div></div></div></blockquote><div><br></div><div>This is not just about lower instrumentation overhead. Things like the recently added static VP node allocation (which will e.g. make indirect callsite promotion for LTO'd kernels work) are other things are being missed out on.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>I would actually make the IRPGO mode completely incompatible with the -fcoverage-mapping flag.</div></div></div></blockquote><div><br></div><div>I'm not sure what you mean by this. Nobody is proposing anything that would make -fcoverage-mapping do anything related to IRPGO.</div></div></blockquote><div><br></div></span><div><div style="font-family:Menlo-Regular">What I mean is that -f<whatever enables IRPGO> should error out when passed at the same time as -fcoverage-mapping. </div></div></div></div></blockquote><div><br></div><div>I think you're coming into this with the mindset that FEPGO will still be a possibility (outside of a build that is used for coverage mapping). I'm not convinced that we actually need to continue exposing that except as a weird thing in conjunction with coverage (and possibly for a deprecation period if users want to merge indexed profiles).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><br></div><div>Thanks!</div><div>Fred</div></div><div><div><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>-- Sean Silva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>Fred</div><div><div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>At its core I don't think -fprofile-instr-generate *implies* FE-based instrumentation. So, I'd like to see the driver do this (on all platforms):<br><br> <span> </span>* -fprofile-instr-generate: IR instrumentation<br> <span> </span>* -fprofile-instr-generate=IR: IR instrumentation<br> <span> </span>* -fprofile-instr-generate=FE: FE instrumentation<br> <span> </span>* -fprofile-instr-generate -fcoverage-mapping: FE + coverage instrumentation<br><br>It's a bit ugly because the meaning of -fprofile-instr-generate becomes context-sensitive. But, (1) it doesn't break existing common workflows and (2) it makes it easier to ship IRPGO. The big caveat here is that we'll need to wait a bit and see if our internal users are OK with this.<br></blockquote><div><br></div><div>Is there a reason to even have the possibility for FEPGO in the long run? From what I can tell, at most we would add a <span style="font-size:12.8px">-fuse-the-old-pgo-because-i-</span><span style="font-size:12.8px">want-to-merge-with-old-</span><span style="font-size:12.8px">profiles option to hold people over until they can regenerate their profiles with the current compiler. We can add a flag to control what pre-instrumentation is done to retain the source-level robustness of FEPGO (e.g. -fpgo-no-simplify-before-instrumenting or something).</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>One alternative is to introduce a separate driver flag for IRPGO. This might not work well for Sony's existing users. I'd be interested in any feedback about this approach.<br></blockquote><div><br></div><div>Personally, I would prefer to maintaining command line compatibility for PGO in Clang (i.e. users don't have to modify their build systems).</div><div><br></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br><br>> I really don't like fragmenting things like this (e.g. if a third-party tests "clang's" PGO they will get something different depending on the platform), but I don't see another way given Apple's constraints.<br>><br>> I'd like to see IRPGO to be the default as well, but the first thing we need is a driver level option to make the switch (prof-gen) -- currently we rely on -Xclang option to switch between two modes, which is less than ideal.<br>><br>> If the concern from Apple is that the old profile still need to work, then this is problem already solved. The reason is that -fprofile-instr-use can automatically detect the type of the profile and switch the mode.<br><br></span>It's not just that. As Sean pointed out, we're concerned about old profiles inter-operating poorly with new ones.<br><br>thanks,<br>vedant<br><br><br>> - Pre-instrumentation passes<br>><br>> Pre-instrumentation optimization has been critical for reducing the overhead of PGO for the PS4 games we tested (as expected). However, in our measurements (and we are glad to provide more info) the main benefit was inlining (also as expected). A simple pass of inlining at threshold 100 appeared to give all the benefits. Even inlining at threshold 0 gave almost all the benefits. For example, the passes initially proposed in<span> </span><a href="http://reviews.llvm.org/D15828did" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15828did</a><span> </span>not improve over just inlining with threshold 100.<br><div><div>><br>> (due to PR27299 we also need to add simplifycfg after inlining to clean up, but this doesn't affect the instrumentation overhead in our measurements)<br>><br>> Bottom line: for our use cases, inlining does all the work, but we're not opposed to having more passes, which might be beneficial for non-game workloads (which is most code).<br>><br>><br>><br>> Yes, Rong is re-collecting performance data before submitting the patch.<br>><br>> - Warnings<br>><br>> We identified 3 classes of issues which manifest as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO):<br>><br>> 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings).<br>><br>> This can be enhanced with an user option to override the behavior. Can you help filing a tracking bug?<br>><br>><br>> 2. In different TU's, pre-instr inlining might make different inlining decisions (for example, different functions may be available for inlining), causing hash mismatch errors (instrprof_error::hash_mismatch). In building a large game, we only saw 8 instance of this, so it is not as severe as 1, but would be good to fix.<br>><br>><br>> Rong has a patch addressing that -- will submit after cleanup pass change is done.<br>><br>><br>> 3. A .cpp file may be compiled and put into an archive, but then not selected by the linker and will therefore not result in a counter in the profraw. When compiling this file with pgo-use, instrprof_error::unknown_function will result and a warning will be emitted.<br>><br>> yes -- this is a common problem to other compilers as well.<br>><br>><br>><br>> Case 1 can be fixed using a function hash or other unique identifier instead of a file path. David, in D20195 you mentioned that Rong was working on a patch that would fix 2; we are looking forward to that.<br>><br>><br>> Right.<br>><br>> For 3, I unfortunately do not know of any solution. I don't think there is a way for us to make this warning reliable in the face of this circumstance. So my conclusion is that instrprof_error::unknown_function at least must be defaulted to off unfortunately.<br>><br>> yes, this can be annoying. If the warnings can be buffered, then the compiler can check if this is due to missing profile for the whole file and can reduce the warnings into one single warning (source file has no profile data).  Making it off by default sounds fine to me too if it is too noisy.<br>><br>> thanks,<br>><br>> David<br>><br>><br>> -- Sean Silva</div></div></blockquote></div></div></blockquote></div></div></div></div></blockquote></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>