public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Evgeny Stupachenko <evstupac@gmail.com>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Jeff Law <law@redhat.com>, Bernd Schmidt <bschmidt@redhat.com>,
		Bernd Schmidt <bernds_cb1@t-online.de>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] New attribute to create target clones
Date: Fri, 09 Oct 2015 21:44:00 -0000	[thread overview]
Message-ID: <CAOvf_xzpEV=q7Mi6=xEr=cSV8D0NOcpeYR8mJgAgkz5kocuYQg@mail.gmail.com> (raw)
In-Reply-To: <20151009200422.GA23615@kam.mff.cuni.cz>

On Fri, Oct 9, 2015 at 11:04 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Fri, Oct 9, 2015 at 9:27 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >> >Of course it also depends what you inline into function. You can have
>> >> >
>> >> >bar() target(-mavx) {fancy avx code}
>> >> >foobar() { ...... if (avx) bar();}
>> >> >foo() ctarget(-mavx,-mno-avx) {....foobar();....}
>>
>> "no-" targets are not supported
>
> Why not? I suppose I can use -march=x86_64 in a file compiled with -march=core-avx2 or something like that, too.
Sure, you can. target(arch=x86-64) is ok. I mean exactly target(no-avx) returns:

aaa.cpp: In function '<built-in>':
aaa.cpp:7:5: error: No dispatcher found for no-avx
 int bar()
     ^

>>
>> >> >
>> >> >Now if you compile with -mavx and because ctarget takes effect only after inlining,
>> >> >at inlining time the target attributes will match and we can edn up inline bar->foobar->foo.
>> >> >After that we multiversion foo and drop AVX flag we will likely get ICE at expansion
>> >> >time.
>> >> But isn't that avoided by fixing up the call graph so that all calls
>> >> to the affected function are going through the dispatcher?  Or is
>> >> that happening too late?
>> >
>> > There is dispatcher only for foo that is the root of the callgarph tree.
>> > When inlining we compare target attributes for match (in can_inline_edge_p).
>> > We do not compare ctarget attributes.  Expanding ctarget to target early would
>> > avoid need for ctarget handling.
>> Currently inlining is disabled for functions with target_clone attribute:
>
> Do you also disable inlining into functions with target_clone?
> What I am concerned about is early inliner inlining (say) AVX code into ctarget
> function because at early inlining time the target is not applied, yet.
Right. Now I've got your point and ICE on the test.
Yes the solution is to disable inline into target_clones function.
Or to move the pass creating clones before inline (as you suggested)
and leave dispatcher creator after inline.

I like you suggestion. It fixes the ICE.
I'll fix the patch and retest.

Thank you for the review,
Evgeny.


>
> Honza

  reply	other threads:[~2015-10-09 21:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-27 11:35 Evgeny Stupachenko
2015-09-08 11:47 ` Evgeny Stupachenko
2015-09-16 11:42   ` Evgeny Stupachenko
2015-09-21 13:43 ` Bernd Schmidt
2015-09-22 20:24   ` Jeff Law
2015-09-22 21:09     ` Bernd Schmidt
2015-09-22 23:52       ` Evgeny Stupachenko
2015-09-25  0:02         ` Evgeny Stupachenko
2015-10-02 13:18           ` Evgeny Stupachenko
2015-10-08 19:00           ` Jeff Law
2015-10-08 19:23             ` Jan Hubicka
2015-10-08 19:53               ` Jeff Law
2015-10-08 21:36                 ` Jan Hubicka
2015-10-09 17:45                   ` Jeff Law
2015-10-09 18:27                     ` Jan Hubicka
2015-10-09 19:57                       ` Evgeny Stupachenko
2015-10-09 20:04                         ` Jan Hubicka
2015-10-09 21:44                           ` Evgeny Stupachenko [this message]
2015-10-12 23:35                             ` Evgeny Stupachenko
2015-10-14 21:32                               ` Evgeny Stupachenko
2015-10-22 18:07                                 ` Evgeny Stupachenko
2015-10-26 15:59                               ` Jeff Law
2015-10-29 13:42                                 ` Evgeny Stupachenko
2015-10-29 17:07                                   ` Jan Hubicka
2015-10-29 18:15                                     ` Evgeny Stupachenko
2015-10-30  3:55                                       ` Jan Hubicka
2015-10-30  5:30                                       ` Jeff Law
2015-10-30 12:30                                         ` Evgeny Stupachenko
2015-10-08 20:01             ` Evgeny Stupachenko
2015-10-09  4:05               ` Jeff Law
2015-10-08 16:39       ` Jeff Law
2015-10-31 10:52 Dominique d'Humières
2015-11-02 14:50 ` Evgeny Stupachenko
2015-11-02 15:22   ` Dominique d'Humières
2015-11-02 17:02   ` Jeff Law
2015-11-03 11:45     ` Evgeny Stupachenko

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='CAOvf_xzpEV=q7Mi6=xEr=cSV8D0NOcpeYR8mJgAgkz5kocuYQg@mail.gmail.com' \
    --to=evstupac@gmail.com \
    --cc=bernds_cb1@t-online.de \
    --cc=bschmidt@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=law@redhat.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).