Displaying 3 results from an estimated 3 matches for "numcount".
Did you mean:
num_count
2013 May 23
2
[PATCH 1/2] gcov: Add script to split coverage informations.
...for little endian machines
+ return getRaw(8);
+}
+
+sub align()
+{
+ my $l = $pos & 7;
+ getRaw(8-$l) if $l;
+}
+
+# read a string prefixed by length
+sub getS()
+{
+ my $l = get32();
+ my $res = getRaw($l);
+ align();
+ return $res;
+}
+
+sub parseFunctions($)
+{
+ my $numCounters = shift;
+ my $num = get32();
+
+ my @funcs;
+ for my $n (1..$num) {
+ my @data;
+ my $ident = get32();
+ my $checksum = get32();
+ for my $n (1..$numCounters) {
+ push @data, get32(); # number of counters for a type
+ }
+ push @funcs...
2014 Feb 21
12
[LLVMdev] asan coverage
...=========================================
--- lib/CodeGen/CodeGenPGO.cpp (revision 201843)
+++ lib/CodeGen/CodeGenPGO.cpp (working copy)
@@ -199,7 +199,8 @@
llvm::Type *Args[] = {
Int8PtrTy, // const char *MangledName
Int32Ty, // uint32_t NumCounters
- Int64PtrTy // uint64_t *Counters
+ Int64PtrTy, // uint64_t *Counters
+ Int64PtrTy // uint64_t *PCs
};
llvm::FunctionType *FTy =
llvm::FunctionType::get(PGOBuilder.getVoidTy(), Args, false);
@@ -209,9 +210,10...
2014 Feb 19
2
[LLVMdev] asan coverage
I've built chromium with " -fprofile-instr-generate -fsanitize=address" --
the performance looks good!
The file format from r198638 is indeed rudimentary.
Do you already know how the real output format will look like?
Just to summarize what I think is important:
- minimal size on disk, minimal amount of files
- minimal i/o while writing to disk, no lockf or some such
-