From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 345 invoked by alias); 25 Mar 2011 07:37:21 -0000 Received: (qmail 32670 invoked by uid 22791); 25 Mar 2011 07:37:20 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtp-154-thursday.nerim.net (HELO maiev.nerim.net) (194.79.134.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Mar 2011 07:37:15 +0000 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by maiev.nerim.net (Postfix) with ESMTPS id 2A4AE2E035 for ; Fri, 25 Mar 2011 08:37:14 +0100 (CET) Received: from glinka.lesours ([192.168.0.1]) by hector.lesours with smtp (Exim 4.72) (envelope-from ) id 1Q31a5-0007ZS-14; Fri, 25 Mar 2011 08:37:13 +0100 Date: Fri, 25 Mar 2011 10:07:00 -0000 From: Basile Starynkevitch To: gcc@gcc.gnu.org Subject: Serializing mixed gimple data from a plugin in LTO? Message-Id: <20110325083753.c2be7958.basile@starynkevitch.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00384.txt.bz2 Hello All, Let's imagine someone is writing a plugin (or a MELT extension...) which computes some complex information around gimple in a pass before LTO serialization and re-uses that information in a later pass after LTO serialization. A possible way to associate data inside a plugin to some gimples would be to have hash tables (keys being Gimple, associated value being some complex information specific to the plugin). The the plugin would compute & serialize [i.e. write or output] data in a pass before LTO and deserialize [re-read or input] that data at LTO time. The writing happens in the write_summary and write_optimization_summary hooks of struct ipa_opt_pass_d of file tree-pass.h. The reading happens in read_summary & read_optimization_summary hooks. But what I cannot understand is how can such a plugin know what are the gimple involved. Since the plugin needs to persist (i.e. serialize into LTO stream & de-serialize) an hash table mapping some gimples to its data, the plugin need to know what gimples are serialized & deserialized, to restore at LTO streaming read the common gimple pointers (the same gimple pointer should appear in the function & the hash table).... I would imagine gcc/lto-streamer-out.c would have a plugin hook inside output_gimple_stmt but this is not the case... I admit I don't have a clear picture of LTO streams usage (& customization) from plugins. Or perhaps it is not possible yet??? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***