Hi,
On 05 Sep 19:09, Ilya Verbin wrote:
I hope that it will not affect the regular LTO compilation. At least, the
'make check' did not reveal any regression on the system with linker plugin.
I found that relying on -flto option in lto-wrapper was a bad idea.
E.g., this simple case is not
Hi,
On 04 Sep 15:54, Thomas Schwinge wrote:
Aha, it's gcc/gcc.c:LINK_PLUGIN_SPEC that is unconditionally adding the
-fresolution option. Here is a hack that seems to make it work, but that
most certainly should be done differently:
Here is updated patch, which solves the problem with linker
Hi!
On Tue, 2 Sep 2014 21:49:46 +0400, Ilya Verbin iver...@gmail.com wrote:
This patch allows to compile binaries with offloading without passing -flto
option, and
w/o performing link-time optimizations of the host code.
Thanks for working on this!
How it works:
1. If there is at least
On 04 Sep 15:08, Thomas Schwinge wrote:
I'm facing one problem; I guess the crucial detail is that in my scenario
I'm using the linker plugin. The lto-wrapper is not being executed (and
thus no mkoffload being run), because »num_claimed_files == 0«.
Yeah I missed that. I tested this patch on
Hi!
On Thu, 04 Sep 2014 15:08:06 +0200, I wrote:
On Tue, 2 Sep 2014 21:49:46 +0400, Ilya Verbin iver...@gmail.com wrote:
This patch allows to compile binaries with offloading without passing -flto
option, and
w/o performing link-time optimizations of the host code.
Thanks for working
Hi!
On Mon, 18 Aug 2014 20:07:59 +0400, Ilya Verbin iver...@gmail.com wrote:
I discovered an issue in the LTO streaming out for target - currently any
file (even without any pragma) compiled with -fopenmp/-fopenacc contains
.gnu.target_lto_* sections. This increases the size of an object
Hi Bernd,
This patch allows to compile binaries with offloading without passing -flto
option, and
w/o performing link-time optimizations of the host code.
How it works:
1. If there is at least one function or global variable to offload, gcc sets
flag_generate_lto.
This enables writing the
On 18 Aug 18:24, Bernd Schmidt wrote:
I think I'd be happier if the function was called init_offload_table
and also collected functions, rather than leaving that to
expand_omp_target. I think the patch would be ok with that change.
For the functions it's not so easy to identify which of them
On 08/19/2014 12:41 PM, Ilya Verbin wrote:
On 18 Aug 18:24, Bernd Schmidt wrote:
I think I'd be happier if the function was called init_offload_table
and also collected functions, rather than leaving that to
expand_omp_target. I think the patch would be ok with that change.
For the functions
On 19 Aug 13:55, Bernd Schmidt wrote:
On 08/19/2014 12:41 PM, Ilya Verbin wrote:
For the functions it's not so easy to identify which of them to add into the
table, e.g.:
#pragma omp target
#pragma omp parallel
x++;
Here 2 functions with omp declare target attribute are
On 19 Aug 13:55, Bernd Schmidt wrote:
In any case, I think let's get this checked in for now and iterate later.
Committed revision 214148.
-- Ilya
Hi Bernd,
I discovered an issue in the LTO streaming out for target - currently any file
(even without any pragma) compiled with -fopenmp/-fopenacc contains
.gnu.target_lto_* sections. This increases the size of an object file and
makes lto-wrapper to run mkoffload.
Therefore, I propose to
On 08/18/2014 06:07 PM, Ilya Verbin wrote:
I discovered an issue in the LTO streaming out for target - currently any file
(even without any pragma) compiled with -fopenmp/-fopenacc contains
.gnu.target_lto_* sections. This increases the size of an object file and
makes lto-wrapper to run
Hi,
Here is the updated patch. offload_funcs/vars are now declared in omp-low.h,
the functions have a comment. Also it fixes the issue of offload_funcs/vars
corruption by the garbage collector. OK for gomp-4_0-branch?
-- Ilya
---
gcc/Makefile.in|1 +
gcc/gengtype.c |
On 04/17/2014 08:33 PM, Ilya Verbin wrote:
Could you please take a look at this patch? It fixes the ordering issue in the
tables stated above, and passes all the tests that I have. But I'm not sure
about its correctness from the architectural point of view.
I'm still skeptical relying on
On 10 Jun 15:52, Bernd Schmidt wrote:
On 04/17/2014 08:33 PM, Ilya Verbin wrote:
+{
+ /* Collect all omp-target global variables to offload_vars, if they have
not
+ been gathered earlier by input_offload_tables. */
+ if (vec_safe_is_empty (offload_vars))
What if a variable was
On 05/08/2014 12:11 PM, Bernd Schmidt wrote:
On 05/06/2014 05:32 PM, Ilya Verbin wrote:
On 05 Apr 17:22, Bernd Schmidt wrote:
Things seemed to work over here, but now I'm not certain whether the
__start_/__stop_ functionality is GNU ld specific? Maybe we should
just go back to the previous
On 05/06/2014 05:32 PM, Ilya Verbin wrote:
On 05 Apr 17:22, Bernd Schmidt wrote:
Things seemed to work over here, but now I'm not certain whether the
__start_/__stop_ functionality is GNU ld specific? Maybe we should
just go back to the previous version of this patch which didn't try
to use
On 05 Apr 17:22, Bernd Schmidt wrote:
Things seemed to work over here, but now I'm not certain whether the
__start_/__stop_ functionality is GNU ld specific? Maybe we should
just go back to the previous version of this patch which didn't try
to use this.
Bernd
This approach does not work
On 17 Apr 22:33, Ilya Verbin wrote:
Hi Jakub,
Could you please take a look at this patch? It fixes the ordering issue in
the
tables stated above, and passes all the tests that I have. But I'm not sure
about its correctness from the architectural point of view.
Thanks,
-- Ilya
On 27 Mar 17:16, Jakub Jelinek wrote:
On Thu, Mar 27, 2014 at 08:13:00PM +0400, Ilya Verbin wrote:
On 27 Mar 15:02, Jakub Jelinek wrote:
The tables need to be created before IPA, that way it really shouldn't
matter in what order you emit them. E.g. the outlined target functions
could
On Sat, Apr 05, 2014 at 05:22:09PM +0200, Bernd Schmidt wrote:
On 04/05/2014 05:04 PM, Thomas Schwinge wrote:
Is it a linker bug that I need to add something like the following?
--- libgcc/ompstuff.c
+++ libgcc/ompstuff.c
@@ -40,6 +40,12 @@ see the files COPYING3 and COPYING.RUNTIME
Hi!
On Fri, 4 Apr 2014 11:30:49 +0200, Bernd Schmidt ber...@codesourcery.com
wrote:
On 03/21/2014 04:20 PM, Jakub Jelinek wrote:
On Fri, Mar 21, 2014 at 04:13:45PM +0100, Bernd Schmidt wrote:
On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
When we were discussing the design last year, my
On 04/05/2014 05:04 PM, Thomas Schwinge wrote:
Is it a linker bug that I need to add something like the following?
--- libgcc/ompstuff.c
+++ libgcc/ompstuff.c
@@ -40,6 +40,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include libgcc_tm.h
#if
On 04/04/2014 07:55 AM, Thomas Schwinge wrote:
Hi!
On Thu, 3 Apr 2014 18:13:08 +0200, Bernd Schmidt ber...@codesourcery.com
wrote:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you?
Yes, it does, thanks! Please revert my patch
On 03/21/2014 04:20 PM, Jakub Jelinek wrote:
On Fri, Mar 21, 2014 at 04:13:45PM +0100, Bernd Schmidt wrote:
On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
When we were discussing the design last year, my strong preference was that
either this lives in some other crt object that mkoffload/linker
On 04/02/2014 10:36 AM, Thomas Schwinge wrote:
I see regressions in the libgomp testsuite for configurations where
offloading is not enabled:
spawn [...]/build/gcc/xgcc -B[...]/build/gcc/
[...]/source/libgomp/testsuite/libgomp.c/for-3.c
-B[...]/build/x86_64-unknown-linux-gnu/./libgomp/
2014-04-03 20:13 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you?
Shouldn't we just remove __OPENMP_TARGET__ argument from GOMP_target,
since we decided to pass it to
On 04/03/2014 06:53 PM, Ilya Verbin wrote:
2014-04-03 20:13 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you?
Shouldn't we just remove __OPENMP_TARGET__ argument from GOMP_target,
2014-04-03 21:06 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 04/03/2014 06:53 PM, Ilya Verbin wrote:
2014-04-03 20:13 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you?
On 04/03/2014 07:25 PM, Ilya Verbin wrote:
Yes, initially the idea was to use it for look up the right function.
But now each DSO will call GOMP_offload_register, and pass unique
pointer to __OPENMP_TARGET__ (host_table) for this DSO. Then
gomp_register_images_for_device registers all this host
2014-04-03 21:28 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 04/03/2014 07:25 PM, Ilya Verbin wrote:
Yes, initially the idea was to use it for look up the right function.
But now each DSO will call GOMP_offload_register, and pass unique
pointer to __OPENMP_TARGET__ (host_table) for
Hi!
On Thu, 3 Apr 2014 18:13:08 +0200, Bernd Schmidt ber...@codesourcery.com
wrote:
On 04/02/2014 10:36 AM, Thomas Schwinge wrote:
I see regressions in the libgomp testsuite for configurations where
offloading is not enabled:
spawn [...]/build/gcc/xgcc -B[...]/build/gcc/
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up offload target code based on the address of the
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up offload target code based on the address of the
Hi!
On Wed, 02 Apr 2014 09:34:29 +0200, I wrote:
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up
+#ifdef ACCEL_COMPILER
+ /* Decls are placed in reversed order in fat-objects, so we need to
+ revert them back if we compile target. */
...
Actually this change is incorrect. If host binary is built with -flto, then
both host gcc and target gcc read decls from lto and target_lto sections
On 03/27/2014 02:31 PM, Ilya Verbin wrote:
+#ifdef ACCEL_COMPILER
+ /* Decls are placed in reversed order in fat-objects, so we need to
+ revert them back if we compile target. */
...
Actually this change is incorrect. If host binary is built with -flto, then
both host gcc and target
On 03/27/2014 02:31 PM, Ilya Verbin wrote:
+#ifdef ACCEL_COMPILER
+ /* Decls are placed in reversed order in fat-objects, so we need to
+ revert them back if we compile target. */
...
Actually this change is incorrect. If host binary is built with -flto, then
both host gcc and target
On Thu, Mar 27, 2014 at 05:31:29PM +0400, Ilya Verbin wrote:
+#ifdef ACCEL_COMPILER
+ /* Decls are placed in reversed order in fat-objects, so we need to
+ revert them back if we compile target. */
...
Actually this change is incorrect. If host binary is built with -flto, then
both
On 27 Mar 15:02, Jakub Jelinek wrote:
The tables need to be created before IPA, that way it really shouldn't
matter in what order you emit them. E.g. the outlined target functions
could be added to the table during ompexp pass which actually creates the
outlined functions, the vars need to be
On 27 Mar 17:16, Jakub Jelinek wrote:
Which is why the table created for host by the ompexp pass should be
streamed into the target_lto sections (marked specially somehow, special
attribute or whatever), and then corresponding target table created from
that, rather then created from some
On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
When we were discussing the design last year, my strong preference was that
either this lives in some other crt object that mkoffload/linker plugin adds
to link, or that it would be completely mkoffload synthetized.
mkoffload is only concerned with
On Fri, Mar 21, 2014 at 04:13:45PM +0100, Bernd Schmidt wrote:
On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
When we were discussing the design last year, my strong preference was that
either this lives in some other crt object that mkoffload/linker plugin adds
to link, or that it would be
On 03/21/2014 04:20 PM, Jakub Jelinek wrote:
And, what is the exact reason why you are using protected visibility rather
than hidden?
Also, supposedly if you've used section names without . in them, the linker
itself would provide the symbols automatically and you wouldn't actually
need
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up offload target code based on the address of the
corresponding host function. There are two alternatives, one based on
named sections, and
On Thu, Mar 20, 2014 at 05:50:13PM +0100, Bernd Schmidt wrote:
--- libgcc/crtstuff.c (revision 208706)
+++ libgcc/crtstuff.c (working copy)
@@ -311,6 +311,15 @@ register_tm_clones (void)
}
#endif /* USE_TM_CLONE_REGISTRY */
+#if defined(HAVE_GAS_HIDDEN) defined(ENABLE_OFFLOADING)
47 matches
Mail list logo
