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 wor
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 linke
Hi!
On Thu, 04 Sep 2014 15:08:06 +0200, I wrote:
> On Tue, 2 Sep 2014 21:49:46 +0400, Ilya Verbin 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!
>
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
Hi!
On Tue, 2 Sep 2014 21:49:46 +0400, Ilya Verbin 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 one function o
Hi!
On Mon, 18 Aug 2014 20:07:59 +0400, 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
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 byte
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
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" attr
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 i
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/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 mkof
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 re
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 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 vari
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 orde
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 vers
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 this
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 w
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,
> -- Il
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
>
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.RUNTI
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 defined(HAVE_GA
Hi!
On Fri, 4 Apr 2014 11:30:49 +0200, Bernd Schmidt
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 strong preference
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 p
On 04/04/2014 07:55 AM, Thomas Schwinge wrote:
Hi!
On Thu, 3 Apr 2014 18:13:08 +0200, Bernd Schmidt
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 when committing yours.
Hi!
On Thu, 3 Apr 2014 18:13:08 +0200, Bernd Schmidt
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/
> >> [...]/source/li
2014-04-03 21:28 GMT+04:00 Bernd Schmidt :
> 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
>
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:06 GMT+04:00 Bernd Schmidt :
> On 04/03/2014 06:53 PM, Ilya Verbin wrote:
>>
>> 2014-04-03 20:13 GMT+04:00 Bernd Schmidt :
>>>
>>> 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 _
On 04/03/2014 06:53 PM, Ilya Verbin wrote:
2014-04-03 20:13 GMT+04:00 Bernd Schmidt :
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 pa
2014-04-03 20:13 GMT+04:00 Bernd Schmidt :
> 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 GOMP_offload_register?
-- Ilya
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/
-
Hi!
On Wed, 02 Apr 2014 09:34:29 +0200, I wrote:
> On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt
> 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
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt
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
> corresponding host
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt
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
> corresponding host
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 po
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 be added to the table during ompexp p
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
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, th
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 gcc
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 gcc
>+#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 sectio
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 begin/end
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 b
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 g
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_OFFLOADIN
47 matches
Mail list logo
