On 14 Nov 09:11, H.J. Lu wrote:
> On Fri, Nov 14, 2014 at 9:08 AM, Ilya Verbin <iver...@gmail.com> wrote:
> > On 14 Nov 09:01, H.J. Lu wrote:
> >> On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin <iver...@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?
>
> Can we use bit fields in flag_fat_lto_objects to cintrorl regular LTO IR and
> offload IR separately?
Well, I don't see how such a separation can help...
There are 3 possible combinations of section types with offload:
1. asm + offload
2. lto + offload
3. asm + lto + offload
Cases 2 and 3 are handled as usually, there is no need to change them.
The problem is only with the case 1, where gcc should not consider object as
"slim", because in fact it is "fat", since it contains asm.
The patch was updated, is it ok?
-- Ilya
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 534c613..8f55180 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2178,7 +2178,11 @@ symbol_table::compile (void)
/* Offloading requires LTO infrastructure. */
if (!in_lto_p && g->have_offload)
- flag_generate_lto = 1;
+ {
+ flag_generate_lto = 1;
+ if (!flag_lto)
+ flag_fat_lto_objects = 1;
+ }
/* If LTO is enabled, initialize the streamer hooks needed by GIMPLE. */
if (flag_generate_lto)
