This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Questions about LTO infrastructure and pragma omp target
- From: Ilya Verbin <iverbin at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Uday Khedker <uday at cse dot iitb dot ac dot in>, Jan Hubicka <hubicka at ucw dot cz>, Richard Henderson <rth at redhat dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 17 Sep 2013 15:30:10 +0400
- Subject: Re: Questions about LTO infrastructure and pragma omp target
- Authentication-results: sourceware.org; auth=none
- References: <20130815133639 dot GA42355 at msticlxl57 dot ims dot intel dot com> <20130815134437 dot GB1814 at tucnak dot redhat dot com> <4df844f6-f385-4e63-9413-8ea341992b77 at email dot android dot com> <20130823105527 dot GA6976 at msticlxl57 dot ims dot intel dot com> <85e37f42-69fe-4bbf-bf1d-f73194e7c444 at email dot android dot com> <20130916171405 dot GA18788 at msticlxl57 dot ims dot intel dot com> <CAFiYyc3nGuvf-=H1k8DvrCp9zLkEm-WP7kpq7MywzU6pMG4+nA at mail dot gmail dot com>
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?
> 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.
> 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?
Thanks,
-- Ilya