<br><br><div class="gmail_quote">On Fri Oct 24 2014 at 4:06:05 PM Xinliang David Li <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Diego,<br><br>I think sampleFDO needs to be designed in a way which can protect itself from future breakage like this. The roots in the unnecessary dependency of sample FDO on gmlt setting. It is totally reasonable to tune debug binary size by changes like this.</blockquote><div><br></div><div>Sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The right way is to fix this is to introduce an internal -g<...> flag for use by sampleFDO -- it will have a fixed definition of what needs to be emitted.</div></blockquote><div><br></div><div>Not so sure. Semantically, -gmlt is exactly what samplefdo needs. Relying on the subprogram tag for the function itself was an implementation detail.</div><div><br></div><div>Adding yet another debug mode that's very much like -gmlt but not quite is going to be confusing for users.</div><div><br></div><div>I *believe* we can reproduce the same behaviour by using the source location ranges. I'm still not quite sure how, but I've got Eric and David within smacking distance, so I'll make myself a nuisance until they give me enough hints.</div><div><br></div><div><br></div><div>Diego.</div></div>