[PATCH] D19333: Move coverage related code into a separate library

[Xinliang David Li via llvm-commits]

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.

David

On Thu, Apr 21, 2016 at 1:15 PM, Justin Bogner <mail at justinbogner.com>
wrote:

> I'm not sure. This feels like it's just papering over a bigger problem
> with the layering. Unfortunately I haven't been following some of the
> other profiling changes close enough to have a well formed opinion at
> the moment.
>
> The really annoying part about this is that AFAICT the problematic edge
> in the dependency graph is entirely accidental. Coverage wants to read
> object files but doesn't particularly care about bitcode, so the
> Object->Bitcode dependency is annoying. Even then, I believe Object only
> reads Bitcode and doesn't write, but the Bitcode->Analysis dependency is
> only in the BitcodeWriter...
>
> Easwaran Raman <eraman at google.com> writes:
> > eraman added a comment.
> >
> > Justin, does this look good?
> >
> >
> > http://reviews.llvm.org/D19333
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160421/4f12be27/attachment.html>