Details
Diff Detail
Event Timeline
tools/llvm-profdata/instr-remap.test is failing in the reverse iteration bot. See http://lab.llvm.org:8011/builders/reverse-iteration/builds/10546/steps/check_all/logs/stdio.
This is because FunctionData is iterated in InstrProfWriter to output function counts, etc. But for two functions with the same name the iteration order is not defined if we use a DenseMap. Changing this to MapVector resolves this.
Note: We can also sort FunctionData before iteration to fix this issue. But that would mean we would need to sort every time we iterate in order to print. Using a MapVector instead is a better option IMO.
I think this could roughly double the memory utilization of the writer, which might be problematic because the number of records to write can be high. (@dblaikie did some work on reducing memory usage in this area, he might have hard data about this.)
As the write should only occur once, maybe the better tradeoff would be to sort?
Yeah, unless I'm missing something (quite possibly) this seems like the sort of place where "do a bunch of processing, then sort, then iterate" is a valid strategy.
@mgrang - does it look like any use case is emitting more than once & modifying in between? I would find that pretty surprising. I think it's just "build build build, stop building, emit" and adding a sort-before-emit would be OK there.
I think this patch is right in also sorting the function names: AFAICS StringMap doesn't provide that guarantee.
lib/ProfileData/InstrProfWriter.cpp | ||
---|---|---|
393–403 | Please run clang-format, the lambda should only be indented by two additional spaces. Also can you put the explicit types for nameA et al.? That should be StringRef and uint64_t for the hashes. |
lib/ProfileData/InstrProfWriter.cpp | ||
---|---|---|
390–398 | I guess you could write this as: return std::tie(A.first, A.second.first) < std::tie(B.first, B.second.first); perhaps? |
lib/ProfileData/InstrProfWriter.cpp | ||
---|---|---|
399–400 | Inconsistent variable naming? (some start with upper case, some with lower case) Currently I think the LLVM style says upper case is required. Naming the types here might be reasonable for readability, but I'm not sure. |
I guess you could write this as:
perhaps?