On Tue, Sep 17, 2013 at 01:56:39PM +0200, Richard Biener wrote:
> On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin <iver...@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
