| Message ID | 20141114160709.GB40445@msticlxl57.ims.intel.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Nov 14, 2014 at 8:07 AM, Ilya Verbin <iverbin@gmail.com> wrote: > <Resending to gcc-patches@gcc.gnu.org> > > Hi, > > This patch fixes recent regressions in libgomp testsuite: > https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00343.html > They are reproducible only with ld from trunk, ld 2.24 works fine. > > When GCC emits sections with offload IR, it should not emit "__gnu_lto_slim" > symbol, otherwise linker plugin tries to compile LTO IR, which is not present. > > Bootstrap and regtesting on x86_64-linux using binutils 20141114 in progress. > OK for trunk when finished? > > Thanks, > -- Ilya > > > gcc/ > * cgraphunit.c (symbol_table::compile): Set flag_fat_lto_objects > in case of g->have_offload. > > > diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c > index 534c613..584a84e 100644 > --- a/gcc/cgraphunit.c > +++ b/gcc/cgraphunit.c > @@ -2178,7 +2178,10 @@ symbol_table::compile (void) > > /* Offloading requires LTO infrastructure. */ > if (!in_lto_p && g->have_offload) > - flag_generate_lto = 1; > + { > + flag_generate_lto = 1; > + flag_fat_lto_objects = 1; > + } > > /* If LTO is enabled, initialize the streamer hooks needed by GIMPLE. */ > if (flag_generate_lto) What happens when -flto is used on command line? Will we generate both LTO IR and offload IR?
On 14 Nov 08:46, H.J. Lu wrote: > What happens when -flto is used on command line? Will we > generate both LTO IR and offload IR? Right. I'm not sure whether we should make slim objects in case of LTO + offload IR... -- Ilya
On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin <iverbin@gmail.com> wrote: > On 14 Nov 08:46, H.J. Lu wrote: >> What happens when -flto is used on command line? Will we >> generate both LTO IR and offload IR? > > Right. > > I'm not sure whether we should make slim objects in case of LTO + offload IR... > Isn't __gnu_lto_slim only applied to regular LTO IR? Should offload IR be handled separately from regular LTO IR? It is odd to use flag_fat_lto_objects to control offload IR.
On 14 Nov 09:01, H.J. Lu wrote: > On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin <iverbin@gmail.com> wrote: > > On 14 Nov 08:46, H.J. Lu wrote: > >> What happens when -flto is used on command line? Will we > >> generate both LTO IR and offload IR? > > > > Right. > > > > I'm not sure whether we should make slim objects in case of LTO + offload IR... > > > > Isn't __gnu_lto_slim only applied to regular LTO IR? Should offload IR be > handled separately from regular LTO IR? It is odd to use flag_fat_lto_objects > to control offload IR. It is handled separately, but it uses a common infrastructure with regular LTO for streaming, therefore compile_file automatically emits __gnu_lto_slim when there is at least one section with IR (flag_generate_lto is set). You propose to introduce a second flag like flag_fat_lto_objects to disable __gnu_lto_slim? -- Ilya
On Fri, Nov 14, 2014 at 9:08 AM, Ilya Verbin <iverbin@gmail.com> wrote: > On 14 Nov 09:01, H.J. Lu wrote: >> On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin <iverbin@gmail.com> wrote: >> > On 14 Nov 08:46, H.J. Lu wrote: >> >> What happens when -flto is used on command line? Will we >> >> generate both LTO IR and offload IR? >> > >> > Right. >> > >> > I'm not sure whether we should make slim objects in case of LTO + offload IR... >> > >> >> Isn't __gnu_lto_slim only applied to regular LTO IR? Should offload IR be >> handled separately from regular LTO IR? It is odd to use flag_fat_lto_objects >> to control offload IR. > > It is handled separately, but it uses a common infrastructure with regular LTO > for streaming, therefore compile_file automatically emits __gnu_lto_slim when > there is at least one section with IR (flag_generate_lto is set). You propose > to introduce a second flag like flag_fat_lto_objects to disable __gnu_lto_slim? > > -- Ilya Can we use bit fields in flag_fat_lto_objects to cintrorl regular LTO IR and offload IR separately?
On Fri, Nov 14, 2014 at 6:08 PM, Ilya Verbin <iverbin@gmail.com> wrote: > On 14 Nov 09:01, H.J. Lu wrote: >> On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin <iverbin@gmail.com> wrote: >> > On 14 Nov 08:46, H.J. Lu wrote: >> >> What happens when -flto is used on command line? Will we >> >> generate both LTO IR and offload IR? >> > >> > Right. >> > >> > I'm not sure whether we should make slim objects in case of LTO + offload IR... >> > >> >> Isn't __gnu_lto_slim only applied to regular LTO IR? Should offload IR be >> handled separately from regular LTO IR? It is odd to use flag_fat_lto_objects >> to control offload IR. > > It is handled separately, but it uses a common infrastructure with regular LTO > for streaming, therefore compile_file automatically emits __gnu_lto_slim when > there is at least one section with IR (flag_generate_lto is set). You propose > to introduce a second flag like flag_fat_lto_objects to disable __gnu_lto_slim? Err... why is offloading not guarded with a new symbol like __gnu_lto_offload? Richard. > > -- Ilya
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c index 534c613..584a84e 100644 --- a/gcc/cgraphunit.c +++ b/gcc/cgraphunit.c @@ -2178,7 +2178,10 @@ symbol_table::compile (void) /* Offloading requires LTO infrastructure. */ if (!in_lto_p && g->have_offload) - flag_generate_lto = 1; + { + flag_generate_lto = 1; + flag_fat_lto_objects = 1; + } /* If LTO is enabled, initialize the streamer hooks needed by GIMPLE. */ if (flag_generate_lto)