Question about : lprofValueProfNodes

Hi

This array is defined in compiler-rt: InstrProfilingValue.c but I can’t find where it is used?

And the comment on it does not say much about why we need it either.

Can someone explain why we need this and where it is used?

/* A shared static pool in addition to the vnodes statically

  • allocated by the compiler. */

COMPILER_RT_VISIBILITY ValueProfNode

lprofValueProfNodes[INSTR_PROF_VNODE_POOL_SIZE] COMPILER_RT_SECTION(COMPILER_RT_SEG INSTR_PROF_VNODES_SECT_NAME_STR);

Thanks

A

Hi,

Hi
This array is defined in compiler-rt: InstrProfilingValue.c but I can’t find where it is used?

It's used in allocateOneNode(). Incrementing the current vnode pointer gives a fresh node (possibly backed by the shared pool).

And the comment on it does not say much about why we need it either.

It's used to avoid calling malloc(), which David (CC'd) found to be a performance improvement.

best,
vedant

Hi,

Hi
This array is defined in compiler-rt: InstrProfilingValue.c but I can’t
find where it is used?

It's used in allocateOneNode(). Incrementing the current vnode pointer
gives a fresh node (possibly backed by the shared pool).

And the comment on it does not say much about why we need it either.

It's used to avoid calling malloc(), which David (CC'd) found to be a
performance improvement.

Right -- it is used to avoid depending on dynamic memory allocation. Other
than performance, if heap memory is used, the program may deadlock if
malloc library (such as tcmalloc) is instrumented.

To turn off the behavior, use the following option

-mllvm -vp-static-alloc=false with the instrumentation build.

David

Thank you

So it does not seem to be relevant for what I’m trying to do.

I’m doing something unconventional.

The objective is to implement PGO and code coverage on a system that does not exit and does not have any file io, or any of stdc libraries that libclang-profile is using. (more like a kernel)

So what I’m trying to do is instead of calling __llvm_profile_write_file () from the application, read the sections __llvm_prf_data, __llvm_prf_names, __llvm_prf_cnts and __llvm_prf_vnds after the critical tasks are done and transfer them to outside of the system.

Then dump these sections in a char * array in a c file and attribute them to be in the associated section. Then compile that file with –u__llvm_profile_runtime to create an executable that calls __llvm_profile_write_file to dump my profraw data.

Sofar, I’m able to do the mechanics but seems like something is going wrong because because fprofile-instr-use does not find profile data for the source files.

Any suggestion?

Thanks

A

Thank you
So it does not seem to be relevant for what I’m trying to do.
I’m doing something unconventional.
The objective is to implement PGO and code coverage on a system that does not exit and does not have any file io, or any of stdc libraries that libclang-profile is using. (more like a kernel)
So what I’m trying to do is instead of calling __llvm_profile_write_file () from the application, read the sections __llvm_prf_data, __llvm_prf_names, __llvm_prf_cnts and __llvm_prf_vnds after the critical tasks are done and transfer them to outside of the system.

You may already have worked this out, but for completeness I'll mention that this is typically done by:
1. Allocating a buffer big enough to contain all the data (see __llvm_profile_get_size_for_buffer_internal),
2. Filling out the buffer (see __llvm_profile_write_buffer_internal), and
3. Transferring the buffer to some host machine.

Then dump these sections in a char * array in a c file and attribute them to be in the associated section.

I'm not sure I follow -- why is a C file needed?

Once you have the buffer from step 3 on the host machine, you've got a well-formed raw profile. You should be able to fwrite() it to e.g 'default.profraw' and test that it's a valid profile with llvm-profdata.

Then compile that file with –u__llvm_profile_runtime to create an executable that calls __llvm_profile_write_file to dump my profraw data.

Sofar, I’m able to do the mechanics but seems like something is going wrong because because fprofile-instr-use does not find profile data for the source files.

What error are you getting exactly? Have you confirmed that your profile is valid?

vedant

What Vedant said – the profiler runtime provides buffer API for profile dumping. Note that value profiling dumping is not yet supported for buffer API, but since you are using Front-end based instrumentation/profile-use, value profiler is not turned on by default anyway.

David

For __llvm_profile_get_size_for_buffer_internal and __llvm_profile_write_buffer_internal to work in our system, we have to modify the compiler-rt to use our kernel’s memory allocation. To avoid that, I was hoping to be able to do all the processing offline by copying only the sections to that offline process.

We currently have a workaround, but please let me know if you think just copying the __llvm_prf_xxx sections and doing the processing offline is not possible with the current API of compiler-rt profiling.

Thanks

A

For __llvm_profile_get_size_for_buffer_internal and
__llvm_profile_write_buffer_internal to work in our system, we have to
modify the compiler-rt to use our kernel’s memory allocation. To avoid
that, I was hoping to be able to do all the processing offline by copying
only the sections to that offline process.

We currently have a workaround, but please let me know if you think just
copying the __llvm_prf_xxx sections and doing the processing offline is not
possible with the current API of compiler-rt profiling.

It should work if the raw profile header is initialized properly with sizes
of data, counter, and name sections as well as counter base address.

David