<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 27, 2017 at 11:39 AM Dehao Chen via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">danielcdh added a comment.<br class="gmail_msg">
<br class="gmail_msg">
In <a href="https://reviews.llvm.org/D29203#659019" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D29203#659019</a>, @mehdi_amini wrote:<br class="gmail_msg">
<br class="gmail_msg">
> In <a href="https://reviews.llvm.org/D29203#658997" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D29203#658997</a>, @danielcdh wrote:<br class="gmail_msg">
><br class="gmail_msg">
> > - What is the motivating example that you want to compile some sources with -fdebug-info-for-profiling and some without<br class="gmail_msg">
> >   - If the debug info size is a concern for -gmlt binary, then one would want to only enable this flag for sources that is performance-critical<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> This is an argument *against* a module flag.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Right ;-) I think I need to raise the point before close the patch.<br class="gmail_msg">
<br class="gmail_msg">
But my opinion is that this use cases (if any) would be rare because:<br class="gmail_msg">
<br class="gmail_msg">
- 17% seem small, but people may have other opinions<br class="gmail_msg">
- adding per-CU flag is manual and tedious<br class="gmail_msg"></blockquote><div><br></div><div>Not sure what you mean - manual in what scenario/way?<br><br>Oh, sorry, you mean that it would be tedious for users to actually specify -f(no-)debug-info-for-profiling in a per-file way, rather than a whole-project way, so the issue of how to resolve these is likely not a real problem because no one's really going to bother doing this?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- per-CU flag may need to change as new source coming in/old source change that updates the hot CU distribution<br class="gmail_msg"></blockquote><div><br></div><div>Not following here either... ah, now I see (& wrote the description above) that if a user did this they would have to be careful about changing load on their code - surprising parts might become hot and they might have to change the flags.<br><br>I believe, at least at Google, some projects already live with this where they explicitly opt out certain objects from their profile because it's too expensive. (this is for non-sample based profiling, which is much more expensive in file size, optimization, etc - so not an apples-to-apples comparison, just to say that there are costs that can cause people to be motivated to deal with that much hassle, etc)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That being said, I would think it's better to force this flag in LTO when mixed flag situation happens. But will let upstream decide if this would be a feature or a bug.<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Dehao<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D29203" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D29203</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>