> Varint is worth it, it saves a lot of space (table below). This is the > default way LLVM streams out its profiles (via the uleb128 type). Compact > mode was added mostly to have the ability to see how much smaller the > most-compressed version of the profile practically could be (modulo > external compression algorithms). It could certainly be the default mode, > we have not measured the streaming overhead as such.
Okay, but does it have significant overhead? If the answer is no I would drop the non compacted variant. If it's not default users may not use it very much. > The basic goals behind the design were to try and have the smallest-possible > format which can be directly consumed by the compiler while being low > overhead to stream in. Using the integrated compression library makes > a lot of sense, we can explore doing that as well. Well don't need to overdesign without a clear need yet. > > IIRC one issue that made files bigger with the old autofdo is that it > > saved zero counts, but perhaps that is already fixed. > > > > Zero counts are still streamed out, however v4 has a location type that > encodes it in the type itself (LOCATION_ZERO), which saves a huge amount > of space already. Can't they just be dropped in a new incompatible revision? > > > Also why do we bother with endian conversion? It seems like unnecessary > > complexity. > > > > It makes the profiles portable across machines and architectures. I am > not sure how relevant it is in practice, but it seemed like a good thing I doubt it has any practical relevancy at this point. > to have. I think it would be good regardless to have the profile be in > fixed-endian format, so maybe it makes more sense to have it be LE by > default. Yes. > > > > > Maybe I missed it, but it would be good to have a separate spec > > for the file format. > > A spec was sent out as an RFC earlier: > https://gcc.gnu.org/pipermail/gcc/2026-April/247992.html. I meant can it be a file in the source tree for future reference (including the latest modifications) Thanks, -Andi
