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(-)
>>>>
>>>>
>>
prev parent 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).