Re: [google][patch] Track discriminators by instruction instead of by basic block (issue4441075)

[Cary Coutant <ccoutant@google.com>]

>>    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