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: David Edelsohn <dje dot gcc at gmail dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: Nathan Sidwell <nathan at acm dot org>, Jeff Law <law at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <jh at suse dot cz>
- Date: Thu, 10 Nov 2016 11:17:04 -0500
- 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> <8e2214bb-3944-7bc7-0d61-098f9f4cadae@suse.cz>
On Thu, Nov 10, 2016 at 10:58 AM, Martin Liška <mliska@suse.cz> wrote:
> On 11/10/2016 04:43 PM, 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'?
>>
>> It's also not clear what problem it's solving for the user? If the user needs atomic update, they should get a hard error if the target doesn't support it. If they don't need atomic, why ask for it?
>
> My initial motivation was to automatically selected -fprofile-update=atomic if supported by a target and when '-pthread' is present on command line.
> As it's very problematic to identify (from GCC driver) whether a target supports or not atomic updates, 'maybe' option is the only possible we can guess.
>
>>
>> But as ever, I'm not going to veto it.
>
> Other option is to disable selection of -fprofile-update=atomic automatically.
Unfortunately, this cannot use a configure test or manually set value
based on target because the same gcc.c driver is invoked with
different options that may provide atomic update in some variants and
no atomic update in other (e.g., -m64) because the profile counter is
64 bits.
Maybe instead of adding "maybe", we need to change the severity of the
warning so that the warning is not emitted by default.
- David