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
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
48 matches
Mail list logo
