Ilya Verbin <iver...@gmail.com> wrote: >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?
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? No, as you will refer to the symbol with the target code from the host code you need a single unified symtab. >Richard, also what do you mean by "WPA time might be too limiting"? At WPA time you do not have function bodies available, so you need to identify candidates at compile-time. Also no sophisticated optimization has happened at this point of the compilation. Richard. >Thanks, > -- Ilya
