This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/n] OpenMP 4.0 offloading infrastructure: offload tables


On Mon, Dec 08, 2014 at 01:28:10PM +0400, Ilya Verbin wrote:
> 2014-12-08 12:18 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
> > On Thu, Dec 4, 2014 at 8:35 PM, Ilya Verbin <iverbin@gmail.com> wrote:
> >> Hi,
> >>
> >> On 30 Sep 18:53, Ilya Verbin wrote:
> >>> This patch creates 2 vectors with decls: offload_funcs and offload_vars.
> >>> libgomp will use addresses from these arrays to look up offloaded code.
> >>>
> >>> During the compilation they are outputted to:
> >>> * binary __gnu_offload_funcs/vars sections, or using
> >>>   targetm.record_offload_symbol hook for PTX.
> >>
> >> In some cases LTO may optimize out a global variable, declared as target, but
> >> it still will be referenced from the offload table, that will cause a linking
> >> error.  Here is the example:
> >>
> >> #pragma omp declare target
> >> int G;
> >> #pragma omp end declare target
> >
> > So where is that "magic" target use then?  Why doesn't the symtab
> > reachability code see the use?  (why don't we prune it from the offload
> > table?)
> >
> > Richard.
> 
> Nowhere on host-side, but it can remain non-optimized on target-side,
> therefore we can not remove it only from the host offload table.

Note, the two tables have to match, and after streaming the offloading LTO
IL, it can't be easily adjusted anymore.
Unless we'd allow some magic value (say NULL) for vars that were optimized
away on the host side, then libgomp and/or mkoffload would need to be
adjusted to ignore or remove pairs from the table where the host var has
been optimized away, but the target one not necessarily so.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]