This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Questions about LTO infrastructure and pragma omp target
- From: Ilya Verbin <iverbin at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, Uday Khedker <uday at cse dot iitb dot ac dot in>
- Cc: hubicka at ucw dot cz, rth at redhat dot com, kirill dot yukhin at gmail dot com, "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 23 Aug 2013 14:55:27 +0400
- Subject: Re: Questions about LTO infrastructure and pragma omp target
- References: <20130815133639 dot GA42355 at msticlxl57 dot ims dot intel dot com> <20130815134437 dot GB1814 at tucnak dot redhat dot com> <4df844f6-f385-4e63-9413-8ea341992b77 at email dot android dot com>
Jakub, Richard, Uday,
Thanks for your answers.
On 15 Aug 20:59, Richard Biener wrote:
> Alternatively you make lto-wrapper aware of this which means that WPA stage would emit extra partitions that it marks for lto-wrapper.
>
> That sounds better than another plugin to me. Of course WPA time might be too limiting. Otoh the idea of multiple WPA stages, aka iterating lto could be picked up to have a late WPA stage.
>
> Richard.
I'm trying to implement the approach with modified lto-wrapper.
Suppose we have a bytecode of the routine foo, streamed during ompexp pass into some section, say .gnu.omptarget_foo.
In function lto.c:do_whole_program_analysis() an extra partition should be created, that will contain bytecode from .gnu.omptarget_foo, right?
As far as I understood, in addition to the bytecode of foo, we should also stream extra symtab_nodes, and read them somewhere in lto-cgraph.c:input_symtab().
This means we should maintain 2 symtabs inside WPA stage - original for host and new for target?
Richard, also what do you mean by "WPA time might be too limiting"?
Thanks,
-- Ilya