public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Ilya Verbin <iverbin@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Uday Khedker <uday@cse.iitb.ac.in>, Jan Hubicka <hubicka@ucw.cz>,
		Richard Henderson <rth@redhat.com>,
	Kirill Yukhin <kirill.yukhin@gmail.com>,
		"Michael V. Zolotukhin" <michael.v.zolotukhin@gmail.com>,
	GCC Development <gcc@gcc.gnu.org>
Subject: Re: Questions about LTO infrastructure and pragma omp target
Date: Tue, 17 Sep 2013 11:56:00 -0000	[thread overview]
Message-ID: <CAFiYyc1Y1Pr00hwm9Auu3DX5Z-B7P9vAQBOFywKLpaHegswaOg@mail.gmail.com> (raw)
In-Reply-To: <20130917113010.GA22722@msticlxl57.ims.intel.com>

On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin <iverbin@gmail.com> wrote:
> On 17 Sep 10:12, Richard Biener wrote:
>> It looks more like a hack ;)  It certainly doesn't look scalable to multiple
>> target ISAs.  You also unconditionally invoke the target compiler (well, you
>> invoke the same compiler ...)
>
> Yes, I currently call the "target" compiler unconditionally, but it can be
> placed under a flag/env var/etc.  When we have multiple target ISAs, multiple
> target compilers will be invoked.  Each of them will read same IL from
> .gnu.target_lto_ and produce an executable for its target.
> Why this approach is not scalable?

Are you sure we have the same IL for all targets and the same targets
for all functions?  That would certainly simplify things, but you still need
a way to tell the target compiler which symbol to emit the function on
as the compile-stage will already necessarily refer to all target
variant symbols.

>> As far as I understand your patch the target IL is already produced by
>> the compile stage (always? what about possible target IL emit from
>> -ftree-parallelize-loops?)?
>
> Yes, I assume that IL is already produced, somehow like this:
> http://gcc.gnu.org/ml/gcc/2013-09/msg00123.html
> Probably the compile stage should somehow inform the lto-wrapper, that target
> compilers should be called.

I mean that (speaking in LTO way), you can end up emitting "target IL" from
the LTRANS stage.  So you'd re-run the LTO linker plugin and lto-wrapper
at the final link stage in case you compile with -flto(?)

>> As I understand Jakub he prefers things to work without -flto as well, so
>> target IL has to be handled by a different linker plugin and LTO would merely
>> be required to pass the target IL sections through the LTO pipeline and re-emit
>> it during LTRANS?
>
> If we want to reuse "LTO pipeline", the LTO infrastructure should be turn on
> (i.e. lto-wrapper should be called).
> With -flto, lto-wrapper will perform all usual things (WPA+LTRANS) + invoke all
> necessary target compilers.
> Without -flto it will merely invoke target compilers.
> I do not see how different linker plugin can help.  It will run lto-wrapper same
> way like current plugin?

Well, it certainly would be less LTO specific.

Richard.

> Thanks,
>   -- Ilya

  parent reply	other threads:[~2013-09-17 11:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-15 13:44 Ilya Verbin
2013-08-15 15:00 ` Jakub Jelinek
2013-08-15 19:19   ` Richard Biener
2013-08-23 13:15     ` Ilya Verbin
2013-08-23 14:38       ` Jakub Jelinek
2013-08-28  9:59         ` Basile Starynkevitch
2013-08-23 15:05       ` Richard Biener
2013-08-23 15:06         ` Jakub Jelinek
2013-08-25 22:36           ` Ilya Verbin
2013-08-26  7:32             ` Jakub Jelinek
2013-09-03 14:00               ` Michael V. Zolotukhin
2013-09-03 14:19                 ` Jakub Jelinek
2013-09-03 15:18                   ` Michael V. Zolotukhin
2013-09-03 17:39                     ` Thomas Schwinge
2013-09-03 18:30                       ` Michael V. Zolotukhin
2013-09-03 18:54                         ` Jakub Jelinek
2013-09-03 19:09                           ` Michael V. Zolotukhin
2013-09-16 17:14         ` Ilya Verbin
2013-09-17  8:12           ` Richard Biener
2013-09-17 11:31             ` Ilya Verbin
2013-09-17 11:54               ` Jakub Jelinek
2013-09-17 11:56               ` Richard Biener [this message]
2013-09-17 12:15                 ` Jakub Jelinek
2013-09-19 10:45                   ` Ilya Verbin
2013-09-19 10:50                     ` Jakub Jelinek

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=CAFiYyc1Y1Pr00hwm9Auu3DX5Z-B7P9vAQBOFywKLpaHegswaOg@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=iverbin@gmail.com \
    --cc=jakub@redhat.com \
    --cc=kirill.yukhin@gmail.com \
    --cc=michael.v.zolotukhin@gmail.com \
    --cc=rth@redhat.com \
    --cc=uday@cse.iitb.ac.in \
    /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).