This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: LTO streaming of TARGET_OPTIMIZE_NODE
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, "Joseph S. Myers" <joseph at codesourcery dot com>, Thomas Schwinge <thomas_schwinge at mentor dot com>, Julian Brown <julian at codesourcery dot com>, Cesar Philippidis <cesar_philippidis at mentor dot com>
- Date: Thu, 20 Nov 2014 22:12:00 +0100
- Subject: Re: LTO streaming of TARGET_OPTIMIZE_NODE
- Authentication-results: sourceware.org; auth=none
- References: <20141113040652 dot GB1984 at kam dot mff dot cuni dot cz> <546DDE1C dot 6060203 at t-online dot de> <alpine dot LSU dot 2 dot 11 dot 1411201420370 dot 374 at zhemvz dot fhfr dot qr> <546DF8D2 dot 3070305 at codesourcery dot com>
> On 11/20/2014 02:20 PM, Richard Biener wrote:
> >On Thu, 20 Nov 2014, 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?
> >
> >The offload target needs to have the same target options as the host?
>
> Not really meaningful I'd think.
>
> >Are the offload functions marked somehow? That is, can we avoid
> >setting TREE_TARGET_OPTION on them?
>
> Well, they are mostly generated automatically by omp-low.c, so
> TREE_TARGET_OPTION wouldn't normally be set anyway. So the field is
> unnecessary, we just can't write it out since the two compilers
> involved disagree on its layout.
I am currently populating TREE_TARGET_OPTION in free lang data that is probably
called after omp-low and incrementally I plan to set it even for newly constructed
functions (profiling, ctors etc.) that are built during IPA, so we do not really need
to rely on sane global state at link time.
This however has nothing to do with offloading.
Honza
>
> >Or rather we need to have a
> >default TREE_TARGET_OPTION node for the offload target which we'd
> >need to set - how would you otherwise transfer different offload
> >target options to the offload compile? How do you transfer
> >offload target options to the offload compile at all?
>
> ABI options are transferred via the -foffload-abi mechanism. No
> other target options can be transferred.
>
> >I think this just shows conceptual issues with the LTO approach...
>
> I don't think running into a few problems demonstrates a conceptual
> problem when it works fine with some fairly small patches.
>
>
> Bernd