search for: __profd_foo

...data needs to do in this > regard AFAICT. > In fact, it's so equivalent that you could in principle read the actual counter values directly out of a core file. A core file could literally be used as a raw profile. E.g. you could in principle open the core in the debugger and then do: p __profd_foo p __profd_bar ... (and walking vprof nodes would be more complicated but doable) I'm not necessarily advocating this literally be done; just showing that "everything you need is there". Note also that the debug info approach has another nice advantage in that it allows minimizing t...

...CT. >> > > In fact, it's so equivalent that you could in principle read the actual > counter values directly out of a core file. A core file could literally be > used as a raw profile. > > E.g. you could in principle open the core in the debugger and then do: > > p __profd_foo > p __profd_bar > ... > > (and walking vprof nodes would be more complicated but doable) > > I'm not necessarily advocating this literally be done; just showing that > "everything you need is there". > A core file can be significantly larger than a raw profile...

Problem ------- Instrumentation for PGO and frontend-based coverage places a large amount of data in object files, even though the majority of this data is not needed at run-time. All the data is needlessly duplicated while generating archives, and again while linking. PGO name data is written out into raw profiles by instrumented programs, slowing down the training and code coverage workflows.

On Fri, Jun 30, 2017 at 5:54 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Problem > ------- > > Instrumentation for PGO and frontend-based coverage places a large amount > of > data in object files, even though the majority of this data is not needed > at > run-time. All the data is needlessly duplicated while generating archives, > and > again while