public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Martin Liška" <mliska@suse.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Nathan Sidwell <nathan@acm.org>
Subject: Re: [PATCH] Fix target clones (PR gcov-profile/85370).
Date: Wed, 01 Aug 2018 11:02:00 -0000	[thread overview]
Message-ID: <ffdda19f-d44b-ac71-a55d-62ed39bfe6c6@suse.cz> (raw)
In-Reply-To: <CAFiYyc1FAwhYp+irZGwtfctEf96DEROfEKBkc4r_1AH8DDTKkQ@mail.gmail.com>

On 07/26/2018 11:00 AM, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 10:44 AM Martin Liška <mliska@suse.cz> wrote:
>>
>> On 07/25/2018 03:50 PM, Richard Biener wrote:
>>> On Wed, Jul 25, 2018 at 3:38 PM Martin Liška <mliska@suse.cz> wrote:
>>>>
>>>> Hi.
>>>>
>>>> Target clones have DECL_ARTIFICIAL set to 1, but we want to
>>>> provide --coverage for that. With patched GCC on can see:
>>>>
>>>>         -:    0:Source:pr85370.c
>>>>         -:    0:Graph:pr85370.gcno
>>>>         -:    0:Data:pr85370.gcda
>>>>         -:    0:Runs:1
>>>>         -:    0:Programs:1
>>>>         -:    1:__attribute__((target_clones("arch=slm","default")))
>>>>         1:    2:int foo1 (int a, int b) { // executed #### wrongly
>>>>         1:    3:  return a + b;
>>>>         -:    4:}
>>>> ------------------
>>>> foo1.arch_slm.0:
>>>>         0:    2:int foo1 (int a, int b) { // executed #### wrongly
>>>>         0:    3:  return a + b;
>>>>         -:    4:}
>>>> ------------------
>>>> foo1.default.1:
>>>>         1:    2:int foo1 (int a, int b) { // executed #### wrongly
>>>>         1:    3:  return a + b;
>>>>         -:    4:}
>>>> ------------------
>>>>         -:    5:
>>>>         1:    6:int foo2 (int a, int b) {
>>>>         1:    7:  return a + b;
>>>>         -:    8:}
>>>>         -:    9:
>>>>         1:   10:int main() {
>>>>         1:   11:  foo1(1, 1);
>>>>         1:   12:  foo2(1, 1);
>>>>         1:   13:  return 1;
>>>>         -:   14:}
>>>>
>>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>>> Will install in couple of days if no objection.
>>>
>>> I wonder if representing the clones as artificial but have their body be
>>> marked as inline instance of the original function works for gcov?
>>
>> Do you mean an inlined functions? If so, these are fine as gimple statements
>> that were inlined still point to original source code.
>>
>>  I think
>>> it should for debuggers.  A similar case is probably the
>>> static_constructors_and_destructors
>>
>> Actually static_c_a_d were motivation for exclusion. They have location set
>> to last line in source code and it's not intentional. Similarly implicit
>> ctors/dtors (e.g. Centering<3>::Centering(Centering<3> const&)) are ignored
>> as they don't have any real line of code in a source file.
>>
>>> function which has all ctors/dtors of static objects inlined into but itself is
>>> of course artificial.  Is that handled correctly?
>>
>> Hope I explained enough?
> 
> The question is what you like to see - looking at your figure above it
> looks like
> you want to see separate coverage for the different clones even when they
> are auto-generated by GCC?

Probably yes, I don't have any strong opinion here.

 Isn't that inconsistent with for example
> IPA-CP generated clones or inline instances?  Manual multiversions
> in source are already reported separately?

Yes, that would be reported separately.

Martin

> 
> Richard.
> 
>> Martin
>>
>>>
>>> Richard.
>>>
>>>> Martin
>>>>
>>>> gcc/ChangeLog:
>>>>
>>>> 2018-07-25  Martin Liska  <mliska@suse.cz>
>>>>
>>>>         PR gcov-profile/85370
>>>>         * coverage.c (coverage_begin_function): Do not mark target
>>>>         clones as artificial functions.
>>>> ---
>>>>  gcc/coverage.c | 3 ++-
>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>>
>>

      reply	other threads:[~2018-08-01 11:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25 13:38 Martin Liška
2018-07-25 13:51 ` Richard Biener
2018-07-26  8:44   ` Martin Liška
2018-07-26  9:00     ` Richard Biener
2018-08-01 11:02       ` Martin Liška [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ffdda19f-d44b-ac71-a55d-62ed39bfe6c6@suse.cz \
    --to=mliska@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nathan@acm.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).