Re: LTO streaming of TARGET_OPTIMIZE_NODE

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Thu, 8 Jan 2015 15:11:49 +0100, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Nov 20, 2014 at 01:27:08PM +0100, Bernd Schmidt wrote:
> > On 11/13/2014 05:06 AM, Jan Hubicka wrote:
> > >this patch adds infrastructure for proper streaming and merging of
> > >TREE_TARGET_OPTION.
> > 
> > This breaks the offloading path via LTO since it introduces an
> > incompatibility in LTO format between host and offload machine.
> > 
> > A very quick patch to fix it is below - the OpenACC testcase I was using
> > seems to be working again with this. Thoughts, suggestions?
> 
> I actually think

Thanks for picking up this issue!

> this patch makes a lot of sense.  Target option nodes
> by definition are target specific, generally there is no mapping between
> host and offloading target features.  So, the host target options
> are not useful to the offloading target.  And, because the amount of bits
> streamed is also target specific, say x86_64 will have different and
> incompatible cl_target_option_stream_{out,in} from nvptx, and even
> for Intel MIC offloading it doesn't make much sense, what CPU is certain
> function targetting doesn't necessarily have any relation to the Intel MIC
> that will offload it.

> Also note that the patch fixes all the current regressions in Intel MIC
> (emulated) offloading caused by the r218767

(Which has been filed as <https://gcc.gnu.org/PR64412>, by the way.)

I'm confirming that Bernd's patch resolves the intelmic offloading
regressions, but I still do see issues in all nvptx offloading, but
cannot tell yet what's going on.  (Reverting Honza's patch resolves
these; but maybe it's something that is solely an issue with the nvptx
offloading path.)


GrÃÃe,
 Thomas

Attachment: pgpZoqcQKIFhc.pgp
Description: PGP signature