From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16598 invoked by alias); 23 Apr 2003 07:45:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16591 invoked from network); 23 Apr 2003 07:45:37 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 23 Apr 2003 07:45:37 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id 6542F4DE31; Wed, 23 Apr 2003 09:45:37 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Wed, 23 Apr 2003 09:45:37 +0200 Date: Wed, 23 Apr 2003 10:59:00 -0000 From: Jan Hubicka To: Richard Henderson , Ulrich Weigand , Jan Hubicka , gcc@gcc.gnu.org, aj@suse.de Subject: Re: Profiling on S390 Message-ID: <20030423074537.GG15464@kam.mff.cuni.cz> References: <20030422211923.GE21400@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030422211923.GE21400@redhat.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg01135.txt.bz2 > On Tue, Apr 22, 2003 at 10:43:37PM +0200, Ulrich Weigand wrote: > > >It looks very unsafe for me - GCC assumes at many places that CC is not > > >live accross boundaries. > > > > This is annoying. Is there any fundamental reason for this restriction? > > No, and it's not actually true. > > What is true is that you can't generally move the thing around > if most of your instructions clobber the flags. So e.g. for x86 > this would be a Really Bad Idea, but for Sparc it can work out. My impression is that s390 is x86-like when dealing with flags. > > It's also true that some of the simplifiers (cse, combine) won't > DTRT unless the compare and use are in the same block. > > > Can't the profiler use special code to save/restore CC? > > It could, but if you don't have add/load/store insns that don't > clobber CC, then you'll get in trouble with reload too. Of We can conclude to use some named patterns. For instance "save_state" "restore_state" to fold profiler code in. Does this sound plausible? Honza > course, that brings up the issue of getting the right pattern > emitted from the profiler. Could be done with a special named > add pattern, but that seems like a lot of overhead for very > little return. > > This is all about a movstrsi or cmpstrsi pattern? Perhaps it > would be better to keep this as one unit until after reload? > > > r~