This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: atomic update of profile counters (issue7000044)
- From: Rong Xu <xur at google dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Xinliang David Li <davidxl at google dot com>, Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, reply at codereview dot appspotmail dot com
- Date: Wed, 20 Nov 2013 10:44:06 -0800
- Subject: Re: atomic update of profile counters (issue7000044)
- Authentication-results: sourceware.org; auth=none
- References: <20121221064539 dot 0E1A7100704 at rong dot mtv dot corp dot google dot com> <20121221092532 dot GA7055 at kam dot mff dot cuni dot cz> <CAF1bQ=R7pXzBq08E7PiXKwahpM8Lx0gergnXvGtr6wk+M8-nKA at mail dot gmail dot com> <CAF1bQ=Qs8uSHmPp01vwYm-vU4XD+wYrB4cEAcAib8i7LDAS3og at mail dot gmail dot com> <CAAkRFZKPOUdHdF2XZDYkncj8=Z_yg2OosmxN6hyZ=877sqoVxg at mail dot gmail dot com> <CAF1bQ=QE0UPcWzG8U150E8cMK4WrcXwiNBgdeDgZPhV5KUx9wA at mail dot gmail dot com> <CA+=Sn1kK-Ld-K7YBAy1rVTrkBaXhduRH6zE4LA379QTgiY-1wA at mail dot gmail dot com> <CAFiYyc33X_tX6csqC880dVYm=AM51PQ3uZX4Bx+7wi0V1UP6Bg at mail dot gmail dot com> <CAF1bQ=R-5ipC+8+MAqsOpyMJ9DQ2X6fw-S3Z0sMKnQ6B9Zz3XQ at mail dot gmail dot com> <50EB31B7 dot 9090307 at redhat dot com> <CAF1bQ=Svz7rJFrWG6-mBHMFbPef9B_Ls=2bCsahZzHK48+JjBg at mail dot gmail dot com> <CAF1bQ=SunHvCyYjN7k-qcqi7C65kRxp=9RE56EsjzAvJRZYe9w at mail dot gmail dot com> <CA+=Sn1kRScfyveEB4KFd60c+fz+t81xJQ8bA4_o=UrWfs6cLFg at mail dot gmail dot com>
On Tue, Nov 19, 2013 at 5:11 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Nov 19, 2013 at 5:02 PM, Rong Xu <xur@google.com> wrote:
>> Hi all,
>>
>> I merged this old patch with current trunk. I also make the following changes
>> (1) not using weak references. Now every *profile_atomic() has it's
>> own .o so that none of them will be in the final binary if
>> -fprofile-generate-atomic is not specified.
>> (2) more value profilers have the atomic version.
>> (3) not link to libatomic. I used to link the libatomic in the
>> presence of -fprofile-generate-atomic, per Andrew's suggestion. It
>> used to work. But now if I can add -latomic in the SPEC, it cannot
>> find the libatomic.so.1 (unless I specify the PATH). I did not find an
>> easy way to statically link libatomic.a. Andrew: Do you have any
>> suggestion? Or should we let the user link to libatomic.a if the
>> builtins are not expanded?
>
> It should work for an installed GCC. For testing you might need
> something that is included inside testsuite/lib/atomic-dg.exp which
> sets the library path to include libatomic build directory.
When I change the SPEC to include libatomic,
the compiler can find libatomic. I.e. using
>> gcc -O2 -fprofile-generate -fprofile-generate-atomic=3 hello_world.c
generates a.out without any problem.
But since there are both shared and static libatomic in lib64, it
chooses to use the dynamic one.
>> ldd a.out
linux-vdso.so.1 => (0x00007fff56bff000)
libatomic.so.1 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00002b0720261000)
/lib64/ld-linux-x86-64.so.2 (0x00002b072003c000)
>> ./a.out
./a.out: error while loading shared libraries: libatomic.so.1: cannot
open shared object file: No such file or directory
while
>> LD_LIBRARY_PATH=<gcc_install_patch>/lib64 ./a.out
works fine.
I think that's the same reason we set the library path in
testsuite/lib/atomic-dg.exp, because <gcc_install_patch>/lib64
is not in the dynamic library search list.
I could do this in the SPEC
-Wl,-Bstatic -latomic -Wl,-Bdynamic
which would link libatomic statically.
I works for me. But it looks a little weird in gcc driver.
Index: gcc.c
===================================================================
--- gcc.c (revision 205053)
+++ gcc.c (working copy)
@@ -771,7 +771,8 @@
%{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
%(mflib) " STACK_SPLIT_SPEC "\
- %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " SANITIZER_SPEC " \
+ %{fprofile-arcs|fprofile-generate*|coverage:-lgcov\
+ %{fprofile-generate-atomic=*:-Wl,-Bstatic -latomic
-Wl,-Bdynamic}} " SANITIZER_SPEC " \
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
%{!nostdlib:%{!nostartfiles:%E}} %{T*} }}}}}}"
#endif
> I think now we require libatomic in more cases (C11 atomic support for
> an example).
>
> Thanks,
> Andrew Pinski
>
>>
>> Is this OK for trunk?
>>
>> Thanks,
>>
>> -Rong
>>
>> On Mon, Jan 7, 2013 at 12:55 PM, Rong Xu <xur@google.com> wrote:
>>> Function __gcov_indirect_call_profiler_atomic (which contains call to
>>> the atomic function) is always emitted in libgcov.
>>> Since we only link libatomic when -fprofile-gen-atomic is specified,
>>> we have to make the atomic function weak -- otherwise, there is a
>>> unsat for regular FDO gen build (of course, when the builtin is not
>>> expanded).
>>>
>>> An alternative it to always link libatomic together with libgcov. Then
>>> we don't need the weak stuff. I'm not sure when one is better.
>>>
>>> -Rong
>>>
>>> On Mon, Jan 7, 2013 at 12:36 PM, Richard Henderson <rth@redhat.com> wrote:
>>>> On 01/03/2013 04:42 PM, Rong Xu wrote:
>>>>> It links libatomic when -fprofile-gen-atomic is specified for FDO
>>>>> instrumentation build. Here I assume libatomic is always installed.
>>>>> Andrew: do you think if this is reasonable?
>>>>>
>>>>> It also disables the functionality if target does not support weak
>>>>> (ie. TARGET_SUPPORTS_WEAK == 0).
>>>>
>>>> Since you're linking libatomic, you don't need weak references.
>>>>
>>>> I think its ok to assume libatomic is installed, given that the
>>>> user has had to explicitly use the command-line option.
>>>>
>>>>
>>>> r~