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: nvptx offloading patches [3/n], RFD


On Mon, Feb 16, 2015 at 22:08:12 +0100, Jakub Jelinek wrote:
> Anyway, the question is if for offloading we use wpa stage at all these days
> or not at all, if there is a way for ACCEL_COMPILER to differentiate
> somehow between LTO sections written by the host compiler and LTO sections
> perhaps created by the offloading compiler when trying to LTO the thing (if
> it does it at all).  Because obviously the host compiler written LTO
> (in .gnu.offload_lto_*) would need the machine modes translated, while
> LTO streamed already by the ACCEL_COMPILER (if any) generally would already
> use the offloading target machine modes and therefore should be treated as
> native lto (.gnu.lto_*). 

Currently both intelmic and nvptx offloading compilers are executed in
non-partitioned LTO mode.  I don't know whether we need to support WHOPR
(WPA+LTRANS) mode.  Maybe it would be useful for programs with large number of
target regions?  But I think this is not needed for GCC 5.
> 
> If we don't try to write .gnu.offload_lto_* again, I think following patch
> with additionally not calling lto_write_mode_table for !lto_stream_offload_p
> and not calling lto_input_mode_table for !ACCEL_COMPILER - instead build
> a single shared identity table - might actually work.
> 
> Thoughts on this?

Probably the ACCEL_COMPILER in WPA mode (flag_wpa) can read .gnu.offload_lto_*
sections and produce temporary partitions with .gnu.lto_* sections.  And the
ACCEL_COMPILER in LTRANS mode (flag_ltrans) will read .gnu.lto_* sections?

  -- Ilya


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