This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Detect whether target can use -fprofile-update=atomic


On Tue, Sep 6, 2016 at 6:45 AM, Martin Liška <mliska@suse.cz> wrote:

>>> Proper fix contains of 2 parts:
>>> a) compiler emission must verify that -fprofile-update=atomic is doable for a given target; it's done
>>> via a new function can_generate_atomic_builtin
>>> b) libgcc must detect whether __atomic_fetch_add_x can be expanded on the target; that requires configure
>>> support and if the target is not capable to expand these, we must conditionally remove all gcov_.*profiler_atomic
>>> functions from libgcov.a.
>>
>> I'm fine with the coverage-pecific changes, but the new hooks etc are not something I can approve.
>>
>> gcc/ChangeLog:
>>
>> 2016-08-12  Martin Liska  <mliska@suse.cz>
>>
>>     * optabs.c (can_generate_atomic_builtin): New function.
>>     * optabs.h (can_generate_atomic_builtin): Declare the function.
>> Need GWM or similar review
>>
>>     * tree-profile.c (tree_profiling):  Detect whether target can use
>>     -fprofile-update=atomic.
>> ok
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-08-12  Martin Liska  <mliska@suse.cz>
>>
>>     * gcc.dg/profile-update-warning.c: New test.
>> ok
>>
>> libgcc/ChangeLog:
>>
>> 2016-08-16  Martin Liska  <mliska@suse.cz>
>>
>>     * acinclude.m4: New file.
>>     * config.in: New macro defines.
>>     * configure: Regenerated.
>>     * configure.ac: Detect atomic operations.
>> need GWM or similar review
>>
>>     * libgcov-profiler.c: Detect GCOV_SUPPORTS_ATOMIC and
>>     conditionaly enable/disable *_atomic functions.
>> OK.
>>
>> nathan
>
> Hi Nathan.
>
> Thanks for review, I'm CCing Jakub and Richard for the review.
> The patch should fix very similar issue spotted on AIX target by David.

What about Jakub's comment in the PR?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6

The proposed patch seems wrong or at least incomplete.  The recent
change is imposing a 64 bit DImode counter when producing 32 bit code.
PowerPC does support 64 bit atomic operations in 32 bit mode.

Was there a design decision that profile counters always should be 64
bits?  Either 32 bit targets won't support multi-threaded profiling or
32 bit targets can overflow the counter sooner.  Which is worse?
Which is more likely?

Thanks, David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]