Hi Bernd!
On Mon, 4 Aug 2014 23:00:07 +0200, Bernd Schmidt ber...@codesourcery.com
wrote:
On 07/23/2014 04:37 PM, Ilya Verbin wrote:
On 23 Jul 16:16, Bernd Schmidt wrote:
Here's the latest version, which fixes some more issues and removes
things that are now unnecessary.
I've committed
On 07/23/2014 04:37 PM, Ilya Verbin wrote:
On 23 Jul 16:16, Bernd Schmidt wrote:
Here's the latest version, which fixes some more issues and removes
things that are now unnecessary. Configure scripts and toplevel
autogenned stuff is left out and must be regenerated.
Are you OK with me
In gcc/configure.ac:
AC_SUBST(enable_accelerator)
offload_targets=`echo $offload_targets | sed -e 's#,#:#'`
AC_DEFINE_UNQUOTED(OFFLOAD_TARGETS, $offload_targets,
Looks like, it should be: sed -e 's#,#:#g'
-- Ilya
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
On 27 Jun 09:32, Bernd Schmidt wrote:
Sorry for the delayed reply, I was travelling. There seem to be some
thinkos in the configure script and Makefile; can you try the
following (don't forget to regenerate configure)? It seems to work
for ptx (with
On 23 Jul 16:16, Bernd Schmidt wrote:
Here's the latest version, which fixes some more issues and removes
things that are now unnecessary. Configure scripts and toplevel
autogenned stuff is left out and must be regenerated.
Are you OK with me installing this on gomp-4_0-branch? If there's
On 07 Jul 17:03, Bernd Schmidt wrote:
Is libgomp the only problematic one? (Does the accel compiler even
need one?) It seems to be installed in /usr/lib rather than in a
gcc-specific directory, which is a little surprising to me. It may
be necessary to give the accel compiler a different
On 07/10/2014 08:24 PM, Ilya Verbin wrote:
On 07 Jul 17:03, Bernd Schmidt wrote:
Is libgomp the only problematic one? (Does the accel compiler even
need one?) It seems to be installed in /usr/lib rather than in a
gcc-specific directory, which is a little surprising to me. It may
be necessary to
On 27 Jun 09:32, Bernd Schmidt wrote:
Sorry for the delayed reply, I was travelling. There seem to be some
thinkos in the configure script and Makefile; can you try the
following (don't forget to regenerate configure)? It seems to work
for ptx (with some additional changes to allow ptx builds
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
2) Or should I build accel compiler as a cross from
x86_64-pc-linux-gnu to x86_64-intelmic-linux-gnu?
Yes, that's the general idea.
Will it help to distinguish the libs?
Is libgomp the only problematic one? (Does the accel compiler even need
On Mon, Jul 07, 2014 at 05:03:07PM +0200, Bernd Schmidt wrote:
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
2) Or should I build accel compiler as a cross from
x86_64-pc-linux-gnu to x86_64-intelmic-linux-gnu?
Yes, that's the general idea.
Will it help to distinguish the libs?
Is libgomp
On Mon, Jul 07, 2014 at 05:14:27PM +0200, Jakub Jelinek wrote:
We need a libgomp for the offload targets to be different from the host
libgomp even on targets like mic, because there are various omp_* functions
that should behave differently. Or the host libgomp needs to have a way how
to
On 06/19/2014 12:19 PM, Ilya Verbin wrote:
On 18 Jun 16:22, Bernd Schmidt wrote:
What I think you need to do is
For the first compiler:
--enable-as-accelerator-for=x86_64-pc-linux-gnu
--target=x86_64-intelmic-linux-gnu --prefix=/somewhere
No --enable-accelerator options at all. This should
On 18 Jun 16:22, Bernd Schmidt wrote:
What I think you need to do is
For the first compiler:
--enable-as-accelerator-for=x86_64-pc-linux-gnu
--target=x86_64-intelmic-linux-gnu --prefix=/somewhere
No --enable-accelerator options at all. This should work, if it
doesn't let me know what you
On 17 Jun 21:22, Bernd Schmidt wrote:
On 06/17/2014 08:20 PM, Ilya Verbin wrote:
I don't get this part of the plan. Where a host compiler will look for
mkoffloads?
E.g., first I configure/make/install the target gcc and corresponding
mkoffload with the following options:
On 06/18/2014 04:13 PM, Ilya Verbin wrote:
On 17 Jun 21:22, Bernd Schmidt wrote:
On 06/17/2014 08:20 PM, Ilya Verbin wrote:
I don't get this part of the plan. Where a host compiler will look for
mkoffloads?
E.g., first I configure/make/install the target gcc and corresponding mkoffload
Hello Bernd,
On 28 Feb 17:21, Bernd Schmidt wrote:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it
into locations where the host will eventually be able to find it.
On 06/17/2014 08:20 PM, Ilya Verbin wrote:
Hello Bernd,
On 28 Feb 17:21, Bernd Schmidt wrote:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it
into locations where the
2014-03-01 1:40 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it into
locations where the host will eventually be able to
On 05/27/2014 12:17 PM, Ilya Verbin wrote:
2014-03-01 1:40 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it into
locations
2014-05-27 14:59 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There isn't a way to do this. For ptx, target libraries can't be built
anyway. For your use case, I'd recommend building the offload gcc first,
installing it, and then building the host gcc with --enable-offload-targets
as
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
2014-05-27 14:59 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There isn't a way to do this. For ptx, target libraries can't be built
anyway. For your use case, I'd recommend building the offload gcc first,
installing it, and then building the host
2014-05-27 15:15 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
Do I understand correctly that you recommend to build our offload gcc
manually, rather than during configure/make?
Well, configure/make it separately - build and install it first.
If
On 05/27/2014 05:33 PM, Ilya Verbin wrote:
2014-05-27 15:15 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
Do I understand correctly that you recommend to build our offload gcc
manually, rather than during configure/make?
Well, configure/make it
On 03/12/2014 03:51 PM, Ilya Verbin wrote:
2014-03-12 18:12 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
LGTM. Shall I start committing my changes to the branch?
Yes, I think you should commit your changes.
And we will rewrite our part to use the new configure approach.
Done now. I
On 17 Mar 16:00, Thomas Schwinge wrote:
GOMP_4.0 {
global:
+ GOMP_offload_register;
GOMP_barrier_cancel;
GOMP_cancel;
GOMP_cancellation_point;
Now that the GOMP_4.0 symbol version is being used in GCC trunk, and will
be in the GCC 4.9 release, can we still add new
Hi!
On Sat, 8 Mar 2014 18:50:15 +0400, Ilya Verbin iver...@gmail.com wrote:
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -208,6 +208,7 @@ GOMP_3.0 {
GOMP_4.0 {
global:
+ GOMP_offload_register;
GOMP_barrier_cancel;
GOMP_cancel;
On Mon, Mar 17, 2014 at 04:00:11PM +0100, Thomas Schwinge wrote:
Hi!
On Sat, 8 Mar 2014 18:50:15 +0400, Ilya Verbin iver...@gmail.com wrote:
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -208,6 +208,7 @@ GOMP_3.0 {
GOMP_4.0 {
global:
+ GOMP_offload_register;
Hi,
On 03/08/2014 03:50 PM, Ilya Verbin wrote:
Here is updated patch for libgomp. It assumes that there is a constructor with
a call to GOMP_offload_register in every target image, created by mkoffload
tool. How does this look?
LGTM. Shall I start committing my changes to the branch?
2014-03-12 18:12 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
LGTM. Shall I start committing my changes to the branch?
Yes, I think you should commit your changes.
And we will rewrite our part to use the new configure approach.
-- Ilya
Hi Bernd,
Here is updated patch for libgomp. It assumes that there is a constructor with
a call to GOMP_offload_register in every target image, created by mkoffload
tool. How does this look?
---
libgomp/libgomp.map |1 +
libgomp/plugin-host.c | 58 -
libgomp/target.c
On 03/05/2014 06:15 PM, Ilya Verbin wrote:
On 28 Feb 17:21, Bernd Schmidt wrote:
I think it won't help that much - I still think this entire scheme
is likely to fail on nvptx. I'll try to construct an example at
some point.
One other thing about the split tables is that we don't have to
write
2014-03-06 12:47 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
I don't see why you want the array of target descriptors - it would take
some effort to construct, and as far as I can tell it's unnecessary. You
can just pass a pointer to the corresponding descriptor to every
On 03/06/2014 12:11 PM, Ilya Verbin wrote:
Do I understand correctly, that you propose to do so:
extern void *_omp_host_func_table[];
extern void *_omp_host_var_table[];
extern void *_omp_host_funcs_end[];
extern void *_omp_host_vars_end[];
void *__OPENMP_TARGET_HOST__[]
__attribute__
2014-03-06 15:53 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
No. I don't think we need a global constructor for registering
__OPENMP_TARGET_HOST__ - this would unnecessarily bloat crtbegin/crtend. We
also shouldn't need to have the target tables known outside of the image
constructed by
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
* Functions and variables now go into different tables, otherwise
intermixing between them could be a problem that causes tables to
go out of sync between host and target (imagine one big table being
generated by ptx
On 02/28/2014 05:09 PM, Ilya Verbin wrote:
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
* Functions and variables now go into different tables, otherwise
intermixing between them could be a problem that causes tables to
go out of sync between host and target
On 02/28/2014 05:21 PM, Bernd Schmidt wrote:
On 02/28/2014 05:09 PM, Ilya Verbin wrote:
Unfortunately I don't fully understand this configure magic... When a
user specifies 2 or 3 accelerators during configuration with
--enable-accelerators, will several different accel-gccs be built?
No -
On 28 Feb 17:21, Bernd Schmidt wrote:
It would help to see the code you have on the libgomp side, I don't
believe that's been posted yet?
It was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01777.html
And below is the updated version.
---
libgomp/libgomp.map |1 +
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There were still a number of things in these patches that did not make sense
to me and which I've changed. Let me know if there was a good reason for the
way some of these things were originally done.
* Functions and variables
On 02/21/2014 04:17 PM, Ilya Verbin wrote:
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There were still a number of things in these patches that did not make sense
to me and which I've changed. Let me know if there was a good reason for the
way some of these things were
2014-02-21 19:41 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The problem is that ptx does not have a linker, so we cannot exactly
reproduce what happens on the host side. We have to process all host .o
files in one single invocation of ptx lto1, and produce a single ptx
assembly file,
Hi Bernd and Thomas,
Are you planning to support offloading from DSO in PTX/CUDA
environment? If yes, how are you going to solve the problem of the
collision of function names from different DSOs?
However, if we decide to use element-wise host-target address mapping,
there are opportunities to
On 02/14/2014 03:49 PM, Ilya Verbin wrote:
Hi Bernd and Thomas,
Are you planning to support offloading from DSO in PTX/CUDA
environment? If yes, how are you going to solve the problem of the
collision of function names from different DSOs?
What I'm currently trying to do is to use
On Fri, Feb 14, 2014 at 04:01:46PM +0100, Bernd Schmidt wrote:
What I'm currently trying to do is to use get_file_function_name,
which should provide a unique string that can be used to look up an
offloaded function. That was suggested by Nathan Sidwell, I'd
forgotten that such a function
On 02/14/2014 04:12 PM, Jakub Jelinek wrote:
On Fri, Feb 14, 2014 at 04:01:46PM +0100, Bernd Schmidt wrote:
What I'm currently trying to do is to use get_file_function_name,
which should provide a unique string that can be used to look up an
offloaded function. That was suggested by Nathan
On Fri, Feb 14, 2014 at 04:50:34PM +0100, Bernd Schmidt wrote:
How many offloaded functions do we really expect to have in an
executable? I don't think that's likely to be a bottleneck.
First of all, this isn't just about offloaded functions, but also any
global variables that need to be mapped
On 01/28/2014 01:52 PM, Ilya Verbin wrote:
The table is used in libgomp (see my patch [1]), as proposed by Jakub
(see [2]). The idea is that the order of entries in the host and
target tables must be identical. This allows to set up one-to-one
correspondence between host and target addresses.
2014/1/29 Bernd Schmidt ber...@codesourcery.com:
I was worried the answer was going to be something like this. These are
produced by two different compilers/linkers, aren't they? This seems really
fragile to me and a recipe for hard-to-debug silent failures.
Yes.
First we let the driver
48 matches
Mail list logo
