This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/4] Add mkoffload for Intel MIC
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ilya Verbin <iverbin at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, gcc <gcc-patches at gcc dot gnu dot org>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Andrey Turetskiy <andrey dot turetskiy at gmail dot com>
- Date: Wed, 22 Oct 2014 09:57:17 +0200
- Subject: Re: [PATCH 1/4] Add mkoffload for Intel MIC
- Authentication-results: sourceware.org; auth=none
- References: <20141021171323 dot GA47586 at msticlxl57 dot ims dot intel dot com> <20141021171602 dot GB47586 at msticlxl57 dot ims dot intel dot com> <Pine dot LNX dot 4 dot 64 dot 1410212147070 dot 24064 at digraph dot polyomino dot org dot uk> <CADG=Z0GxD+zQfNsLb0w9t7FxSWj1DbPM6DU5VL0Tb7Wdk9dSiQ at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Oct 22, 2014 at 02:30:44AM +0400, Ilya Verbin wrote:
> > I don't see anything restricting this program to being built for GNU
> > *hosts*. Thus, it needs to be portable (to different hosts; obviously
> > it's target-architecture-specific) rather than relying on glibc
> > interfaces. (Providing appropriate functions in libiberty is of course an
> > option; thus, freely using obstacks is fine because they're in libiberty.)
>
> This mkoffload is expected to be built only with the offload compiler,
> which is expected to be configured with
> '--enable-as-accelerator-for=... --host=x86_64-*-linux-gnu
> --target=x86_64-*-linux-gnu'.
> Without $enable_as_accelerator it wouldn't be built. I will add more
> restrictions to config.gcc.
But why the --host=x86_64-*-linux-gnu restriction?
mkoffload looks to me like a typical host tool, but I don't understand
why it would require native compilation, it is a tool that arranges that
the offloading target compiler is invoked, and results linked back, but it
doesn't need to execute anything on the target, you don't need access to the
acceleration device for that and I don't see any reason why it couldn't be
run on s390-linux, or say mingw.
Both the primary compiler and offloading target compilers obviously have to
be configured for the same (or similar?) host, the target (for what they
generate code for) is given for both too (unless we start supporting say
powerpc64-linux primary compiler offloading to Intel MIC etc.) and build
irrelevant (e.g. you could build offloading compiler using canadian cross
with --enable-as-accelerator-for=x86_64-pc-linux --build=aarch64-linux \
--host=s390-linux --target=x86_64-intelmicemul-linux
and primary compiler with
--enable-offload-targets=x86_64-intelmicemul-linux-gnu=/some/path/ \
--build=armv7tel-linux-gnueabi --host=s390-linux --target=x86_64-pc-linux
). Or do you see any substantial reasons why this can't work?
> >> + nextval = strchrnul (curval, ':');
> >
> > I don't think strchrnul is portable (unless added to libiberty).
>
> It seems that there is no need to make this mkoffload so portable.
I disagree, see above. I think this isn't so performance critical code
that you can't just use portable:
nextval = strchr (curval, ':');
if (nextval == NULL)
nextval = strchr (curval, '\0');
Jakub