[PATCH] D63232: [Coverage] Load code coverage data from archives

Vedant Kumar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 13 10:30:27 PDT 2019


vsk added inline comments.


================
Comment at: llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp:595
+  Reader->ProfileNames = std::move(ProfileNames);
+  if (BytesInAddress == 4 && Endian == support::endianness::little) {
+    if (Error E =
----------------
Dor1s wrote:
> nit: I guess it's stupid, but maybe `sizeof(uint32_t)` isntead of `4`? And the same in the following conditions.
If it were possible to write 'sizeof(intptr32_t)', I think that would be clearer. I'm not sure 'sizeof(uint32_t)' is clearer than '4', though.


================
Comment at: llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp:597
+    if (Error E =
+            readCoverageMappingData<uint32_t, support::endianness::little>(
+                Reader->ProfileNames, Coverage, Reader->MappingRecords,
----------------
Dor1s wrote:
> I think we can make it a bit more concise (2 branches instead of 4) by passing `Endian` as a template parameter. May need a separate check though to make sure it's either `support::endianness::little` or `support::endianness::big`.
As 'Endian' is not a constant-expression, I don't think it's possible to pass it in as a template parameter. I think it could be passed as a regular parameter, but that would eliminate two branches here while adding two branches to 'readCoverageMappingData'.


================
Comment at: llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp:742
+      return ReaderOrErr.takeError();
+    Readers.emplace_back(std::move(ReaderOrErr.get()));
+    return Readers;
----------------
Dor1s wrote:
> Why do we use `emplace_back` here and on line 794, but `push_back` in the other places?
Fixed.


================
Comment at: llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp:757
+      if (Arch != ObjArch)
+        continue;
+
----------------
Dor1s wrote:
> Should we log anything here?
I don't think so. It's expected that at least one of the slices in a universal binary will not match the desired architecture. I'll add a comment to that effect.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63232/new/

https://reviews.llvm.org/D63232





More information about the llvm-commits mailing list