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: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Ilya Verbin <iverbin at gmail 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 14:12:28 +0200
- 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> <20130917113010 dot GA22722 at msticlxl57 dot ims dot intel dot com> <CAFiYyc1Y1Pr00hwm9Auu3DX5Z-B7P9vAQBOFywKLpaHegswaOg at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Sep 17, 2013 at 01:56:39PM +0200, Richard Biener wrote:
> 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.
This has been discussed to some extent during Cauldron.
Yes, there are various target dependencies in the GIMPLE IL, many of them
very early.
Some of the dependencies are there already during preprocessing, there is
nothing to do about those.
For some things we will just rely on the host and target having the same
properties, stuff like BITS_PER_UNIT, type layout/alignment, endianity,
the OpenMP (and I believe OpenACC too) model effectively requires that,
while you don't need to have shared address space between host and target
(but can have that), for the mapping/unmapping it is assumed that you can
simply take host portions of memory and copy them over to the target device
or back, as sequence of bytes, there is no form of RPC or similar that would
tweak endianity, differently sized types, padding, etc.
While you can say have 64-bit host and 32-bit target or vice versa, the
target IL will simply contain precision info, alignment, structure layout
etc. and just will have to generate right code for that (something that is
native long on the host can be native long long on the target or vice versa
etc.).
Then there are dependencies we'd ideally get rid of, at least pre-IPA,
stuff like BRANCH_COST, but generally that is just an optimization issue and
thus not that big deal.
Bigger issue are target specific builtins, I guess we'll either have to just
sorry on those, or have some helper targhook that will translate a subset of
md builtins from selected hosts to selected targets.
Preferrably, before IPA we'd introduce as few target dependencies into the
IL as possible, and gradually towards RTL can add more dependencies (e.g.
the vectorizer adds so many target dependencies that at that point trying to
use the IL for a different target is practically impossible).
Jakub