From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-147211-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2339 invoked by alias); 10 Jun 2008 18:58:38 -0000
Received: (qmail 2331 invoked by uid 22791); 10 Jun 2008 18:58:37 -0000
X-Spam-Check-By: sourceware.org
Received: from SAGW-PRIMARY.ARC.COM (HELO elsdt-razorfish.arc.com) (62.189.186.51)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jun 2008 18:58:20 +0000
Received: from elsdt-razorfish.arc.com (localhost.localdomain [127.0.0.1]) 	by elsdt-razorfish.arc.com (8.13.8/8.13.8) with ESMTP id m5AIwG02019997; 	Tue, 10 Jun 2008 19:58:16 +0100
Received: (from joernr@localhost) 	by elsdt-razorfish.arc.com (8.13.8/8.13.8/Submit) id m5AIwGhK019996; 	Tue, 10 Jun 2008 19:58:16 +0100
Date: Tue, 10 Jun 2008 18:58:00 -0000
From: Joern Rennecke <joernr@arc.com>
To: Steven Bosscher <stevenb.gcc@gmail.com>
Cc: "Kaveh R. GHAZI" <ghazi@caip.rutgers.edu>,         Ian Lance Taylor <iant@google.com>, gcc@gcc.gnu.org
Subject: Re: constified note_stores
Message-ID: <20080610185816.GN32358@elsdt-razorfish.arc.com>
References: <20080609224328.GK32358@elsdt-razorfish.arc.com> <m33anmkx85.fsf@google.com> <13D82723C9864E9C93CA351786EAE74C@glap> <20080610133836.GL32358@elsdt-razorfish.arc.com> <Pine.GSO.4.58.0806101329001.6649@caipclassic.rutgers.edu> <20080610182214.GM32358@elsdt-razorfish.arc.com> <571f6b510806101127if21b8a5y24bcae574a91589@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <571f6b510806101127if21b8a5y24bcae574a91589@mail.gmail.com>
User-Agent: Mutt/1.4.2.2i
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2008-06/txt/msg00257.txt.bz2

On Tue, Jun 10, 2008 at 08:27:43PM +0200, Steven Bosscher wrote:
> Actually, hold on a second please.  You're only talking in terms of
> solutions.  But what *exactly* are you trying to do?  You ave to
> modify the SET_SRC of some SETs.  What do these SET_SRCs look like?
> This is important, because if you are only looking at registers, maybe
> you can easily access them through DF_INSN_DEFS.

I am looking for special CONSTs that appear either as SET_SRC or as
memory addresses in SET_SRC or SET_DEST.

If I find a CONST with a specific UNSPEC there which is not hash table
yet, I emit some code; the CONST is then replaced with a SYMBOL_REF.

Or if you want the more abstract description, I'm shifting the burden of
profiling from the callee to the caller, thus saving some time and memory
for profiling, and getting acceptable profiling results when the libraries
contain only callgraph information instead of actual instrumentation -
i.e. we can do profiling without libg.a .