<div dir="ltr">Lumping coverage with ProfileData together is not a good idea -- so IMHO this patch is the right direction to go. Coverage library provide APIs for coverageMapping data reading and writing, and its implementation is just a user of the ProfileData. ProfileData provides core profiling related APIs, and can be depended upon by others, but almost none of other libs need to depend on Coverage.  Without the split, ProfileData has to depend on Object which does not make a lot of sense.<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 1:15 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure. This feels like it's just papering over a bigger problem<br>
with the layering. Unfortunately I haven't been following some of the<br>
other profiling changes close enough to have a well formed opinion at<br>
the moment.<br>
<br>
The really annoying part about this is that AFAICT the problematic edge<br>
in the dependency graph is entirely accidental. Coverage wants to read<br>
object files but doesn't particularly care about bitcode, so the<br>
Object->Bitcode dependency is annoying. Even then, I believe Object only<br>
reads Bitcode and doesn't write, but the Bitcode->Analysis dependency is<br>
only in the BitcodeWriter...<br>
<div class="HOEnZb"><div class="h5"><br>
Easwaran Raman <<a href="mailto:eraman@google.com">eraman@google.com</a>> writes:<br>
> eraman added a comment.<br>
><br>
> Justin, does this look good?<br>
><br>
><br>
> <a href="http://reviews.llvm.org/D19333" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19333</a><br>
</div></div></blockquote></div><br></div>