This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Introduce -fprofile-update=maybe-atomic
- From: Nathan Sidwell <nathan at acm dot org>
- To: Martin Liška <mliska at suse dot cz>, Jeff Law <law at redhat dot com>, Andi Kleen <andi at firstfloor dot org>
- Cc: gcc-patches at gcc dot gnu dot org, jh at suse dot cz, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Thu, 10 Nov 2016 08:14:06 -0800
- Subject: Re: [PATCH] Introduce -fprofile-update=maybe-atomic
- Authentication-results: sourceware.org; auth=none
- References: <87f2bc4f-c4df-eadd-aec6-a937ed0ccaba@acm.org> <1253ac69-3301-f185-e43a-a34cadf8f51e@suse.cz> <67fda6d2-9b3e-a0d1-effc-34e1115030b2@acm.org> <b62f3336-b332-048f-ed2f-9392824f0b84@suse.cz> <1ff3cc75-7cee-79f3-395b-ef7a4d286a3d@acm.org> <04a05835-4666-4d7d-c1a9-d4bcc4ea924a@suse.cz> <ac9182f6-7164-9426-c55b-c13a1a30d3bd@suse.cz> <87k2fpdatl.fsf@tassilo.jf.intel.com> <6f8b1905-818b-bfff-1bf3-5ba04f3b4b64@suse.cz> <c526f177-0304-787d-c57d-3fd3e49a57e5@redhat.com> <20160818155130.GE5871@two.firstfloor.org> <631cf1bd-8ae9-f07b-5672-5084b699f650@redhat.com> <2c750f4c-c96c-2b22-43ae-53bbebf18af8@suse.cz> <73aa44d7-5287-e4b8-6188-a87d52d3d6b9@acm.org> <9aca1f7c-e7eb-e101-249e-8b5edd21cd48@suse.cz> <2419555f-7271-d64d-94ac-ac97ee7cb953@suse.cz> <4cbaad58-421d-cef5-e1b1-6c78a56d18b8@suse.cz> <5b7cdf6c-54e4-126b-1461-26f88b45dbbb@suse.cz> <36aaf074-5042-c4b9-8d47-9f52313765d6@acm.org>
On 11/10/2016 07:43 AM, Nathan Sidwell wrote:
On 11/10/2016 05:19 AM, Martin Liška wrote:
On 10/13/2016 05:34 PM, Martin Liška wrote:
Hello.
As it's very hard to guess from GCC driver whether a target supports
atomic updates
for GCOV counter or not, I decided to come up with a new option
value (maybe-atomic),
that would be transformed in a corresponding value (single or
atomic) in tree-profile.c.
The GCC driver selects the option when -pthread is present in the
command line.
That should fix all tests failures seen on AIX target.
Patch can bootstrap on ppc64le-redhat-linux and survives regression
tests.
Ready to be installed?
I dislike this. If it's hard for gcc itself to know, how much harder
for the user must it be? (does gcc have another instance of an option
that behaves 'prefer-A-or-B-if-you-can't'?
Thinking further. why isn't the right solution for
-fprofile-update=atomic when faced with a target that cannot support it to:
a) issue an error and bail out at the first opportunity
b) or issue a warning and fall back to single threaded update?
For #b presumably there'll be the capability of suppressing that
particular warning?
nathan
--
Nathan Sidwell