From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26020 invoked by alias); 13 Nov 2014 15:23:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 26011 invoked by uid 89); 13 Nov 2014 15:23:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 13 Nov 2014 15:23:03 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 2C2485440BC; Thu, 13 Nov 2014 16:22:59 +0100 (CET) Date: Thu, 13 Nov 2014 15:32:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, "Joseph S. Myers" Subject: Re: LTO streaming of TARGET_OPTIMIZE_NODE Message-ID: <20141113152258.GE11013@kam.mff.cuni.cz> References: <20141113040652.GB1984@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-11/txt/msg01510.txt.bz2 > > > > Incrementally I would like to handle optimizations nodes same way and change > > streaming format to be a set of assignments field_name=value. > > This way we could behave sanely when some field is introduced or removed by > > either defaulting it or ignoring it. > > I'm not sure that idea is good ;) Adding a version / checksum to > detect a mismatch early would be nice though. Maybe just compute > a hash for the fields in the AWK script? OK, lets see how to handle it incrementaly. > > > Bootstrapped/regtested x86_64-linux, seems sane? > > Sounds sane - I'd like to have a AWK capable person have a look > for non-portable stuff (did you check AIX? ;)) Good idea, will do today :) Basically all the AWK is cut&paste from the way save loop is generated, no really new constructs in it. > > + if (CODE_CONTAINS_STRUCT (code, TS_TARGET_OPTION)) > > + cl_target_option_stream_in (ib, data_in, TREE_TARGET_OPTION (expr)); > > + > > if (code == OMP_CLAUSE) > > lto_input_ts_omp_clause_tree_pointers (ib, data_in, expr); > > Any reason you don't use bitpacks and stream it from > [un]pack_value_fields? We can happily pack strings there as well. > The 'body' streaming is for tree pointers only. Hmm, I did not notice we have pack_string. Will go with bitpacks then. > > @@ -963,6 +960,9 @@ streamer_write_tree_body (struct output_ > > if (CODE_CONTAINS_STRUCT (code, TS_CONSTRUCTOR)) > > write_ts_constructor_tree_pointers (ob, expr, ref_p); > > > > + if (CODE_CONTAINS_STRUCT (code, TS_TARGET_OPTION)) > > + cl_target_option_stream_out (ob, TREE_TARGET_OPTION (expr)); > > + > > if (code == OMP_CLAUSE) > > write_ts_omp_clause_tree_pointers (ob, expr, ref_p); > > } > > Otherwise looks good. OK, I will update the changes above and test AIX today. Incrementally I will send patch to disable the TARGET_OPTION_NODE regeeneration from attribute and to stream TARGET_OPTION_NODE for all functions (this is tested on firefox and AIX by now and works). For optimization node I think I can follow exactly the same strategy (to avoid writting binary blobs that are not portable). I plan to add Ipa and Late modifiers to the format to annotate flags that affects only Ipa or Late codegen/optimization (ltrans). This way we can add comparers for inliner ignoring the flags that are not marked Late and streamer that streams only Ipa/Late. If this plan sounds sane, I can do it today I believe. Across stage3 early stage3 I can update IPA passes to not check global flags during LTO so we can support correctly support different LTO flags (like -fno-inline) in the optimization nodes... Honza > > Thanks, > Richard.