>> Rework discriminator assignment so that it attaches the discriminator >> to the source location of each instruction instead of to the basic >> block itself. > > Any idea on how this affects memory consumption?
Richard had the same question when I first proposed this patch. This was my answer then: "Not a lot. We assign discriminators for only a small fraction of the total number of locations in the program, so the number of unique location_t values doesn't increase significantly. I didn't add anything to the line_map structure, nor did I do anything at all in libcpp, so it's not bloating the source_location/location_t data structures at all. The extra space needed is linear with the number of discriminators assigned, which is roughly one per for loop or switch statement, plus an occasional discriminator for conditional expressions or macro expansions with control flow. (In the old code that I'm replacing, the extra space was one int per basic block.)" >> It's not ready for trunk yet because it does not yet preserve >> the discriminators across LTO, so I'd like to put it in >> google/main until I have a chance to get that part working. > > But, IIRC this does not introduce LTO regressions, right? Right. Even though discriminators don't survive the streaming-out/streaming-in process, the samples obtained from an initial non-LTO compilation will include discriminator information, and that information survives long enough into a profile-use compilation with LTO for the frequency information to get recorded correctly. -cary
